How to solve the problem with the organization of a web application when monolithic approach is not feasible? Why does server-side rendering deserve a comeback? Do micro frontends make any sense? This article shall discuss how the topic of the segmentation of web applications into smaller fragments can be handled.
Introduction
The architecture of microservices is taking its position in the projects related to the scalable web solutions by storm. It works perfectly now that a single platform is not the most adequate tool to provide complex solutions in the face of challenges posed by the project. Additionally, the possibility of simultaneous work on various parts of the solution in different technologies allows for the work to advance fast.
Dynamic loading
An interesting way of organizing architecture is the approach based on dynamically loaded components. Systems of content management are a frequently mentioned topic in the discussions on such solutions. The concept is based on adding an extra abstraction layer intended for the management of the component layout on the page. “Project Mosaic” may serve as an example of that. It is based on server-side rendering. In the first place, the internal routing mechanism based on information from API decides which parts of the application are required in a given moment. After transmitting this information on to the system management service, the service loads and dynamically shares the components.
Drawing 1. Architecture based on dynamically loaded components.
Afterwards, on the client’s side, thanks to Fragments API from React and the system of dynamic module loading, require.js, we get a fully functional web application.
Routing and server side rendering
In its basic version, the routing itself together with the division into fragments may turn out to be sufficient. If we, however, wish to target a more complex solution with a deeper bundle separation into parts, we will have to properly address the topic of our own, often platform-specific, approach to server-side rendering. It is worth mentioning at this point what it is to move from components understood as static Java script files combined into a whole in the form of a bundle, to components defined as JSON.
Listing 1. [JavaScript] Example of a functional component React
Due to the declarative nature of the component representation in React, this does not cause major trouble. In order to transform components on a larger scale, it is worth recurring to libraries such as react-json-renderer.
Listing 2. [JSON] Example of a component React after converting it to JSON format.
Fragment update is based on standard communication through REST API with the system management service. This permits to manage changes in particular components in an easy and scalable manner, which allows to separate them from each other completely.
When creating such solutions, various factors must be taken into account, such as efficiency requirements, possibility of division of tasks among developer teams, module synchronization, target quality level, and the required scope of configurability. The fundament on which building such a system should be based is the preparation of the testing environment that would meet the target criteria the solution must fulfill. Model application on such an early stage helps avoid problems related to the scope of configurability being too vague or solution optimization occurring too early on.
Summary
Apart from its numerous advantages, the above described model is based on the separation on the level of particular components. This translates into additional workload related to the scaling and queueing internal communication in order to fully use the opportunities such division has to offer. Another point worth considering are the questions of dependencies shared among the components and communication between the components during the application’s operation.