Apache Dubbo aims to provide full interoperability with the gRPC ecosystem through the Triple protocol, which is designed to be fully compatible with gRPC communication and tooling.

However, the gRPC ecosystem has evolved significantly in recent years, including improvements in APIs, streaming interfaces, and client/server abstractions.

Some of these updates have not yet been fully reflected in Dubbo's current API design and SDK capabilities.

This project aims to evaluate the latest gRPC APIs and align Dubbo’s APIs with modern gRPC design patterns where appropriate.

Goal

Expected tasks include:

Investigate the latest gRPC API changes and features.

Identify gaps between Dubbo’s APIs and the gRPC ecosystem.

Improve or extend Dubbo APIs to better align with gRPC usage patterns.

Improve interoperability between Dubbo services and gRPC clients.

Provide examples and documentation for cross-framework usage.

Possible Extensions

Improve gRPC streaming support

Enhance proto-based service definitions

Improve developer experience for cross-language services

Relevant Skills

Java

gRPC

RPC frameworks

Distributed systems

Potential Mentors

Albumen Kevin, Apache Dubbo PMC, albumenj@apache.org
dev@dubbo.apache.org

Difficulty: Major

Project size: ~350 hour (large)

Potential mentors:

Liang He, mail: heliang666s (at) apache.org

Project Devs, mail:

Apache Fineract

fineract-client-feign usage for integration tests

Loan Origination (POC)

No one should work on this specific ticket unless assigned - the GSOC candidate we choose will be assigned this ticket.

For more information, you should be reviewing emails on this subject and following the Wiki pages.
https://lists.apache.org/list.html?dev@fineract.apache.org
https://cwiki.apache.org/confluence/display/FINERACT/GSOC+Program+at+Fineract

"Moving away from RestAssured (low-level) API calls in integration tests and rather use fineract-client-feign would be a great improvement"

Summary (with some assist from chatgpt for clarity)

Apache Fineract has a large set of REST APIs and many integration tests currently call those APIs using RestAssured(low-level HTTP requests). This ticket is to help modernize the tests by switching them to use fineract-client-feign, which is Fineract’s higher-level API client.

Goal

Create a simple migration approach and then migrate a small set of integration tests from RestAssured to fineract-client-feign.

Why we’re doing this

Makes tests easier to read and maintain (less raw HTTP code).

Encourages consistent API usage across tests.

Reduces duplicated request-building logic (headers, base URLs, auth, etc.).

Scope of Work

1) Create a short migration plan

Write a short note (in the Jira ticket comments or a small doc) that answers:

Where are the current RestAssured-based integration tests located?

What’s the recommended pattern for using fineract-client-feign in tests?

What should be migrated first (start small)?

2) Pick a small “starter set” of tests

Identify 2–5 integration tests that:

Are simple (e.g., create/read/update a resource)

Don’t involve complicated multi-step workflows

Run reliably in CI

3) Implement the migration for the starter set

For each selected test:

Replace RestAssured calls with fineract-client-feign client calls

Keep the same assertions (same expected behavior)

Ensure the tests still pass locally and in CI

4) Document the new pattern

Add a short README note or comments in the test code showing:

How to initialize/configure the Feign client for tests

How auth/session is handled

A small “before vs after” explanation (1 paragraph is enough)

Acceptance Criteria

A brief migration plan is written and linked in the ticket.

At least 2 integration tests have been converted to use fineract-client-feign.

All tests pass (locally and/or in CI).

A short note exists explaining how to write future integration tests using fineract-client-feign.

Notes / Hints for a beginner

Start by converting just one very small test to learn the pattern.

Keep changes small and easy to review (one test per commit is ideal).

If something is unclear (e.g., how auth is set up), add a comment in the ticket describing what you found.

Out of Scope (for this ticket)

Migrating all integration tests across the repo

Refactoring production API code

Changing API behavior—this is only a test client swap

LOAN ORIGINATION CONTEXT

