Background

As the saying goes, the only constant in life is change and while I’m sure Heraclitus wasn’t thinking about software development back in 500 BC, it applies equally as well to Liferay Development

I’ve been using Liferay for over 15 years and have had the privilege of seeing many important changes in how we use Liferay for building solutions.  Some of them have been relatively small, but very impactful.  For example, I remember the introduction of the Control Panel, I think it was added in version 5.2.  Prior to that, the first step everyone needed to take after a fresh install was creating an administrative page that contained all the important portlets for managing a Liferay instance.  It seemed like such an obvious change for the better that I doubt there were too many people that were passionately opposed to it.  

Of course some of the changes were a little more drastic, and had a much larger impact on the solutions we were building, and maintaining.  I’m thinking of the transition from Liferay Portal EE to Liferay DXP and the architectural changes that OSGi introduced.  Now in that case, I don’t think you would have any problems finding some dissenting voices.  Even though the long term benefits have been overwhelmingly positive, there was a difficult transition for many Liferay solutions.  

And here we are, in the closing months of 2024, going through another change.  However, this change might feel a little more subtle to many of us, because we’ve learned a thing or two over the years about how to help manage change.  Even though we’ve introduced some very big architectural changes and some new ways of doing things,  we’ve also continued to support the old ways of doing things.  While personally, I think this is the right move, it has sometimes caused confusion for some members of the Liferay community.  One of the biggest points of confusion is due to the fact that the timing of some of these changes coincided with the introduction of Liferay SaaS.  This has led some people to think that these new approaches are exclusive to Liferay SaaS projects, and that they don’t apply to Liferay PaaS or Liferay Self Hosted solutions which couldn’t be further from the truth.  

Introducing a New Paradigm

In my mind, and when I am talking about these changes with people I have taken to using the term ‘Modern Liferay Application Development’ as an umbrella term that captures all of the newer features and approaches that a new LIferay solution should be leveraging today.   I don’t know if this is the best term, since the use of the word modern implies that the alternative is old or antiquated, but it’s the best term I’ve found and it seems to resonate with people.  

So what do I mean by Modern Liferay Application Development?  Well, in a nutshell a Modern Liferay Application follows these guidelines:  

1. Native Liferay features and functionality - A Modern Liferay Application relies on as much out of the box functionality as possible, leveraging features such as Collections, Fragments, and Data Sets for displaying data whenever possible.    

2. Liferay Objects for data modeling - When an out of the box data model is not available, a Modern Liferay Application uses Liferay Objects to create new data models.  

3. Liferay Headless API for data access - A modern Liferay Application leverages Liferay’s Headless APIs for all interaction with Liferay data, not just for integration.  This means no more talking directly with the Liferay service layer from your code or even from templates and fragments.  

4. Client Extensions for applications- When native Liferay functionality isn’t sufficient, a Modern Liferay Application extends the platform through the use of Client Extensions.

What’s the advantage of using this approach?  Well the primary advantage is in the maintainability of your solution.  If you can stick to the Modern Liferay Application approach, you will have a solution that is easy to upgrade and cheaper to maintain.  You will also find that by upgrading more often, your solution will benefit from all of the new features that the Liferay product team are introducing with every quarterly release.  

And what about the older way of doing things?  Developing portlets, modeling data with  Service Builder and creating APIs with Rest Builder, and deploying all of these changes through OSGi modules.  Is there anything wrong with those tools?  No, they are still fully supported by Liferay and will continue to be in the future. In some cases, the OSGi based module approach may provide additional features that can’t be matched with Moden Liferay Application Development, at least not yet. However, like everything in Life, there are tradeoffs, and using these older Module based approaches may incur higher maintenance costs and may reduce your agility and ability to upgrade as frequently.  

Conclusion

So there you have it, two perfectly valid approaches to Liferay Development which I have been referring to as:  

1. Modern Liferay Application Development

2. Liferay Module Based Development

And of course, during this time of change there are going to be a lot of projects that use a blended approach, taking as many of the Modern Liferay Application Development patterns as possible, but still using Liferay Module Based Development when necessary, and that’s also perfectly valid.  Perhaps we should call that Liferay Hybrid Application Development :)  

What do you think?  I’d love to hear your thoughts and get your feedback and if you're attending DevCon this week I'll be talking about some of these topics and I'd love to  get a chance to meet you in person!  

Photo by Ryan De Hamer on Unsplash