we are actually evaluating the CUBA as a UI platform for our enterprise Apps. In general, we have a number of highly automated workflows, but we still require a number of ‘Apps’ that are capable of displaying and mutating business states by ‘human’ users.
We also adapted the ‘microservices’ pattern, where a number of back-office App ‘owns’ a context over a dedicated Domain Model (DM) and business logic. The back-office Apps are structured as follows:
i) API (we are using a RPC-based API using gRPC and proto3 as IDL)
ii) The business logic is implemented in Java
iii) App ‘state’ is stored in a relational data model using JOOQ
The question is now if CUBA is capable to deal (read AND write) with the RPC based back-office API. As we understood CUBA offers an ‘AbstractNotPersistentEntity’ approach, where the corresponding entity is programmatically created/mapped using arbitrary API
In summary, the questions we still have are:
How does CUBA support ‘write’ API calls? If a property of an AbstractNotPersistentEntity is mutated - how does CUBA trigger the state change?
CUBA offers a lot of standard functionalities like security, traceability of user actions, etc. Are this features available even when AbstractNotPersistentEntities are involved?