Table of Contents

Architecture - frontend

The application is divided into 2 technological lines: backend (java) and frontend (javascript). There is a REST interface between the two.

Compared to BE, the development of FE began with a few months head start. The aim was to use the new FE over the original BE for CzechIdM for the access of endpoint users - as the user interface. The administrator part of the user interface would remain in the original CzechIdM. Therefore, within this concept, a major part of react components and pages for editing user profile, changing password and the like was created. Using the resteasy framework, REST services were built over the original CzechIdM BE.

My vision was to take FE as it is and build REST under it with the same interface as over the original BE. In the end, we opted for a few conceptual changes, which will be further described in the backend chapter.

We are now building a client running on the (Browserify) client using the technologies mentioned above - in the future, it might be necessary to switch to an isomorphic web (NodeJS, Webpack). We are using the ES6 syntax (JS format).

Application modules

Core module

Contains services, managers, components and individual core pages. More in modularity and in the next chapter with layers.

App module

= Application, executable application. Connects modules with environment configuration. The minimal executable application always contains the app + core modules.

Application layers

Going from the bottom:

RestApiService ⇒ service (AbstractService) ⇒ manager (EntityManager, redux) ⇒ ui component (basic, advanced) ⇒ content (=stránka, AbstractContent).

and now in a bit more detail…

Loading of data from a REST endpoint is done by the service = service. The class AbstractService was created for a service with base operations. When creating a new service communicating with a REST interface, all it needs to be done is to inherit from this class and define the url of the REST endpoint (implement the getApiPath() method). Virtually all application services are children of this service since the REST endpoints are built with the given convention as well. RestApiService is used for calling REST. It calls physically the get, post, put, patch, delete operations on the url within the service.

The service is used by a manager (redux manager), which adds asynchronity (dispatch, promise) and state (reducer, getState()) to the service. Similarly to the service, there is an abstract class EntityManager for the manager, which needs to be inherited and then implement the getEntityType() and getCollectionType() methods - they state the name of the entity type which the manager will work with.

Managers are accessed by individual UI components (basic, advanced) and pages (AbstractContent), where the life cycle is controlled by redux:

  1. action start (requesting data loading, saving …) e.g. this.context.store.dispatch(manager.fetchEntities()) Notice that the manager operation is not called directly, but through redux context in order to send the action and the result through redux (action = dispatch + stated = reducer).
  2. listening to state with a result e.g. manager.getEntities(state). Since it is all asynchronous, the redux function connect is used for listening to state. The function is always called when the state changes.

All the described classes are in the core module and can be used in any application module (one by one, I will add links to the key words and used libraries in Git).