05. Portlets as "micro-frontends"

Date: 2018-05-23

Status

Accepted

Context

Microservice architecture discussion seldomly includes tips how to deal with the UI. Usually UI is thought to be one big monolith communicating with all microservices behind the scenes. That brings problems when you want to give UI pieces to different teams, use different stacks and version/deploy them seperately.

Micro-frontends ignited some discussion, for example in here and here. They are also tracked in ThoughtWorks technology radar.

In Liferay world we have certain restrictions but fortunately also somewhat ready-made solution to decomposition. Current Valamis uses Liferay portlets that can be seen as a form of micro-frontends as they encapsulate UI logic to their own code base and they are deployable separately.

Decision

Continue to get benefits from potlet concept until alternatives of UI decomposition are researched on.

Consequences

Pieces of UI can be developed by dedicated teams. Additional benefit is that we can deploy many external/3rd portlets that are adding additional features to Valamis installation. Portles can be also added to Liferay pages dynamically with flexible layouts.

Problems arise from the conflict between Liferay porlets, the idea of micro-frontends and modern JavaScript web developments. Server rendering, bundling/building and other usual feats of frontned development become more complex when we don't have monolithic frontend. These problerms should be solved with future ADRs.

Another problem is that clearly fragmented UI is not the best way to reach the optimal UX. In the future portlet's role in Valamis is most likely reduced with fewer actual portlets.