Hello Bhaskar,
Consuming Fineract as a library might work for you because your other
application is written in Java. It will however be a challenge for others
consuming Fineract via Javascript, C#, PHP and other programming languages. The
current REST approach is good for Fineract adoption.
Can you please use an APM tool such as Stakify, Azure App Insights, etc to
analyse your applications (Fineract <-> Other backend application(s) <->
frontend). This should help identify where the performance issue is coming
from. If its Fineract, kindly share the APIs and the response time for each API
that is causing the bottle neck.
Regards
Anu Omotayo
On Tuesday, May 6, 2025 at 08:22:02 AM GMT+1, James Dailey
<jdai...@apache.org> wrote:
It’s an interesting question that has come up in the past - ie using the
Fineract capabilities without going through the API layer. However I’m unaware
of any recent efforts to create an SDK from Fineract, which may be the
direction you are heading in.
To be sure Look at recent listserv discussions
https://lists.apache.org/list.html?dev@fineract.apache.org
However, there is an effort underway to improve the CQRS pattern and remove
some latency issues in processing by streamlining There’s a proof of concept
and I believe there is a need for more contributors. Improvements with Jackson
JSON should help some latency I would think.
See
https://cwiki.apache.org/confluence/display/FINERACT/FSIP-5%3A+New+command+processing+infrastructure
There are also tickets being worked on for some performance purposes - search
them on Fineract Jira and see recent code changes for a hint to how you could
help. The improvements tend to come in on some API calls first and not so much
on others.
In that vein you may want to prioritize which API calls are the most
problematic by further testing.
On Tue, May 6, 2025 at 8:12 AM Magezi Arthur <artmag...@gmail.com> wrote:
Dear Baskar,
Which response times are you looking for?Work the numbers first especially
running tests locally on your server with respect to your expectations.
Your synchronous design heavily depends on how fast fineract will process the
requests. Asynchronous processing has been heavily emphasized in these
circumstances, perhaps you may need to look into your design a bit.
Again we could look more into the actual scenarios under which the response
times deteriorate and combat that to some extent.
Basically am saying, don’t rush the decision before establishing the cause of
the latency, especially if serialization and network issues are ruled out.
MUGABE MAGEZI ARTHUR
Software Developer and Process Management Consultantemails:
artmag...@gmail.com
atmag...@yahoo.co.ukMob: +256704901261
facebook: Magezi Arthur
Skype: marthur26
The Struggle the doesn't break you will make you, if you hold a little longer
under that fire you will certainly come out as Gold
On Tue, 6 May 2025 at 8:51 am, Bhaskar Tiwari <bhas...@strideone.in> wrote:
Dear MUGABE MAGEZI ARTHUR,
Thank you for the response.
To provide more context: currently, our application relies on making API calls
to Fineract for every database read or write operation. Our architecture is
based on a request-response pattern — once we receive a response from Fineract,
we process it through our custom business logic in a separate application.
This round-trip communication, especially over HTTP, introduces noticeable
latency that affects the responsiveness of our frontend.
That’s why we're exploring whether it would be feasible to embed Fineract
directly as a library within our service, allowing us to make direct function
calls instead of HTTP API calls. This approach could potentially improve
performance by removing network and serialization overhead.
Is there any recommended path or documentation for such an integration, or is
Fineract strictly designed to operate as a standalone service accessed via REST
APIs?
Appreciate your guidance on this.
From: Magezi Arthur <artmag...@gmail.com>
Sent: Tuesday, May 6, 2025 11:14 AM
To: dev@fineract.apache.org
Subject: Re: Inquiry: Using Fineract 1.9 as a Library Instead of via API
Dear Bhaskar,
Have you established properly if your the latency concerns are network related
or just growing account transactions.
I’d say, run your tests first, figure out where the actual delays are then
proceed with the solution.
We’ll be here to guide.
MUGABE MAGEZI ARTHUR
Software Developer and
Process Management Consultant
emails:
artmag...@gmail.com
atmag...@yahoo.co.uk
Mob: +256704901261
facebook: Magezi Arthur
Skype: marthur26
The Struggle the doesn't break you will make you, if you hold a little longer
under that fire you will certainly come out as Gold
On Tue, 6 May 2025 at 7:27 am, Bhaskar Tiwari <bhas...@strideone.in> wrote:
Hi Team,
I am currently using Fineract 1.9 for API-based communication from another Java
application, and it has been functioning well. However, due to the complexity
of our application, we are experiencing some latency issues, likely caused by
the overhead of API calls.
To improve performance, I'm exploring the possibility of integrating Fineract
directly as a library within our service, so that API calls can be replaced by
direct function calls.
Is there a recommended approach or documentation available for embedding
Fineract as a library rather than accessing it via REST APIs? If so, could you
please guide us on how to proceed?
Thank you,
Bhaskar Tiwari
|
"Print this mail only if absolutely necessary. Save Paper. Save
Trees."Disclaimer: “This electronic mail message sent from StrideOne (Stride
Fintree Private Limited) may contain Confidential/Restricted/Internal
information and should only be viewed by the intended recipients. Under no
circumstances may any such information be disclosed, copied, used or
distributed to any unauthorized persons or entities without the written consent
of Strideone. If you are not the intended recipient, any review,
retransmission, dissemination or reliance on the content of these materials is
strictly prohibited and may be the subject of legal action. If you received
this email in error, please notify the sender and delete the message
immediately.”
|
|
"Print this mail only if absolutely necessary. Save Paper. Save Trees."
Disclaimer: “This electronic mail message sent from StrideOne (Stride Fintree
Private Limited) may contain Confidential/Restricted/Internal information and
should only be viewed by the intended recipients. Under no circumstances may
any such information be disclosed, copied, used or distributed to any
unauthorized persons or entities without the written consent of Strideone. If
you are not the intended recipient, any review, retransmission, dissemination
or reliance on the content of these materials is strictly prohibited and may be
the subject of legal action. If you received this email in error, please notify
the sender and delete the message immediately.”
|
