For years, 𝗦𝗲𝗿𝘃𝗶𝗰𝗲 𝗕𝘂𝗶𝗹𝗱𝗲𝗿 was considered the backbone of backend development in Liferay.

Need a custom entity?
Use Service Builder.

Need APIs?
Use Service Builder.

Need persistence, finder methods, services, indexing, permissions, workflows, or business logic?
Again, Service Builder.

It became the default engineering pattern for almost every serious Liferay implementation.

But the ecosystem has changed dramatically.

Today, when I look at modern Liferay architecture, I think a very important question needs to be asked:

▎ Is Service Builder still the primary way to build backend systems in Liferay?

Honestly, for many use cases, the answer is no.

────────────────

𝗧𝗛𝗘 𝗥𝗜𝗦𝗘 𝗢𝗙 𝗟𝗜𝗙𝗘𝗥𝗔𝗬 𝗢𝗕𝗝𝗘𝗖𝗧𝗦

Liferay Objects changed the development experience completely.

Instead of writing large OSGi modules for every business requirement, teams can now create business-driven applications directly from the platform itself.

Objects already provide:

 - Data modeling
 - Relationships
 - Permissions
 - Workflows
 - APIs
 - Validation
 - UI generation
 - Headless access
 - Low-code administration

This removes a huge amount of engineering overhead.

A business requirement that previously needed:

 - Service Builder entities
 - Local services
 - Remote services
 - REST builders
 - JSPs or React UI
 - Permission handling
 - Workflow integration

…can now sometimes be solved in hours using Objects.

That is a massive architectural shift.

────────────────

𝗪𝗛𝗬 𝗦𝗘𝗥𝗩𝗜𝗖𝗘 𝗕𝗨𝗜𝗟𝗗𝗘𝗥 𝗜𝗦 𝗡𝗢 𝗟𝗢𝗡𝗚𝗘𝗥 𝗧𝗛𝗘 𝗗𝗘𝗙𝗔𝗨𝗟𝗧 𝗔𝗡𝗦𝗪𝗘𝗥

One of the biggest mistakes I still see is treating Service Builder as the starting point for every backend requirement.

That mindset made sense years ago.

But modern enterprise systems are evolving differently.

Today’s architectures are increasingly based on:

 - Microservices
 - Headless APIs
 - External platforms
 - Event-driven systems
 - Cloud-native deployments
 - Frontend/backend separation

In this type of ecosystem, Liferay often acts more like:

 - A digital experience layer
 - A business orchestration layer
 - A frontend aggregation platform

not necessarily the place where all backend logic must live.

And this is exactly where:

 - 𝗟𝗶𝗳𝗲𝗿𝗮𝘆 𝗢𝗯𝗷𝗲𝗰𝘁𝘀
 - 𝗖𝗹𝗶𝗲𝗻𝘁 𝗘𝘅𝘁𝗲𝗻𝘀𝗶𝗼𝗻𝘀
 - 𝗘𝘅𝘁𝗲𝗿𝗻𝗮𝗹 𝗦𝗲𝗿𝘃𝗶𝗰𝗲𝘀
 - 𝗛𝗲𝗮𝗱𝗹𝗲𝘀𝘀 𝗶𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗶𝗼𝗻𝘀

start becoming much more powerful than traditional monolithic OSGi development.

────────────────

𝗧𝗛𝗘 𝗣𝗥𝗢𝗕𝗟𝗘𝗠 𝗪𝗜𝗧𝗛 𝗢𝗩𝗘𝗥𝗨𝗦𝗜𝗡𝗚 𝗦𝗘𝗥𝗩𝗜𝗖𝗘 𝗕𝗨𝗜𝗟𝗗𝗘𝗥

Service Builder is extremely powerful.

But power is not always the correct architectural choice.

Large Service Builder-heavy projects often create:

 - Tight coupling with portal runtime
 - Complex deployments
 - OSGi dependency challenges
 - Upgrade difficulties
 - Slower development cycles
 - Harder scalability patterns
 - Platform lock-in

And honestly, many modern backend concerns are handled far better today using dedicated external services.

For example:

 - High-volume processing
 - AI integrations
 - Payment orchestration
 - Analytics engines
 - External ERP synchronization
 - Distributed workflows
 - Event streaming

These workloads naturally fit microservice architectures more than portal-contained business logic.

────────────────

𝗦𝗢 𝗜𝗦 𝗦𝗘𝗥𝗩𝗜𝗖𝗘 𝗕𝗨𝗜𝗟𝗗𝗘𝗥 𝗗𝗘𝗔𝗗?

Not at all.

Service Builder still has very strong use cases.

It remains valuable when:

 - Deep portal integration is required
 - Internal Liferay persistence is necessary
 - Tight coupling with platform services is beneficial
 - Advanced indexing/custom search control is needed
 - Existing enterprise implementations heavily depend on it

But I no longer see it as the “default architecture.”

That’s the key difference.

────────────────

𝗪𝗛𝗔𝗧 𝗠𝗢𝗗𝗘𝗥𝗡 𝗟𝗜𝗙𝗘𝗥𝗔𝗬 𝗔𝗥𝗖𝗛𝗜𝗧𝗘𝗖𝗧𝗨𝗥𝗘 𝗟𝗢𝗢𝗞𝗦 𝗟𝗜𝗞𝗘

In my opinion, modern Liferay development is moving toward this combination:

 - 𝗟𝗶𝗳𝗲𝗿𝗮𝘆 𝗢𝗯𝗷𝗲𝗰𝘁𝘀 for business-driven configuration
 - 𝗖𝗹𝗶𝗲𝗻𝘁 𝗘𝘅𝘁𝗲𝗻𝘀𝗶𝗼𝗻𝘀 for frontend/backend flexibility
 - 𝗛𝗲𝗮𝗱𝗹𝗲𝘀𝘀 𝗔𝗣𝗜𝘀 for interoperability
 - 𝗘𝘅𝘁𝗲𝗿𝗻𝗮𝗹 𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 for scalable business logic
 - 𝗟𝗶𝗳𝗲𝗿𝗮𝘆 𝗮𝘀 𝗮𝗻 𝗼𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 𝗽𝗹𝗮𝘁𝗳𝗼𝗿𝗺

This creates:

 - Cleaner separation
 - Faster delivery
 - Independent deployments
 - Better scalability
 - Easier modernization
 - Technology freedom

And honestly, this approach aligns much more closely with modern enterprise engineering principles.

────────────────

𝗙𝗜𝗡𝗔𝗟 𝗧𝗛𝗢𝗨𝗚𝗛𝗧𝗦

I don’t think the future is:

▎ “Objects replacing Service Builder.”

I think the future is:

▎ “Architectures becoming less portal-centric.”

And in that world, Service Builder becomes one tool among many — not the center of the entire backend strategy.

That’s the real shift happening in the Liferay ecosystem right now.