Is Service Builder Still the Default? Rethinking Backend Architecture in Liferay

This is LR Tools’ rewrite of an architecture opinion piece by Bhargav R Vaghasiya on Liferay.dev, arguing that a long-standing Liferay default is worth reconsidering.

The old default

For years, Service Builder was treated as the backbone of Liferay backend development — the automatic answer any time a project needed a custom entity, an API, persistence, finder methods, services, indexing, permissions, workflows, or general business logic. It became the standard engineering pattern for nearly every serious Liferay implementation, to the point where reaching for it wasn’t really a decision, just a habit.

What changed the equation

Liferay Objects shifted what’s actually necessary to build a business-driven application on the platform. Objects already provide data modeling, relationships, permissions, workflows, APIs, validation, UI generation, headless access, and low-code administration out of the box — work that used to mean writing Service Builder entities, local and remote services, REST builders, a JSP or React UI, permission wiring, and workflow integration by hand. Some of that work now takes hours with Objects instead of the days or weeks it used to take with a full OSGi module. That’s a real architectural shift, not a minor convenience.

Why “always Service Builder” stopped fitting

One of the more common mistakes still floating around Liferay projects is treating Service Builder as the automatic starting point for every backend requirement — a mindset that made sense when it was genuinely the only real option, but doesn’t fit how modern enterprise systems tend to get built now. Current architectures lean on microservices, headless APIs, external platforms, event-driven systems, and cloud-native deployment, with a clean split between frontend and backend. In that kind of ecosystem, Liferay increasingly functions as a digital experience layer, a business orchestration layer, or a frontend aggregation platform — not necessarily the place all backend logic has to live. That’s exactly the context where Liferay Objects, Client Extensions, external services, and headless integrations end up doing more useful work than another monolithic OSGi module would.

The real cost of defaulting to Service Builder

Service Builder is genuinely powerful — the argument here isn’t that it’s weak, it’s that power isn’t the same thing as being the right choice by default. Large Service-Builder-heavy projects tend to accumulate tight coupling to the portal runtime, complicated deployments, OSGi dependency headaches, harder upgrades, slower development cycles, and platform lock-in. A lot of what modern backends actually need to do — high-volume processing, AI integrations, payment orchestration, analytics, external ERP synchronization, distributed workflows, event streaming — tends to be handled better by dedicated external services built as microservices, because that’s the architecture those workloads actually suit.

Service Builder isn’t dead

None of this means Service Builder should be abandoned. It’s still the right tool when deep portal integration is genuinely required, when internal Liferay persistence is needed, when tight coupling to platform services is actually a benefit rather than a cost, when advanced or custom search/indexing control matters, or when an existing implementation already depends on it heavily. The shift isn’t “stop using Service Builder” — it’s “stop treating it as the default architecture.” That distinction is the actual point.

What a modern Liferay backend looks like

Put together, the emerging pattern combines Liferay Objects for business-driven configuration, Client Extensions for frontend/backend flexibility, headless APIs for interoperability, external microservices for logic that genuinely needs to scale independently, and Liferay itself acting as an orchestration and experience platform rather than a monolith holding everything. That combination tends to produce cleaner separation of concerns, faster delivery, independent deployments, easier scaling, and more freedom in technology choices — closer to how enterprise engineering generally works outside the portal world.

The actual reframe

The interesting shift isn’t “Objects replacing Service Builder” — it’s architectures becoming less portal-centric overall. In that framing, Service Builder becomes one tool among several rather than the center of the entire backend strategy, which is a more useful way to think about the decision than asking whether it’s been made obsolete.

This article is LR Tools’ rewrite of the original post by Bhargav R Vaghasiya — read it on Liferay.dev for the author’s own framing.