Hi Nidhi, That's a good initiative from your side. While based on pr I reviewed earlier I forgot to consider your overall goal for api implementation. Which I apologise for that.
I think for reporting and dashboard purpose we must consider tradeoff and scalability of implementation. Based on use case I have to first ask how much data need to be processed and how frequently it need to be read. If this data is need to be fetched more frequently by user. I recommend implementing ETL pipelines which returns precomputed data and can be scaled independently. If we are dealing with less frequent data but very old data. Less assume last few years of data for auditing purposes. Using API with aggregation. In my opinion is not a good practice. It should be processed in the background and then should be send via email method. Regards Aman Mittal On Wed, Feb 11, 2026, 8:33 PM Nidhi Bhawari <[email protected]> wrote: > Hello Fineract Community, > > I would like to start a discussion regarding the value and architectural > alignment of FINERACT-2460, which proposes a new endpoint to retrieve > consolidated client performance metrics. > > The Problem: Currently, to build a comprehensive "Client Dashboard," > front-end applications must make multiple separate API calls to fetch loan > summaries, savings balances, and standing data. This results in "API > chattiness," which increases network latency and complexity for developers. > > The Proposed Solution: The clients/{clientId}/performance API provides a > single, read-only view of a client’s financial performance. > > Why this aligns with Fineract: > > Reducing "API Chattiness" (Mobile-First Approach): Modern applications in > low-bandwidth regions cannot afford 5–6 separate requests for a single > overview screen. This endpoint acts as a Data Aggregator, following the > Backend-for-Frontend (BFF) pattern to provide a pre-computed summary. > > Transition to "System of Engagement": Fineract is evolving from a "System > of Record" (saving data) to a System of Engagement (providing insights). By > offering metrics like total arrears and performance scores in one call, we > move Fineract toward an Intelligence Layer, providing the instant feedback > expected by modern fintech users. > > Cloud-Native Resource Efficiency: In cloud environments, database > connections and CPU cycles are costly. Executing one optimized > "Performance" query is significantly cheaper and more scalable than five > independent queries for loans, savings, and identity data. > > I have already submitted a PR for this (#5410) and am refining it based on > initial technical feedback. I believe this is a critical step toward making > Fineract’s data delivery more intelligent and performance-oriented. > > I would love to hear the community's thoughts on this approach. > > Best regards, > Nidhi Bhawari >
