The Evolution of the Plugin Model — and Why It Needed to Evolve in the First Place

Sometimes I sit and reflect: what made me fall in love with Liferay? Maybe that sounds like a strange way to pass the time. But after almost 15 years of developing expertise in Liferay, it’s fair to call it an integral part of my life.

My conclusion to that question, every time: the blessing and the curse of plugins.

Plugins are the best. Simply put, a plugin is an independent piece of functionality that gets inserted into your existing software, enabling you to extend what’s already there or add entirely new functionality.

If you’re a developer, you’ve probably experienced the dopamine hit that comes with deploying a plugin and actually seeing your work in action—particularly if you’ve written your own plugin that changes the way base functionality in a product works.

I love plugins. I’m addicted to plugins. And in Liferay, you can use plugins to accomplish complex tasks with relative ease, which makes you look like a genius and a rockstar at the same time. So who wouldn’t love plugins?

The answer: Anyone working on an upgrade from one version of software to the next.

That’s the issue that Liferay’s ultra-flexible development model created—and the issue that we set out to solve.

But first, some background.

 

The Power and Lure of Plugins

Pluggable architecture used to be all the rage. The idea that you could free yourself from the limitations of traditional development and task accomplishment seemed to open up an endless realm of possibilities.

Why? Well, at a basic level, most product companies try to anticipate their users’ goals, and then develop capabilities to help users meet those goals. If you make HR software, for example, you might create a way to automate the employee review process.

Plugins were created to address a problem for rapidly growing businesses that often have extremely complex requirements: it’s virtually impossible to anticipate all necessary product capabilities, so having the ability to build functionality into an existing product allows you to change and adapt for the future.

At Liferay, we took plugins a step further. In our product, not only could you “plug in” new capabilities, but you could also “plug in” changes to override existing behavior. This made it possible to alter just one part of an existing feature rather than replacing the whole thing (though you can do that too, if you want.)

For instance, you could inject logic to run as part of a Login pipeline of actions without building the entire login solution. Essentially, you’re taking the out-of-the-box capability and squeezing your way into the execution by adding instructions that tell Liferay, “...and when you get to this point, do x and y as well.”

This way of working with plugins became a clear differentiator between Liferay and competitors. As a developer, the power and productivity gains of Liferay’s plugin model were what sold me. I could get more done in less time, maximizing the value I could deliver to customers. Projects that would have taken me three months to complete with another product I could finish in two weeks.

But everything comes with a price. 

 

The Price of Plugins

With all their power, plugins have tradeoffs.

1. First Tradeoff: A Limited Tech Stack

This doesn’t happen by design. Rather, it’s a consequence of the fact that the portal container (in our case, Liferay DXP itself) manages the plugins. Although there are no boundaries in terms of what you can do with your plugins, you can only work in the context of a finite set of tools. This could be an issue for multiple reasons, but the most challenging one is finding developers who are comfortable using the technology and/or educating internal teams to use it.

2. Second Tradeoff: API Dependency

Dependency on the product’s APIs is a particular pain-point for people who aren’t plugin fans. APIs are great at doing their job: making sure when you actually “plug in” your plugin, that it works, but APIs also reflect the exposed capabilities of the product itself. As the product changes, so do the APIs.

This is what can make upgrades to a new version so challenging. If newer capabilities get released, but the plugins you’ve created have interfered with or now rely upon the old capabilities inextricably, you can’t upgrade smoothly. That’s why it’s important to maintain the plugins you create, rather than plugging them in once and then leaving them alone without reference to how the product changes.

3. Third Tradeoff: The Investment

Like many vendors, Liferay adheres to open standards. These standards are agreements by which major market players have chosen to abide. But Liferay (also like many vendors) frequently extends those standards to provide additional functionality in order to offer a developer or user experience that ends up being unique to Liferay. So while it’s very simple, for example, to create a plugin/widget that lets users enter or track data, render it on screen, and then make it available to other systems, in the traditional method, that plugin would only be available to use in Liferay.

At least, that was the case. Until now.

 

From Plugins to Client Extensions

We knew we had to solve the issue that our plugin model had created, and we knew it would involve a paradigm shift in our approach to the Liferay Customization Framework, which is the way we determine when and how to customize.

We began brainstorming with a big end goal: let’s still give customers the ability to customize our solutions, including with new functionality, while allowing them to maintain a decoupled solution.

Easy, right? Not exactly—a lot of complexity hides behind this goal. Fundamentally, it means asking for autonomous systems that can exist on their own but are aware of the existence and capabilities of other systems. These two systems then would work together to solve problems—a technologically symbiotic relationship.

In the Liferay DXP plugin world, that looks like taking the plugin out of its traditional home, the portal container, and running it externally. By moving the plugin outside of the portal container, however, the product needed to change in other ways, because unless Liferay DXP knows about the existence of the plugin living somewhere else, there can’t be any task delegation.