Fineract has some loan origination functionality but it is not robust enough for many operations. Several vendors, working with Fineract have created new Loan Origination plug ins.

There is also a major enhancement underway that would build out a full Loan Origination flow by supporting the backend needs of data storage for such LOS. See ticket https://issues.apache.org/jira/browse/FINERACT-2418 .

The GSOC student would be expected to propose something as a POC (proof of concept) that would use and expand upon the developed Fineract backend solution. It should not revisit the design of that, and it should be separated enough as to not collide with ongoing work in the project that may be moving faster.

It may be useful to build a new component outside of Fineract to create the flows that would demonstrate the LOS functionality.

That is, this is a moving target, and we would need different proposals from prospective candidates to explore the area of Loan Origination. This may require expertise in risk assessment, loan origination models and business acumen. There will not be much more explanation that this available. The student would be expected to be a self starter.

The mentor for this would need to be an expert at risk modeling, understand Loan Origination, and support a conceptual basis that may involve some things internal to Fineract and some processing elements outside of Fineract. Please comment below if you are an existing Fineract contributor with this expertise.

To try to illustrate: one possible GSOC Proposal archtype we could accept would be a survey of Loan Origination Models, their strengths and weaknesses and to identify commonalities for the community to focus on. This would thus be a Requirements exercise and may help identify future roadmap concepts. In this case, the code to be developed may just expose a few APIs into different screen flows. Thus, perhaps FIGMA flows (or similar) connecting to a set of APIs on the backend.

If those new LOS APIs are existing in June 2026 (ticket 2418 resolved), then those APIs are to be used. if they are NOT there in Fineract, then the student would be requested to create a fork and to implement the POC outside of the main Dev branch.

I welcome additions to this write up. jdailey

Difficulty: Minor

Project size: ~350 hour (large)

Potential mentors:

James Dailey, mail: jdailey (at) apache.org

Project Devs, mail: dev (at) fineract.apache.org

Loan Origination

Fineract Backoffice Interface (POC)

To enable a more comprehensive Fineract project, there will be a new administrative backend User Interface (UI) component. It will be a separate GitHub repository within the Apache Fineract project.

It will be aimed explaining the key functionality of fineract to devs and to act as the demo infrastructure. It will be aimed at being downloaded as part of the Docker container from the ASF, for example.

It should include, for the system user and dev, a page showing all of the APIs organized in a sensible way, and generated automatically at each build.

This back office component is NOT THE SAME as the end-user POC that is proposed in https://issues.apache.org/jira/browse/FINERACT-2440

This does overlap partially with external open source projects that are offered under different licenses. However, this will be apache 2.0 license.

This project will use Angular.

This project should re-imagine the Fineract use cases in a way that is visually simple, distinct, and relates to the several user groups that we see in the project: Fintechs, embedded lending programs, non banking financial institutions (lenders), small banks, etc

Use cases will include, but not be limited to:

login and select user type
configure other users
set up a new loan product
disburse a loan
create a savings account
configure global variables
run dashboards

Difficulty: Minor

Project size: ~350 hour (large)

Potential mentors:

James Dailey, mail: jdailey (at) apache.org

Project Devs, mail: dev (at) fineract.apache.org

Front end application MVP (POC)

No one should work on this specific ticket unless assigned - the GSOC candidate we choose will be assigned this ticket.

For more information, you should be reviewing emails on this subject and following the Wiki pages.
https://lists.apache.org/list.html?dev@fineract.apache.org
https://cwiki.apache.org/confluence/display/FINERACT/GSOC+Program+at+Fineract

Build a simple self-service front end that talks to the Self-Service API

We need a new, user-friendly front end app that connects to our Backend for Front end (Self-Service API component) This will be the “customer portal” experience where users can log in, see their accounts, and check recent activity. It should be straightforward, easy to use, and a good reference example for others to build on.

Functionality needed would include:

Login
Check balances
Transfer between accounts owned by the same customer.
Submit application for a new loan

Testing end to end required.
Solid UI design
Modern app framework
Documentation