Modern enterprise applications are designed with the basic concept of separating the frontend from the backend.

These two layers have very different characteristics, and therefore, they require different approaches, in terms of the following:

• Software development and life cycle
• Resource management (CPU, thread, throughput)
• Scalability and service levels

For these reasons, all new applications, from those built with monolithic architectures to new ones designed with microservices, are released with components dedicated to the management of the backend and frontend.

While, for the backend components, Jakarta EE and MicroProfile have contributed to the creation of more functional specifications for the realization of cloud-oriented applications, the same cannot be said for the frontend components.

At the moment, the platform only provides full specifications for the server side while, for the frontend  layer, there is only one specification based on the concepts of component model, a flexible and ready-to-use user interface element—Java Server Faces (JSF).

Java EE/Jakarta EE 8 provides version 2.3 of JSF, which represents the standard user interface for building applications.

Although they have been completely revised starting from version 2.0, released in a concise form with JEE 6, JSF have progressively lost their appeal in the developer community, despite all the improvements enacted in the latest versions.

Numerous criticisms of JSF technology have been launched, the most famous of which was presented in the Technology Radar publication, available at https://www.thoughtworks.com/radar/languages-and-frameworks/jsf.

The main criticisms are as follows:

• The use of a shared stateful state inside the components
• The presence, in the same place, of the user interface and the business logic concepts

The JSF specification leaders have tried to respond to these criticisms (for example, in the article at https://www.primefaces.org/jsf-is-not-what-youve-been-told-anymore/), but without any great success.

To try to overcome the limitations found in JSF, it was proposed to create a new JSR, MVC 1.0/JSR 371, based on an action-based model, which should have been the answer to Spring MVC. But MVC is vetoed in the final stage and it still exists as a community-based specification.

Although I do consider Jakarta EE and extremely mature MicroProfiles for the realization of Java Enterprise and cloud-oriented applications, I do not consider it the right choice for the realization of frontend architectures.

Thorntail, from this point of view, only offers support to JSF through a specific fraction, as follows:

<dependency>
    <groupId>io.thorntail</groupId>
    <artifactId>jsf</artifactId>
</dependency>

For these reasons, the suggestion is to adopt a microservice architecture, even for frontend components, so as to be able to modify specific elements of the user experience without having to release the entire graphical interface, but with frameworks that follow the HTML 5 specifications (CSS 3 and ECMAScript).

There are numerous frameworks in this segment, as follows:

• Angular: https://angular.io/ 
• Bootstrap: https://getbootstrap.com/ 
• ReactJS: https://reactjs.org/ 

The basic idea is to divide the original monolithic frontend into multiple microservices, potentially written using different languages and frameworks, and to coordinate them using the concept of a micro frontend.

This term is the equivalent of a microservice backend, but related to the frontend world.

The basic idea is to build a single-page application that is a composition of features implemented by dedicated microservices.

As was described for the backend microservice, the micro frontend should be organized into vertical teams responsible for implementing specific areas of the user experience.

Every single micro frontend can be implemented with the technology that the team evaluates as being best in terms of business requirements

Finally, you can have a sort of aggregator single-page application that invokes the micro frontends, in order to build the final user experience.

This approach gives you the ability to do the following:

• Be technologically agnostic: Make the team free to choose the technology.
• Isolate the team code: The applications are independent and self-contained. In this way, every micro frontend can have a dedicated life cycle.
• Favor native browser features over custom APIs: In this way, you can build a more effective and easily portable user interface.
• Build a resilient site: Through the use of JavaScript that is asynchronous, and it's designed for native manages the failure.

Building a user experience is beyond the scope of this chapter, since we are evaluating the features of Jakarta EE in Thorntail. For that reason, I will show you a quick way to create a user interface for your specific microservice, in order to test the APIs in a way other than the JUnit test.