A New Development Paradigm

These days, developing in Liferay DXP looks very different from even just a few years ago. Plugins, for instance, used to be the best thing since Windows 95. (In fact, we’ve already waxed poetic about the magic and pitfalls of plugins.)

Now, the landscape has shifted in favor of more sustainable solution-building. That means leveraging and prioritizing the full breadth of Liferay DXP’s out-of-the-box capabilities and 300+ features. If you absolutely can’t cover your use case OOTB, explore Client Extensions. Client Extensions at a basic level are services used outside of the product in a way that doesn’t interfere with the core. 

Plugins have become the last resort of development. And even then, we recommend following best practices to make sure you can remove your plugin later with either a client extension or OOTB capability. And if you really need to go the plugin route, the best place to look is Liferay Marketplace.

Just because development looks different doesn’t mean the old approach is wrong—there are still certain cases where we’d recommend it. For the majority of our customers and partners, however, the current way of developing that prioritizes easier upgrades and future-proofing is the best fit.

Rather than emphasizing a dichotomy of right/wrong, the term “modern application development” highlights just how much developing on Liferay has evolved over the years, especially with the move to quarterly releases.

So what does this look like in practice?

Major Development Shifts

Below, you’ll find a few examples of what development used to look like versus now.

10 Best Practices for Developing Today with Liferay DXP

Now you have a basic framework for understanding what modern application development is and isn’t in Liferay.

Next, we’ll cover ten best practices.

1. Follow existing best practices 

Your deployment method—Liferay SaaS, Liferay PaaS, or Self-Hosted—doesn’t matter when we’re talking about best practices, since the primary business value of Liferay-based solutions comes from the core Liferay DXP product.

The most important best practice? Start building your solution with the features and functionality available out of the box. Liferay DXP has a long list of features you may not even be aware of, and we’re always adding new ones. Make sure you keep up with what’s new—and don’t be afraid to find creative ways of solving your use cases.

2. Equip your own internal teams

Your teams should have the right tools and processes to be successful. Even if you’re managing custom code outside of Liferay DXP, as with the Liferay SaaS deployment option, you still need to think about the developer experience:

1. Liferay Workspace should be your first stop to help you manage and organize your Client Extensions.

2. Blade CLI is where you’ll manage local servers, build deployable artifacts, and handle local deployment.

3. Liferay Cloud CLI, for Liferay PaaS or Liferay SaaS deployment methods, interacts with Liferay DXP’s cloud resources.

3. Properly organize and package your code

The way you organize your code has both short and long-term ramifications:

1. Short term. Code organization has a direct impact on the resources your solution is consuming. For instance, if your deployment method is Liferay SaaS, CPU and Memory vary based on your subscription and subscription add-ons.

   • Example: You have three different applications that include object actions or CRON actions, implemented as Spring Boot microservices. If you packaged these as three different Client Extensions, this means you would be running three different Spring Boot servers, each taking up precious CPU and Memory with duplicated overhead. Putting all three into a single Client Extension, however, would reduce your usage to one Spring Boot server.

2. Long term. Code organization also impacts maintenance as well as how easy it is for a new developer or implementation partner to understand your setup.

   • Example: Remember those three applications? Maybe they were built and maintained for three different departments by three different development teams or even three different implementation partners. In this case, how difficult would it be to handle the possible conflicts that might arise from disparate teams working on the same Client Extension?

This is why you need to balance present and future considerations as well as any technical limitations of your specific Client Extensions.

4. Design your data models and APIs for performance

You can’t necessarily approach data modeling with Liferay Objects the same way you would when working with normalized data. Instead, you have to think about how you’re actually going to use and interact with data.

Because Headless APIs are the primary way you should be reading and updating data, think about the performance impact if you had to make multiple calls to retrieve related data from inside a complex normalized data structure as before.

In the past when you were running code inside Liferay, those calls came from “inside the house,” so multiple calls to different services to aggregate data didn’t have such a negative impact. Now, it’s like the calls are coming from outside the house, and each call needs to unlock the front door and show proper identification, so making multiple calls to different endpoints to assemble your data can lead to significant impact on your throughput.

5. Leverage batch processing

We mentioned that you’ll be interacting with Headless APIs a lot. If you’re not handling this interaction correctly, it becomes a bottleneck.

That’s where the Batch Framework and Batch Endpoints come in for scalability. Remember all those calls from outside the house, waiting in line? If you only have a single endpoint, this creates a major problem. With Batch Endpoints, however, you can create or update many data records via a single call. No more line!

6. Embrace the asynchronous patterns of microservices

In the Before Times when Liferay development was traditionally monolithic, we followed request-driven, synchronous patterns, and this worked well.

With Client Extensions, however, we’ve moved toward a microservice-based approach, which means embracing the asynchronous patterns that rule the microservices world.

Since this is a complete paradigm shift, you may need time to adjust. But, especially for a transactional application like a ticketing or reservation system with high expected volume, for example, you’ll reap the rewards many times over.

7. Use OAuth to manage security

Another vestige of the Before Times? You may have been comfortable accessing Liferay DXP’s service layer and permissions system directly.

That’s not the case anymore with Client Extensions. So, going back to the caller analogy, how can you show ID and get that door unlocked?

Create an OAuth application to access Liferay DXP’s resources securely, define the scope, and grant only the specific access that the external service requires. (You wouldn’t normally let your roof contractor use your master bathroom!)

Make sure you’re following the best practices for OAuth:

• Restrict access token privileges to the minimum required for a specific application or use case.

• Store your OAuth credentials securely.

• Use Service Accounts for automated workflows and integrations.

8. Ensure portability by using External Reference Codes

If you’ve worked with Liferay entity ids before, you’ll need to learn to rely on External Reference Codes (ERCs) now. An ERC is an alphanumeric code that uniquely identifies entities across your entire solution and across multiple systems. The power of an ERC is that it tells you exactly what entity you’re working with, regardless of its origin or destination.

You can’t control an ERC when you’re importing data from an external system, but any entity created in Liferay DXP, though it generates an automatic value, can be changed. You’ll want to use business- or developer-friendly values to ensure your code and API usage is easier to understand.

9. Test early, test often, and test realistically

Don’t make testing an afterthought. Even from your initial solution conceptualization, plan how to test your application in a way that mimics the real-world experience and day-to-day wear-and-tear it will take. 

For example, if you’re working in a distributed environment like Liferay SaaS, running your application locally for testing isn’t enough. Things may appear to work fine, but upon deployment, you’d probably discover, too late, unanticipated problems. This could impact your overall timeline as well as your performance.

10. Leverage your browser's computing power vs. server-side resources

In the past, developing with Liferay leaned on server-side processing. With front-end Client Extensions that provide support for technologies like React, Angular, and VueJS, you can move some of that processing to your browser. These technologies offer your users more immediate feedback and responsiveness while reducing your server load.

A New Frontier of Liferay Development

Gone are the wild west days of Liferay development. And although there are certain circumstances where you may want to harness the wild mustang of plugins, your default should be instead to turn to the reins and fences of modern application development.

Modern application development in Liferay DXP still gives you the opportunity to build creative, innovative solutions—just in a more sustainable way.

Ready to dive into Liferay development yourself? Start a Pre-Built Trial.

Author Bio: Jeff Handa is a Senior Manager of Solution Delivery and has worked at Liferay for almost two decades, with training and consulting experience across 18 countries. Jeff is passionate about helping customers understand how to get the most out of Liferay DXP’s out-of-the-box features and how to correctly extend the platform. In his spare time, Jeff enjoys spending time with family, woodworking, grilling, and mastering the art of beer brewing.