Please see https://lists.apache.org/thread/4407ngs8gyyhv47z4lqqrjnlg2oxnc44
On Thu, Mar 5, 2026 at 2:17 AM JANANI <[email protected]> wrote: > Hi Ashhar and Harish, > > My name is Janani and I am a student studying Artificial Intelligence and > Data Science. I have been reading your messages about the Self-Service API > gatekeeper and the name tags for the different rooms. > > I am new here and I really want to learn how to build this with you for > GSOC 2026. I am looking at the code on my computer now to see how the > gatekeeper works. > > Thank you for explaining everything so clearly! > > Best regards, Janani > > On Wed, Mar 4, 2026 at 11:55 PM Ashhar Ahmad Khan <[email protected]> > wrote: > >> Hi, >> Following on from Aman's point about consistency being critical for >> transaction processing, I wanted to add something I confirmed from the >> source while working on the self-service removal. >> On Harish's multi-tenancy question: TenantAwareBasicAuthenticationFilter >> reads the Fineract-Platform-TenantId header and binds the resolved tenant >> to thread local storage via ThreadLocalContextUtil.setTenant(). The old >> self-service module went through this same filter and tenant binding was >> already correct at the filter layer. For a BFF calling Fineract internally >> using a service account, multi-tenancy might reduce to correctly embedding >> the tenant header in outbound calls, with Fineract's existing filter >> handling the resolution. The more interesting question is how the BFF maps >> an authenticated borrower request to the correct tenant identifier in the >> first place, whether that lives in the borrower JWT or somewhere else. >> Happy to be corrected if I am misreading the filter chain. >> Ashhar >> >> >> On 2026/02/21 04:38:04 Harish wrote: >> > Hi everyone, >> > >> > I hope you're all doing well. >> > >> > My name is* Harish*, and I’m a second-year ECE* student from India*. >> I’ve >> > been exploring Apache Fineract’s architecture over the past few days and >> > reviewing the discussion around the proposed Self-Service API (BFF) >> > component for GSoC 2026. I’m very interested in working on this project. >> > >> > From my understanding, the goal is to build a standalone >> > Backend-for-Frontend service that exposes consumer-facing APIs such as >> > account balances, transaction initiation, and loan applications, while >> > securely integrating with the Fineract backend. >> > >> > I’ve been thinking about approaching this as a *dedicated Spring Boot >> > microservice* that communicates with Fineract via HTTP clients aligned >> with >> > existing API patterns. For authentication, I’m considering a >> > consumer-focused *JWT/OAuth2-based mechanism*, separate from the admin >> > authentication model. >> > >> > Since this service would be public-facing, I was also considering >> whether >> > it would be appropriate (even at the POC level) to include: >> > >> > - >> > >> > Asynchronous handling for heavier operations like loan processing >> > - >> > >> > Redis caching for frequently accessed endpoints >> > - >> > >> > Basic rate limiting and validation >> > - >> > >> > Resilience patterns when communicating with Fineract >> > - >> > >> > Docker-based setup for easier deployment and testing >> > >> > I would appreciate guidance from the community on the expected scope of >> the >> > POC — particularly how production-ready it should be. >> > >> > I also have a few clarifications: >> > >> > 1. >> > >> > Should consumer users be stored within Fineract’s existing user model, >> > or should this BFF maintain a separate identity store linked to Fineract >> > clients? >> > 2. >> > >> > Is multi-tenancy expected to be supported in this POC? >> > 3. >> > >> > Would this component live as a new module within the apache/fineract >> > repository, or as a separate repository? >> > >> > I’d be happy to draft a short architecture proposal based on the >> feedback >> > here. >> > >> > Looking forward to your thoughts. >> > >> > Thank You and Regards, >> > >> > Harish >> > >> > github: https://github.com/HarishSivakumar-dev >> > >> > mail: [email protected] >> > >> >
