Architecture - frontend
The application is divided into 2 technological lines: backend (java) and frontend (javascript). There is a REST interface between the two.
- FE - Frontend (javascript)
NodeJSGulpReactJS(view layer)React router(page navigation)Redux(non-invasive handing of events, keeps the whole application status)React redux router(integration of router + redux for calling the navigation status)React Bootstrap(overusing of some of the components)
Babel(allows writing of ES6 … makes conversion to ES5, also procures JSX → JS translation)Browserify(loader/dependency module)BrowserSync(changes in the source code will take effect immediately)Chai,Mocha(testing)lodashImmutable(saving the application status in immutable structures - Map, List …)Isomorphic fetch(client communication with REST services)i18next(localization)- … other see
package.json
- BE - Backend (java)
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.
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:
- 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). - listening to state with a result e.g.
manager.getEntities(state). Since it is all asynchronous, the redux functionconnectis 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).