Hi everyone, ... I'd like to point your attention to the new command processing component. For those that didn't see this proposal, please follow these links for details:
- Jira: https://issues.apache.org/jira/browse/FINERACT-2169 - Wiki: https://cwiki.apache.org/confluence/display/FINERACT/FSIP-5%3A+New+command+processing+infrastructure Viktor and Oleksandr already prepared a ton of REST resource classes to have proper Java types (instead of the String blobs). This will make maintaining the OpenAPI descriptor much easier. To be simplify maintenance from top (REST resource classes) to bottom (business logic services) the new (type safe) command processing component is needed. Have a look at the unit tests and the refactoring instructions (work in progress) to see the impact this will have on developer productivity and being able to remove (a ton) of boilerplate code related to manual JSON parsing. There will be no more Google GSON use and everything will be handled by Jackson (mostly) without adding a single line of code related to JSON de-/serialization. As I said in a previous email, we'll start to migrate some non-critical services first (SMS campaign, document management...). We'll adjust things as needed, but will try hard to keep that component: - independent of anything else in the Git repo - simple and minimal (takes 5min to read the code) - focused on one specific goal: processing commands So, if you ask how maker-checker will be handled: this was/is baked into the current command processing infrastructure, but in fact belongs more to the security domain. I'll draft a different proposal for that... taking into account that we maybe want to have a more modular security stack. The services we are targeting now are not affected by this. Performance: I showed some of you that the new command processing will be able to handle command execution in 3 performance levels: - synchronous (that's how we do things now anyway) - asynchronous (with CompletableFuture etc.; should be interesting to see with virtual threads enabled) - non-blocking using the LMAX disruptor library (just to have another completely different approach to the 2 obvious ones) While the mechanics are already working pretty nicely in the unit tests, async and non-blocking processing modes will need separate extensive testing and therefore are out of scope for the current migration effort. We'll circle back to them later when we are done and/or have some time for this. One thing that needs to be ensured is that all ThreadLocal variables are available in those execution contexts (especially async). But again, that's for another day to keep things simple. The goals for this round now are: - type safety everywhere - remove any reference to the API communication protocol (JSON) from the business logic services (no more JsonCommand etc.) - get rid of manual JSON parsing - simple to understand and easy to debug command processing mechanics So... please checkout the PR at https://github.com/apache/fineract/pull/4281 and send your comments (or just leave a -1/0/+1). Big thank you to Victor Romero and Adam Sagy who reviewed the PR and already approved it. Cheers, Aleks
