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 Consultant emails: *artmag...@gmail.com* <artmag...@gmail.com> *atmag...@yahoo.co.uk <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 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* <artmag...@gmail.com> > > *atmag...@yahoo.co.uk <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.” >
