Thanks, Aleks for the update and for coordinating this effort! Regards, Terence Monteiro.
On Wed, Apr 23, 2025 at 1:22 AM Aleksandar Vidakovic <al...@apache.org> wrote: > ... 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 >> >