Does all of this sound too complicated? Transfer this idea to the way a company works with people. When I need a new design for an area of Liferay Learn, I don’t come up with it myself—I delegate to our Design team. When that section is done and ready to be announced, I don’t take over our social media accounts—I go to our Marketing department. I have a business outcome I’m trying to achieve, but on the way to that outcome, I’m plugging into different organizational groups to leverage their skillsets for the best result. If I don’t know how to talk to Design or Marketing, I can’t delegate to them, and suddenly, my job gets harder, and the result likely won’t be nearly as good because I don’t have the expertise that those departments have.

 

This is how we wanted the new way of customizing, called client extensions, to work. The main difference between a plugin and a client extension is this: a plugin is something internal to the product, and a client extension is a service I can leverage from outside of the product.

Plugins are what we build and deploy in the product that are managed by Liferay’s portal container, whereas client extensions are components Liferay DXP is aware of and could possibly use but has no direct control or responsibility over. In this way, client extensions don’t interfere with core product capabilities.

 

Client Extensions: Flexibility for the Future

Client extensions are the brave new world of extending Liferay DXP. Again, the main attraction of this approach is that your extensions live outside of Liferay, eliminating those tradeoffs we talked about earlier:

1. No tech stack constraints. Except for the small amount of “glue” needed to bridge Liferay DXP and the system referenced by the extension, there are no management restrictions created by the portal container.

2. No fears of breaking API changes. Integration is now done via a versioned and open-standards based headless API, which frees you to update Liferay DXP without needing to upgrade your customization at the same time in lockstep.

3. Less overall investment. You don’t necessarily need your entire IT team to learn niche technologies or invest in outside developers. Now, you can use the expertise of your existing team with practically any technology to build solutions.

Okay, you might be saying, that sounds great. But what if I’ve already invested in plugins as part of my solution? Can I convert my plugins to client extensions?

 

Converting Plugins to Client Extensions

The first thing I do when I hear this question is counter with one of my own: does what you’ve built with a plugin need to be moved to a client extension at all? Many plugins developers have built in Liferay over the years can actually be replaced with out-of-the-box capabilities using configuration over code. We have 300+ capabilities, many of which you may not even be aware of!

Service Builder is a great example. In the past, that’s how developers could extend the Liferay data model to store entity information according to your specific organizational needs – i.e., modeling your business. Now, however, you don’t need to convert this to a client extension: you can use Objects to model the entity via the UI, and then leverage features like Content Management, Page Builder, and Fragments to capture the data and render it for users.

There may be cases, however, where you still need functionality not included in our out-of-the-box capabilities. (Always double and triple-check first, though.) In these instances, how much work it is to convert your plugin to a client extension depends largely on the complexity of your plugin or widget to begin with.

 

Additional Benefits of Client Extensions

Adding client extensions to the paradigm of the Liferay Customization Framework doesn’t just address the tradeoffs of the plugin model. There are additional benefits as well:

• Disparate teams can work in parallel. Teams can work autonomously and release on their own schedules instead of coordinating with our maintenance windows. So, for example, if your solution is a Customer Portal, and you have a team responsible for building and maintaining a tool like a quote calculator built using a client extension, that team can evolve, fix bugs, and release when they want to. 

• Client extensions and the resources they used can be scaled without Liferay. If this quote calculator suddenly becomes the most popular tool inside and outside your organization, you may need additional resources to keep up with demand. When the calculator is deployed in the Liferay portal container as a plugin, scaling up resources would mean scaling up Liferay DXP itself. But if you used a client extension, then the resources that are running the calculator live outside Liferay DXP, so you could ramp up with additional hardware, VMs, or containers without increasing the number of Liferay nodes. You’ll save on license costs this way as well.

 

Limitations

Like all software, the framework of client extensions is continuously evolving.

Although client extensions offer solutions to many customization needs, they don’t yet cover every use case that the traditional plugin model supports—yet.

If this happens and you’ve explored out-of-the-box capabilities thoroughly too, you may still need to build a plugin. We do still support plugins, but this method of deployment rules out the possibility of using Liferay SaaS to host.

And if you find yourself in these circumstances, here’s a fleshed-out version of the Liferay Customization Framework for deciding that age-old question of when to customize:

1. Make every effort together with Liferay or one of our trusted partners to find the functionality you need with out-of-the-box capabilities.

2. Repeat Step 1. Really!

3. After you’ve made sure you can’t cover your use case with out-of-the-box capabilities, look into your options with client extensions.

4. If client extensions absolutely won’t work either, turn to plugins. But make sure to architect your solution in such a way that you can take the plugin out easily later, either when a client extension or out-of-the-box capability becomes available.

5. Don’t keep what you need a secret! Please tell us about the gap, and why this feature you had to add as a customization is so important for your business.

Have an idea already? Drop us a line at [email protected]. 

 

Conclusion: The Future Is Up to You

Now you have the bigger picture of why we made the shift from the old plugin model to the new world of client extensions. 

And as much as I love plugins and will always have a soft spot for them, I’ve made room in my heart for client extensions after seeing their potential. Client extensions still carry the heritage of Liferay with them, what’s been special from the beginning—giving our customers the opportunity to continue pushing the boundaries of what’s possible in order to meet, and exceed, business needs.

 

 

Author: Andrew Jardine, Lead Solution Architect at Liferay