APISIX plugins ship JSON Schema definitions for their configuration. If APISIX Dashboard can render plugin configuration forms directly from JSON Schema, developer experience improves significantly and reduces manual UI maintenance.

Goals (Deliverables)
Must-have:

• A reusable SchemaForm (or equivalent) that renders basic types: string/number/integer/boolean/object/array.
• enum support (Select/Radio etc), defaults, required fields, basic constraints (min/max, pattern, etc) where feasible.
• Support at least the key complex patterns used by APISIX plugin schemas:
  • oneOf (select one option and render corresponding fields)
  • dependencies / conditional fields
  • (Stretch) anyOf if present in target schemas
• Validation pipeline: validate form values against schema (AJV) and show errors in UI consistently.
• Documentation + developer guide: how to add/extend schema-to-widget mapping.
• Tests (unit + minimal integration) to prevent regressions for schema parsing and conditional rendering.

Build a Self-Service API Component that Connects to Apache Fineract

When the project removed self-service APIs in 2025, it did so understanding that we would need an outside component to make that connection as part of an overall solution. 

This project is to create - as a Proof of Concept (POC) - a new dedicated Self-Service API component or service that integration with Fineract backend.  It will need to expose APIs to consumer facing applications for typical activities like viewing account balances, transaction initiation, loan application, etc.  

The idea is for GSOC candidates to propose a design and build the POC. 

Minimal criteria include testing, authentication methodology, documentation.  

Not included in this GSOC would be the end consumer APP, although that may be undertaken by another project and coordination would be needed. 

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 

The idea is to create a connector and a demonstration of analytics that would consume and organize data from Fineract.  

For example, create a way to pull data out of Fineract and make it easy to use in common analytics  such as Power BI or Tableau or, better yet, an open source variant.   The data should probably go to a Data Warehouse.  

Start by proposing and exploring different options and write up the pros and cons.  

Create a demonstration project that takes into account security, levels of access, and security of PII data if it exists. 

Fineract has some loan origination functionality but it is not robust enough for many operations.   The POC would demonstrate the kind of functionality that could be built and/or help to demonstrate the full capabilities of the Fineract system.  

Using data that is typically in a fineract installation, create a way to score risk and a more full featured loan origination process.  Propose and explore other sources of data and how to integrate in a flexible and extensible manner.  

This needs further definition...