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] >
