Hi Paul, Thank you for the kind words. I highly appreciate your business perspective and the willingness to help.
Standardized/automated testing of core API endpoints involved in loan product creation is definitely a valuable outcome. However, I see that the community has already invested a lot of effort into various testing approaches, like huge sets of integration tests or newer cucumber's ones. There are multiple proposals, how to clean this up, like https://cwiki.apache.org/confluence/display/FINERACT/FSIP-4%3A+Cucumber+Testing+Framework I definitely do not have any spare capacity this quarter for helping Fineract with the QA/testing, but I think you can start writing down the requirements for what you want to achieve. With a strong proposal in hands, it might be much easier to find a suitable contributor for your needs. I am currently fully committed to building the performance offer this quarter and I planned the relevant resources specifically for this kind of work. That means my support in other areas might not be as effective as it could be. Please do not hesitate to write about any Fineract performance issues you are currently struggling with - it might be possible we will be able to help you with them within the upcoming weeks. Regards, Jakub. On Fri, Apr 4, 2025 at 2:13 PM Paul <pchristi...@gmail.com> wrote: > Fineract Community, > > Jakub offer is a significant opportunity for project improvement and is > greatly appreciated. > > Techies, what is the top one or two Fineract performance issues that you > believe would yield the greatest benefit if resolved? Alternatively, what > is the primary architectural or design inconsistency that prompts you to > question the original development approach? > > As a business person, and one of the newer members on this list, issues > which center on the need for consistent and efficient outcomes directly > impact business operations. TIME matters. Specifically, I propose the > development of a standardized, automated testing script or tool for core > API endpoints involved in loan product creation. This would entail: > > - Identifying critical API endpoints within the loan product creation > workflow. > - Developing a Postman collection, or equivalent, with predefined test > cases and environment variables. > - Implementing robust automated test scripts to validate API responses > against expected outcomes. > - High flexibility in testing while maintaining sanity and consistent > results. (If its brittle, it breaks.) > - Packaging the above into a user-friendly and accessible method to > those with varying technical expertise. (in other words, that even I could > use without need of a developer's time.) > > *Jakub, * > > No idea if this is in the realm of what you are looking for. But, SHOULD > you proceed with *this* use case, input on loan scenario types and a > defined scope of included loan types will be necessary. I can assist with > business-related inquiries, surveys, and the compilation of loan type > descriptions and profiles. The dynamic nature of loan products, such as the > emergence of Buy Now, Pay Later (BNPL), necessitates a method for > community-driven test stack expansion without chaos, compromising system > stability or requiring users to execute irrelevant tests. Establishing > parameter limits for a use case for automated loan testing is crucial. > Regards > Paul > > On Fri, Apr 4, 2025 at 3:13 AM Jakub Sławiński > <jslawin...@soldevelo.com.invalid> wrote: > >> >> Hi Arnold, >> >> no, it is exactly the opposite - the bigger impact the better. >> >> Since fineract might require a huge volume of data and the transactions >> might be time-sensitive, it is a perfect project to show our expertise. >> This is why I am asking for a real challenge, not a few outdated tickets. >> >> Regarding a minimal effort focusing on quick gains - I've been selected >> Star Contributor of the Month for January 2010 (more than 15 years ago) in >> Mifos (predecessor of Fineract) and I am still supporting many open source >> projects since then. >> >> Arnold, are you aware of any real business problem that can be addressed >> in Fineract? >> >> >> Regards, >> Jakub. >> >> On Fri, Apr 4, 2025 at 9:58 AM Arnold Galovics <arn...@apache.org> wrote: >> >>> Hi Jakub, >>> >>> May I ask why you chose Fineract for this? I feel like you just wanna >>> get through this with as minimal effort as possible so that you can make a >>> case study out of it without making any real impact on Fineract - and I >>> hope you don't get offended by this because it wasn't meant to be. >>> >>> Best, >>> Arnold >>> >>> On Fri, Apr 4, 2025 at 9:07 AM Jakub Sławiński >>> <jslawin...@soldevelo.com.invalid> wrote: >>> >>>> Hi James, >>>> >>>> I think I was not clear enough in the previous email, maybe due to the >>>> list's moderator that is blocking links. >>>> >>>> The success case I am looking for is exactly about focusing on one >>>> perspective - the most painful performance related problem you have. >>>> >>>> Please take a look at the other cases we have published: >>>> - Not every optimization takes months: openIMIS performance improved >>>> by over 95% in just one week! >>>> - Not every optimization takes months: How we boosted a key API >>>> endpoint by 56% in just one week >>>> - How we improved OpenLMIS import performance by over 90% >>>> >>>> I would like to have one more about Fineract. >>>> >>>> Are you able to identify such a place? >>>> >>>> >>>> Regards, >>>> Jakub. >>>> >>>> On Fri, Apr 4, 2025 at 2:14 AM James Dailey <jdai...@apache.org> wrote: >>>> >>>>> Jakub - Thanks for sharing the perspective. >>>>> >>>>> I think the challenge is that from a project perspective, having >>>>> another audit is useful but doesn't actually advance the project if we >>>>> don't have the follow up. It is a form of contribution, so I am >>>>> supportive >>>>> of it.... but ... >>>>> >>>>> With a number of people looking at the code and project and >>>>> identifying a myriad of issues over a long period of time, it's pretty >>>>> clear that identifying more issues isn't the solution. >>>>> >>>>> What might be useful is to run a code "audit" and focus on one >>>>> perspective - such as making the code more maintainable and approachable. >>>>> The "performance" gain we need is speed of developer onboarding, test >>>>> environments, speed of builds. It could be a good baseline audit, and >>>>> could focus attention on an important area of improvement which could then >>>>> speed up addressing other issues. >>>>> >>>>> Also, any "audit" results may result in some security issue >>>>> identification - so please follow best practice and send those to >>>>> <security AT fineract.apache.org> private list. >>>>> >>>>> Thanks, >>>>> James >>>>> PMC >>>>> >>>>> >>>>> >>>>> On Thu, Apr 3, 2025 at 12:24 PM Jakub Sławiński >>>>> <jslawin...@soldevelo.com.invalid> wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> Unfortunately, it is not what I am looking for. >>>>>> The set of old issues from the backlog, general areas for improvement >>>>>> or challenges older than a decade - these do not sound like something >>>>>> important or valuable to anyone. >>>>>> >>>>>> I think I haven't shared the bigger context with the community. >>>>>> >>>>>> What we are looking for is to get one more success case for the >>>>>> service we are currently tuning up: Java Performance Scalability Audit >>>>>> >>>>>> What business problems are we targeting? For example: >>>>>> 🚀 *Performance-Related Issues* >>>>>> >>>>>> 1. >>>>>> >>>>>> *Slow Application Response Times* – Users experience delays, >>>>>> leading to frustration and lost engagement. >>>>>> 2. >>>>>> >>>>>> *High Server Costs Due to Inefficiencies* – Unoptimized code >>>>>> leads to excessive resource consumption, increasing infrastructure >>>>>> expenses. >>>>>> 3. >>>>>> >>>>>> *Frequent System Crashes or Downtime* – Poor memory management, >>>>>> threading issues, or resource leaks causing instability. >>>>>> 4. >>>>>> >>>>>> *Unoptimized Database Queries* – Slow or inefficient database >>>>>> operations causing bottlenecks. >>>>>> 5. >>>>>> >>>>>> *Poor User Experience (UX) Due to Lag* – Slow interactions drive >>>>>> users away and harm customer retention. >>>>>> >>>>>> 📈 *Scalability Challenges* >>>>>> >>>>>> 6. >>>>>> >>>>>> *Inability to Handle Increasing User Load* – System struggles >>>>>> with growth, leading to degraded performance. >>>>>> 7. >>>>>> >>>>>> *Lack of Proper Load Balancing and Caching* – Inefficient >>>>>> resource distribution leading to slow responses under load. >>>>>> 8. >>>>>> >>>>>> *Unscalable Architecture* – Design flaws preventing efficient >>>>>> horizontal or vertical scaling. >>>>>> 9. >>>>>> >>>>>> *Microservices Bottlenecks* – Inter-service communication issues >>>>>> causing slowdowns or failures. >>>>>> 10. >>>>>> >>>>>> *High Latency in Distributed Systems* – Delays in API responses, >>>>>> messaging queues, or inter-service communication. >>>>>> >>>>>> 🔍 *Technical Debt & Code Maintainability* >>>>>> >>>>>> 11. >>>>>> >>>>>> *Legacy Code with Performance Bottlenecks* – Old, unoptimized >>>>>> code making enhancements difficult. >>>>>> 12. >>>>>> >>>>>> *Lack of Monitoring and Profiling* – No visibility into >>>>>> performance issues until they cause failures. >>>>>> 13. >>>>>> >>>>>> *Memory Leaks and Inefficient Garbage Collection* – Leading to >>>>>> crashes and sluggish performance over time. >>>>>> 14. >>>>>> >>>>>> *Threading and Concurrency Issues* – Poor multi-threading >>>>>> implementations causing deadlocks or slow execution. >>>>>> 15. >>>>>> >>>>>> *Security Risks Due to Inefficient Code* – Performance weaknesses >>>>>> that also expose vulnerabilities. >>>>>> >>>>>> 💰 *Business Impact & Cost Reduction* >>>>>> >>>>>> 16. >>>>>> >>>>>> *Lost Revenue Due to Performance Issues* – Sluggish applications >>>>>> reduce conversion rates and customer trust. >>>>>> 17. >>>>>> >>>>>> *Missed SLAs (Service Level Agreements)* – Performance problems >>>>>> leading to contractual penalties or lost clients. >>>>>> 18. >>>>>> >>>>>> *Unnecessary Infrastructure Scaling* – Overprovisioning cloud >>>>>> resources instead of optimizing code. >>>>>> 19. >>>>>> >>>>>> *Poor DevOps Efficiency* – Developers wasting time >>>>>> troubleshooting performance instead of building new features. >>>>>> 20. >>>>>> >>>>>> *Long Release Cycles Due to Performance Issues* – Slow debugging >>>>>> and testing caused by unoptimized code. >>>>>> >>>>>> >>>>>> >>>>>> What would I like to see as the results of this particular success >>>>>> story? For example: >>>>>> >>>>>> 1. Cut infrastructure costs by 50%. >>>>>> 2. Increase the number of clients/transactions handled in a stable >>>>>> manner without changing infrastructure by 100%. >>>>>> 3. Decrease the time needed by critical operations by 70%. >>>>>> >>>>>> What do you think? Are there any business problems we could help you >>>>>> with? >>>>>> >>>>>> Please contact me directly if you are ready to check our services. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Jakub. >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Jakub Sławiński* >>>>>> Chief Technical Officer >>>>>> jslawin...@soldevelo.com / +48 514 780 384 >>>>>> >>>>>> >>>>>> *SolDevelo* Sp. z o.o. [LLC] / www.soldevelo.com >>>>>> Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland >>>>>> Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41 >>>>>> >>>>> >>>> >>>> -- >>>> >>>> *Jakub Sławiński* >>>> Chief Technical Officer >>>> jslawin...@soldevelo.com / +48 514 780 384 >>>> >>>> >>>> *SolDevelo* Sp. z o.o. [LLC] / www.soldevelo.com >>>> Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland >>>> Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41 >>>> >>> >> >> -- >> >> *Jakub Sławiński* >> Chief Technical Officer >> jslawin...@soldevelo.com / +48 514 780 384 >> >> >> *SolDevelo* Sp. z o.o. [LLC] / www.soldevelo.com >> Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland >> Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41 >> > > > -- > -- > Paul > -- *Jakub Sławiński* Chief Technical Officer jslawin...@soldevelo.com / +48 514 780 384 -- * SolDevelo* Sp. z o.o. [LLC] / www.soldevelo.com <http://www.soldevelo.com> Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
