Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | Last revision Both sides next revision | ||
devel:documentation:architecture:dev:backend [2018/03/23 09:16] stloukalp |
devel:documentation:architecture:dev:backend [2019/05/02 05:27] kopro [Spring] add tutorial |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Architecture - backend ====== | ||
+ | |||
+ | {{tag> | ||
+ | |||
+ | {{indexmenu_n> | ||
+ | |||
+ | Backend is based primarily on the Spring and Activiti workflow technologies. | ||
+ | |||
+ | ===== Application layers ===== | ||
+ | |||
+ | Going from the bottom: | ||
+ | |||
+ | Entity ('' | ||
+ | |||
+ | Creating a child of each one of the classes above is sufficient for issuing a new REST endpoint for the new agenda (entity). | ||
+ | |||
+ | And now in a bit more detail ... | ||
+ | |||
+ | ==== Relational database ==== | ||
+ | We are expecting to use the relational databese through a jdbc connector. Primarily, we are going to use '' | ||
+ | |||
+ | ==== Hibernate ORM ==== | ||
+ | Using of Hibernate is a logical choice, nothing changes/ will change about that. We will keep creating '' | ||
+ | |||
+ | Setting the cache selectively for the individual operations: https:// | ||
+ | |||
+ | ==== Spring ==== | ||
+ | |||
+ | The application is superordinate to the [[https:// | ||
+ | |||
+ | * Spring Data | ||
+ | * Spring Security | ||
+ | * [[.: | ||
+ | * AOP (aspectj) | ||
+ | * [[.: | ||
+ | * ... | ||
+ | |||
+ | === Spring Data === | ||
+ | |||
+ | Spring Data facilitates the work with the ([[http:// | ||
+ | |||
+ | Intended extensions: | ||
+ | - support of searching through standard jpa criteria for more difficult queries via [[https:// | ||
+ | |||
+ | === Spring Data REST === | ||
+ | |||
+ | <note important> | ||
+ | Spring Data REST are used as helper for rest layer initialization only (convertors, | ||
+ | </ | ||
+ | |||
+ | Dto layer is created above entities - services ('' | ||
+ | Dto can be identified by '' | ||
+ | |||
+ | Advantages of Spring Data REST (not used now): | ||
+ | * hal - uses Spring hateoas | ||
+ | * documentation directly at REST - annotation, apls | ||
+ | * projection(in the manner of trimmed view), | ||
+ | * securing through annotations, | ||
+ | * < | ||
+ | * patch method | ||
+ | * versing(ETag) - usable for optimistic locks | ||
+ | * last modification of resource | ||
+ | |||
+ | Disadvantages of Spring Data REST (not used now): | ||
+ | * Non-existence of service layer (only repositories) | ||
+ | * Non-existence of service layer (mapping to dtos) - I consider this so important that I have mentioned it twice. REST controllers are issued directly from entities, or rather from spring data repositories, | ||
+ | * links with an absolute pathway to BE are used as entity identifiers (e.g. http:// | ||
+ | |||
+ | === Spring Security === | ||
+ | |||
+ | The Spring Data layer, REST or services themselves can be supplemented with annotations evaluating security (before or after calling). A logged-in user can be used favorably as an input for search queries (e.g. queries like "give me subordinates" | ||
+ | |||
+ | == Authorities model == | ||
+ | |||
+ | **Authorities** (hasAuthority), | ||
+ | |||
+ | To make assigning permissions to a role easier the following interfaces are created: | ||
+ | * '' | ||
+ | * '' | ||
+ | |||
+ | Assigning permissions to a role is represented by this pair: | ||
+ | * **target** - target permission - an instance of GroupPermision | ||
+ | * **action** - base permission - an instance of BasePermission | ||
+ | |||
+ | When evaluating, target and action acts as an authority **target\_action** (e.g. USER\_READ). | ||
+ | |||
+ | Each module can register its own set of permissions (both a new group, and adding new base permissions to an already existing group). | ||
+ | |||
+ | Each role has its own type (system, business, technical ... ) according to application settings. | ||
+ | |||
+ | [[..: | ||
+ | |||
+ | ==== Workflow ==== | ||
+ | |||
+ | We have chosen [[http:// | ||
+ | |||
+ | One of the advantages is its integration with Spring framework and therefore its easier application in our devstack. Activiti Platform allows us to issue a REST interface through which most functions can be controlled, i.e. it is possible to have Activiti Platform + REST interface running on the application server and communicate with it even from a non-Java environment. A disadvantage of this solution is the loss of direct Java integration, | ||
+ | |||
+ | ===== Backend functional requirements ===== | ||
+ | |||
+ | ==== Logging ==== | ||
+ | |||
+ | [[..: | ||
+ | |||
+ | ==== Notifications ==== | ||
+ | |||
+ | [[..: | ||
+ | |||
+ | ==== Audit ==== | ||
+ | |||
+ | [[..: | ||
+ | |||
+ | ==== Log locking ==== | ||
+ | |||
+ | We expect to use optimistic locks on key entities. Auxiliary entities will not be locked - the last to come is the winner. If needed, it will be possible to engage an optimistic lock on any entity. The use of pessimistic locks is not expected yet. | ||
+ | |||
+ | Regarding the user interface, the `ETag` and `LastModified` headings are planned to be used for informing the user about changes made by somebody else in his currently edited log + a mechanism for using my changes or reloading the changed log. | ||
+ | |||
+ | The solution assumes that the objects will not be kept loaded (outside of the UI) for long in order not to break the optimistic log. At the same time, it is necessary to keep the transaction processing over the object being changed. | ||
+ | |||
+ | |||
+ | Optimistic lock is engaged on entities: | ||
+ | * Identity | ||
+ | * Organization | ||
+ | * Role | ||
+ | |||
+ | ==== Provisioning a synchronization ==== | ||
+ | |||
+ | [[..: | ||
+ | |||
+ | ==== Performing actions always under a user ==== | ||
+ | |||
+ | TODO: Guest, system | ||
+ | ... | ||
+ | |||
+ | |||
+ | ===== Non-functional requirements ===== | ||
+ | |||
+ | ==== CI/CD ==== | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | ==== Open source ==== | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | ==== Public demo ==== | ||
+ | |||
+ | Application profiles configured: | ||
+ | * [[..: | ||
+ | |||
+ | ==== Testing ==== | ||
+ | |||
+ | [[..: | ||