... just FYI: new command processing has been merged into the develop branch.
On Fri, Apr 18, 2025 at 12:01 PM Aleksandar Vidakovic <al...@apache.org> wrote: > 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 >
