Micro Frontends: Liferay Portlets approach. Part 2

In the previous article we described how the Micro frontends approach works. In our case we are going to use Liferay as frontends container.

Every micro frontend is going to consist in a Angular Application inside a Spring MVC portlet architecture. Here below you can find an example of a portlet application.

Angular Portlet Example

In order to facilitate all the developments we have created a basic Angular Portlet Archetype with a basic functionality.

This Angular portlet application is structured in 3 different parts:

1. Angular application

Inside src/main/angular, a standard angular app is located. Like other angular apps, there is a component folder, service folder, model folder and styles folder.

Angular application

2. Spring MVC Controller

In src/main/java folder, Spring MVC Controllers and all the Java classes needed for all the operations executed are located.

Spring MVC Controller

3- Liferay Portlet configuration

In webapp folder, all the configuration files needed for a Liferay portlet are located.

Liferay Portlet configuration

Maven is the tool used to compile and build the code. The execution of mvn clean install is generating a WAR file ready to be deployed in a Liferay portal.

Taking in account the following structure, an example of a business interaction from FE to an external BE on Liferay is:

Portlet Workflow

IPC (Inter-portlets communication)

Even using this micro frontend architecture, in some cases we will need to propagate some information or event between different portlets. For that type of communication Liferay offers different possibilities.

Inter Portlet Communication is the way of making communication among different Portlets which are in same page or reside in other pages.

In the IPC mechanism Portlet will share data among the Portlets and Portlet will work based on the other Portlet.

IPC Events is one of the ways to make Inter Portlet Communication among the Portlets and these Portlets may be in same page or different pages in the portal.

IPC Events we have two categories of Portlets:

  • Event Producer Portlet will send some data or push some data
  • Event Listener Portlet will receive the data and will process subsequent steps.

We can have one Producer and Multiple Consumer Portlet will listen the event and process subsequent steps.

In the case of our archetype, it is the producer and the listener in order to have both examples in the same portlet. In this code you can see the producer part, where an custom event is launched in a specific method.

 public launchEvent() {
    console.log('Event sent: ' + this.text);
    this.liferay.fire('test-event-1', {data: this.text});

This event is going to be listened by the following section of code:

    if (this.liferay != undefined) {
        this.liferay.on('test-event-1', this.myAlert.bind(this));

This event is going to be propagated through all the pages and portlets in a Liferay portal.

How to test it and deploy it?

Every portlet is going to contain its own unit test in order check the basic functionality of it. As I mentioned in our previous article, every frontend is going to have its own pipeline and only the successful builds are going to be deployed in the portal.

Microfrontend pipelines

This pipeline is going to check that these unit tests are executed correctly and that our app achieves our quality gates (code quality, code coverage, etc.).

This way we are sure that every portlet is reaching our quality standards, but we cannot forget that all this portlets have to be correctly integrated and deployed in our Liferay portal and that from our clients perspective this is going to operate as a unique Frontend application.

In order to test the complete application and check that the integration of all the portlets is correct, we have created a specific E2E project using Cypress (https://techblog.fexcofts.com/2018/09/24/end-to-end-e2e-angular-testing-protractor-vs-cypress/) to test our app with multiple E2E scenarios.


– Easy integration and deployment

When the war file for the portlet is generated, it is very easy to deploy. Also to configure the different layouts between them is very intuitive.

– Inherited Styles from Liferay Theme

If a specific Theme is created for our Liferay portal. It is going to be inherited by all our portlets, so it is not necessary to specify these custom styles in every app, avoiding duplications.

– User management

Liferay provides a powerful User management functionality for user, groups and roles, saving development time and costs. It is easy to allow pages or portlets only for specific users or roles.


– Liferay Technical limitations

In our case we have not found a specific limitation for our angular apps in Liferay yet, but like in all the technologies when you are using a container, any limitation of this container is going to be propagated to our specific developments.

– Lack of documentation Angular portlets

Liferay community is very active, but for the specific case of angular portlets there is a lack of documentation. Most of the examples or problems described are based on other FE technologies (JSP, JSF…)

Author: Pablo Nuño

Fexco Senior Software Engineer

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.