OMS Frontend design

This page serves as providing a current overview of the state of the frontend, and the ideas we have for the future.

Since the future design will differ quite a lot from the current design, this page will mainly serve as a placeholder until that time.

Current design

The current design of the core is one that has a lot of legacy design elements in it: There are new ideas (see below), however these are postponed for now.

The biggest design factor right now is the fact that the frontend of the entire system is still intertwined with the core, the frontend is in the same repository and same container as the core. Due to this it communicates differently with the core as it does with other micro services. Aside from that development is somewhat slowed down because of this.

The current design also still makes use of (backend) modules and module-pages, these things are solely left in for legacy purposes.

When working on something related to the core, one should take into account these upcoming changes.


Future design

In the future we want to have a full stand-alone frontend repository and container. It would have to communicate with the core as it would have to communicate with any other microservice. Additionally, the plan is to remove the concept of modules within microservices, and instead leave this option to the frontend / registery.

Plans have changed a bit by now, In short: Backend has no modules, frontend has modules:

  • Every service will have a seperate backend and frontend container
    • The backend container will consist of the backend, containing all the logic and data. It will expose a REST API.
    • The frontend container uses the API endpoints of the backend container to fill the module view with data. Frontend-modules consist of actual Angular pages injected into the final webpage
  • There will be 1 central frontend service
    • This container will have the responsibility of combining several frontend-modules into 1 final webpage.
  • The service-registry will have the responisbility of creating an overview of the frontend-modules and offering this information as an API endpoint

This page is largely based upon the following discussions that took place on JIRA:

GENERAL-84 - Getting issue details... STATUS

GENERAL-85 - Getting issue details... STATUS