Using Custom Elements as Remote Applications

Until now, this module has focused primarily on custom element client extensions as a modern alternative to traditional Liferay widgets. This is a powerful capability with which you can develop decoupled customizations while still leveraging native functionality, like the headless API or the Liferay JavaScript object that is available on every Liferay page. When you implement custom elements as widgets, they run outside of the portal container; however, because they use resources or utilities that are exclusive to Liferay pages, the client extensions remain partially tethered to Liferay.

For the vast majority of use cases, this dependency is perfectly fine, and even preferable. If you are implementing frontend functionality for a Liferay page, it makes sense for the custom element to depend on Liferay resources. However, custom elements are not limited solely to the widget use case. You can take them a step further and implement custom element client extensions as remote applications.

Making a Custom Element Remote

In the standard widget use case, the deployable ZIP archive for a custom element client extension contains two key components:

1. The client-extension.yaml file, which contains the metadata for the client extension.
2. The .js file(s), which contain the entire application logic.

In the remote application use case, the ZIP archive contains only the metadata for the client extension, i.e., the client-extension.yaml file. Instead of bundling local JavaScript files, the metadata references a URL pointing to the remote application code.

A detailed explanation of how to build custom elements as remote applications is out of scope for this course. However, it’s still important to understand what is possible with this client extension and why you might want to deploy custom elements in this manner. To illustrate the value of this use case, consider the following scenario.

Implementing a SaaS Vacation Tracker

Your enterprise already has a React application for tracking and logging vacation days. Employees can access and interact with this application directly. Now, the company has decided to use Liferay to build an employee dashboard, along with other features. To unify employee services within a single interface, you want to integrate the vacation tracker into the dashboard. This is a great opportunity to use a custom element client extension to bring your React app into Liferay and treat it as a widget.

However, duplicating the application files in the client extension project would create unnecessary maintenance overhead. Since the vacation tracker already has its own hosting setup, you can implement your custom element as a remote application, referencing the app by its URL instead of duplicating its files.

Your enterprise recognizes the value of the vacation tracker application and wants to package it as a SaaS offering. Customers can either use it as a standalone application or integrate it into their own Liferay solutions. In both cases, you, the vendor, would host and manage the application.

Not all employees and customers need or want access to Liferay just to log vacation days. By maintaining the standalone app, you deliver the same functionality without forcing users to purchase a Liferay license. For those already using (or planning to use) Liferay, the custom element client extension is a plug-and-play solution.

In summary, by using custom elements as remote applications, you can enable third party integrations that improve the flexibility and market agility of your solutions.

Conclusion

While custom element client extensions are primarily used as an alternative to traditional widgets, you can fully untether them from Liferay as remote applications. This use case can make your custom element solutions even more flexible and cost-effective, while also opening up new market opportunities and enabling third party integrations. Next, let’s review what you’ve learned in this module.