Api

1.1. Implementation

The API should provide CRUD operations along with ERP specific implementations.

The API should be implemented in such a way to express screen models configured on the backend.

Use Feathers JS or another provider (socket.io, express, RabbitMQ) for backend-frontend synchronization.

It should be possible to request to include or hide specific fields from data access (CRUD or API implementation) or return all.

Deep read level should be implemented (i.e. reading child entities) but with caution because deep joins take a lot of time (tested with Entity Framework and Postgres).

Reads of child entities should be done only for what is displayed, but note that too many requests to load data will slow down the UI. You have to find a way to delegate those reads to a deep level reader if any child entities must be read for a parent, immediately after or at the same time that the parent is loaded, so the joins will be done on the database and served all at once.

All data should be served translated by the backend. The backend should also serve entity configurations and display options for the fields.

All display data, drop down options and frequently requested data should be cached (if marked as such) and it should be ordered by its cached and last used timestamp in order to be removed from cache to release memory.

1.2. Security

The security service must generate JWT tokens for authentication.

A plugin will automatically generate firewall and proxy/gateway rules from the entity security configurations.

All requests will contain the Bearer http header, containing the JWT provided by the Authentication service.