Hi James Dailey, Thank you for the detailed clarification — this is very helpful.
I understand the intent now as: 1.a separate end-user-facing BFF, 1.with its own auth server and user store (independent of Fineract back-office users), 3.enforcing customer ownership boundaries to avoid reintroducing earlier self-service security risks. I’d like to shape my POC around this pattern: 1. customer-safe /me/* APIs in the BFF, 2. JWT-based auth issued by the BFF auth component, 3. explicit mapping between BFF end-users and Fineract client IDs, 4. all backend operations executed via fineract-client-feign, 5. minimal/no changes to Fineract core. I look forward to your feedback in this direction. Best regards, Pranjal On Fri, 6 Mar 2026 at 00:29, James Dailey <[email protected]> wrote: > please see my response to > https://lists.apache.org/thread/4407ngs8gyyhv47z4lqqrjnlg2oxnc44 > > > On Thu, Mar 5, 2026 at 12:15 AM Pranjal Singla <[email protected]> > wrote: > >> Hi Fineract Community, >> >> I am Pranjal, a 2nd-year B.Tech student. I’ve recently started >> contributing to Fineract by fixing compilation warnings to get familiar >> with the architecture. >> >> I am very interested in the *Self-Service API Component* idea from the >> GSoC 2026 list. My proposed approach for this POC includes: >> >> - >> >> *BFF Architecture:* A standalone service to aggregate data (balances, >> transactions, loans) into single responses for mobile/web clients. >> - >> >> *Modern Integration:* Using *fineract-client-feign* for all internal >> communication with the Fineract backend. >> - >> >> *Security:* Implementing *JWT-based authentication* for secure and >> isolated consumer access. >> - >> >> *Documentation:* Providing full *Swagger/OpenAPI* support for easy >> frontend integration. >> >> I’m eager to hear your thoughts and start drafting a detailed proposal >> once the window opens. >> >> Best regards, >> >> Pranjal Singla >> >
