You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Ádám Sághy <ad...@gmail.com> on 2025/08/10 14:53:36 UTC
Re: Fineract 2.0 roadmap ideas
Hi James,
Possible Topics to Include in the Survey
API Endpoint & Parameter Consistency
Introduce common, generic naming conventions for all API endpoints, commands, request parameters, and response fields to improve clarity and reduce ambiguity.
Date & Time Handling
Standardize date/time representation across all APIs. Options include:
Return all dates and datetimes as ISO 8601-formatted strings (date, dateTime, offsetDateTime).
Alternatively, use the system’s provided date format.
Avoid mixed representations (arrays, strings, etc.) for the same type of data.
Strict DTO-based Request/Response Models
Remove incoming and outgoing raw string JSON handling.
Map all requests and responses to DTOs with clear field-level validations for incoming data.
Exception Handling & HTTP Status Codes
Enforce consistent status codes across the platform:
400 - Request syntax or field validation errors.
403 - Domain/business rule violations.
500 - Generic server errors.
Standardize the error response structure for easy client-side handling.
Common Response Structure for Write Operations
Example unified structure:
json
CopyEdit
{
"resources": [
{
"resourceId": "1",
"resourceExternalId": "87c83044-825a-48c8-989b-bbf47d43caec",
"resourceEntity": "LOAN",
"resourceClassification": "REPAYMENT"
}
],
"changes": {
"key": "value"
}
}
Alternative Approach
Move away from a common, generic response format and allow each API to define its own dedicated response object tailored to its functionality.
Modularization & Dependency Hygiene
Finish modularization and remove circular/unnecessary dependencies between modules.
Define clear, stable module boundaries (public API vs. internal).
Security & SQL Safety
Avoid native SQL; use JPQL/Criteria/repositories by default.
If native is needed, require prepared statements—no string concatenation.
My opening thoughts on Fineract 2.0.
Regards,
Adam
> On 2025. May 12., at 22:53, James Dailey <jd...@apache.org> wrote:
>
> Community -
>
> It is probably past time to have a discussion about the future of Fineract and what we want to see going forward.
>
> I would like to get your ideas for a Survey of users and developers.
>
> In that survey, which we would push to as many users and developers of Fineract as possible, we would ask things about developer experience, user interfaces, API documentation, connecting to payments, enabling connections to third party systems, security, code quality, and in general a number of topics that relate to the roadmap ideas that have surfaced in the past two years.
>
> I will also include a few of the previously asked questions from our community surveys in 2019, 2021, and 2022 so that we can have a time series, e.g. around questions of "how did you learn about the project?" and "how are you using it?"
> https://cwiki.apache.org/confluence/display/FINERACT/Survey+Results+2022+November
>
> Please respond here with questions and topics to cover. If there is no objection I will formulate the questions and send out the survey using Google Survey by the end of next week with responses due by June 4th. I'll ask for the community to promote the survey as much as possible to relevant people.
>
> Thanks,
Re: Fineract 2.0 roadmap ideas
Posted by Aleksandar Vidakovic <ch...@monkeysintown.com>.
... And:
- standardized errors based on HTTP problem details specification
- all error-/messages internationalized with Java resource bundles (aka no
more translations on the client/UI side)
On Mon, 11 Aug 2025, 17:53 Aleksandar Vidakovic, <ch...@monkeysintown.com>
wrote:
> ... some more:
>
> - ditch ORM layers altogether and use QueryDSL or Jooq (good bye SQL
> string concatenation and SQL injections)
> - migrate from JAX-RS to Spring Web MVC
> - investigate virtual threads
> - allow alternative API protocols (e.g. gRPC)
> - remove SQL JOINS as much as possible
> - prepare for Spring Boot 4/Spring Framework 7
> - do API versioning via advanced content type header;
> "application/json" vs
> "application/vnd.fineract.loan+json;charset=UTF-8;version=1.0"
>
>
> On Mon, Aug 11, 2025 at 8:53 AM sidhant goel <si...@freo.money.invalid>
> wrote:
>
>> One thing I'd like to propose is reducing code duplication by refactoring
>> repeated logic into reusable functions or utilities.
>>
>> As someone who's recently started working on Fineract, I've noticed that
>> making changes often requires modifying the same or very similar code in
>> multiple places. This not only increases development time but also raises
>> the risk of inconsistencies or errors.
>>
>> While this wouldn’t introduce any new features, it could significantly
>> improve maintainability and make future enhancements easier and safer. What
>> do you all think?
>>
>> On Sun, Aug 10, 2025 at 10:25 PM James Dailey <ja...@gmail.com>
>> wrote:
>>
>>> Thanks Adam - I’m back in this topic.
>>>
>>> Any others ?
>>>
>>> Sent from Gmail Mobile
>>>
>>>
>>> On Sun, Aug 10, 2025 at 7:54 AM Ádám Sághy <ad...@gmail.com> wrote:
>>>
>>>> Hi James,
>>>>
>>>> *Possible Topics to Include in the Survey*
>>>>
>>>> -
>>>>
>>>> *API Endpoint & Parameter Consistency*
>>>> -
>>>>
>>>> Introduce common, generic naming conventions for all API
>>>> endpoints, commands, request parameters, and response fields to improve
>>>> clarity and reduce ambiguity.
>>>> -
>>>>
>>>> *Date & Time Handling*
>>>> -
>>>>
>>>> Standardize date/time representation across all APIs. Options
>>>> include:
>>>> -
>>>>
>>>> Return all dates and datetimes as ISO 8601-formatted strings (
>>>> date, dateTime, offsetDateTime).
>>>> -
>>>>
>>>> Alternatively, use the system’s provided date format.
>>>> -
>>>>
>>>> Avoid mixed representations (arrays, strings, etc.) for the
>>>> same type of data.
>>>> -
>>>>
>>>> *Strict DTO-based Request/Response Models*
>>>> -
>>>>
>>>> Remove incoming and outgoing *raw string JSON* handling.
>>>> -
>>>>
>>>> Map all requests and responses to DTOs with clear field-level
>>>> validations for incoming data.
>>>> -
>>>>
>>>> *Exception Handling & HTTP Status Codes*
>>>> -
>>>>
>>>> Enforce consistent status codes across the platform:
>>>> -
>>>>
>>>> 400 - Request syntax or field validation errors.
>>>> -
>>>>
>>>> 403 - Domain/business rule violations.
>>>> -
>>>>
>>>> 500 - Generic server errors.
>>>> -
>>>>
>>>> Standardize the error response structure for easy client-side
>>>> handling.
>>>> -
>>>>
>>>> *Common Response Structure for Write Operations*
>>>> -
>>>>
>>>> Example unified structure:
>>>>
>>>> json
>>>> CopyEdit
>>>> {
>>>> "resources": [
>>>> {
>>>> "resourceId": "1",
>>>> "resourceExternalId": "87c83044-825a-48c8-989b-bbf47d43caec",
>>>> "resourceEntity": "LOAN",
>>>> "resourceClassification": "REPAYMENT"
>>>> }
>>>> ],
>>>> "changes": {
>>>> "key": "value"
>>>> }}
>>>>
>>>> -
>>>>
>>>> *Alternative Approach*
>>>> -
>>>> -
>>>>
>>>> Move away from a common, generic response format and allow each API
>>>> to define its own dedicated response object tailored to its functionality.
>>>>
>>>>
>>>> *Modularization & Dependency Hygiene*
>>>> -
>>>>
>>>> Finish modularization and remove circular/unnecessary
>>>> dependencies between modules.
>>>> -
>>>>
>>>> Define clear, stable module boundaries (public API vs. internal).
>>>>
>>>>
>>>> 7.
>>>>
>>>> *Security & SQL Safety*
>>>>
>>>> Avoid native SQL; use JPQL/Criteria/repositories by default.
>>>>
>>>> If native is needed, require prepared statements—no string
>>>> concatenation.
>>>>
>>>>
>>>> My opening thoughts on Fineract 2.0.
>>>>
>>>> Regards,
>>>> Adam
>>>>
>>>>
>>>> On 2025. May 12., at 22:53, James Dailey <jd...@apache.org> wrote:
>>>>
>>>> Community -
>>>>
>>>> It is probably past time to have a discussion about the future of
>>>> Fineract and what we want to see going forward.
>>>>
>>>> I would like to get your ideas for a Survey of users and developers.
>>>>
>>>> In that survey, which we would push to as many users and developers of
>>>> Fineract as possible, we would ask things about developer experience, user
>>>> interfaces, API documentation, connecting to payments, enabling connections
>>>> to third party systems, security, code quality, and in general a number of
>>>> topics that relate to the roadmap ideas that have surfaced in the past two
>>>> years.
>>>>
>>>> I will also include a few of the previously asked questions from our
>>>> community surveys in 2019, 2021, and 2022 so that we can have a time
>>>> series, e.g. around questions of "how did you learn about the project?" and
>>>> "how are you using it?"
>>>>
>>>> https://cwiki.apache.org/confluence/display/FINERACT/Survey+Results+2022+November
>>>>
>>>>
>>>> Please respond here with questions and topics to cover. If there is
>>>> no objection I will formulate the questions and send out the survey using
>>>> Google Survey by the end of next week with responses due by June 4th.
>>>> I'll ask for the community to promote the survey as much as possible to
>>>> relevant people.
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
Re: Fineract 2.0 roadmap ideas
Posted by Aleksandar Vidakovic <ch...@monkeysintown.com>.
... some more:
- ditch ORM layers altogether and use QueryDSL or Jooq (good bye SQL
string concatenation and SQL injections)
- migrate from JAX-RS to Spring Web MVC
- investigate virtual threads
- allow alternative API protocols (e.g. gRPC)
- remove SQL JOINS as much as possible
- prepare for Spring Boot 4/Spring Framework 7
- do API versioning via advanced content type header; "application/json"
vs "application/vnd.fineract.loan+json;charset=UTF-8;version=1.0"
On Mon, Aug 11, 2025 at 8:53 AM sidhant goel <si...@freo.money.invalid>
wrote:
> One thing I'd like to propose is reducing code duplication by refactoring
> repeated logic into reusable functions or utilities.
>
> As someone who's recently started working on Fineract, I've noticed that
> making changes often requires modifying the same or very similar code in
> multiple places. This not only increases development time but also raises
> the risk of inconsistencies or errors.
>
> While this wouldn’t introduce any new features, it could significantly
> improve maintainability and make future enhancements easier and safer. What
> do you all think?
>
> On Sun, Aug 10, 2025 at 10:25 PM James Dailey <ja...@gmail.com>
> wrote:
>
>> Thanks Adam - I’m back in this topic.
>>
>> Any others ?
>>
>> Sent from Gmail Mobile
>>
>>
>> On Sun, Aug 10, 2025 at 7:54 AM Ádám Sághy <ad...@gmail.com> wrote:
>>
>>> Hi James,
>>>
>>> *Possible Topics to Include in the Survey*
>>>
>>> -
>>>
>>> *API Endpoint & Parameter Consistency*
>>> -
>>>
>>> Introduce common, generic naming conventions for all API
>>> endpoints, commands, request parameters, and response fields to improve
>>> clarity and reduce ambiguity.
>>> -
>>>
>>> *Date & Time Handling*
>>> -
>>>
>>> Standardize date/time representation across all APIs. Options
>>> include:
>>> -
>>>
>>> Return all dates and datetimes as ISO 8601-formatted strings (
>>> date, dateTime, offsetDateTime).
>>> -
>>>
>>> Alternatively, use the system’s provided date format.
>>> -
>>>
>>> Avoid mixed representations (arrays, strings, etc.) for the
>>> same type of data.
>>> -
>>>
>>> *Strict DTO-based Request/Response Models*
>>> -
>>>
>>> Remove incoming and outgoing *raw string JSON* handling.
>>> -
>>>
>>> Map all requests and responses to DTOs with clear field-level
>>> validations for incoming data.
>>> -
>>>
>>> *Exception Handling & HTTP Status Codes*
>>> -
>>>
>>> Enforce consistent status codes across the platform:
>>> -
>>>
>>> 400 - Request syntax or field validation errors.
>>> -
>>>
>>> 403 - Domain/business rule violations.
>>> -
>>>
>>> 500 - Generic server errors.
>>> -
>>>
>>> Standardize the error response structure for easy client-side
>>> handling.
>>> -
>>>
>>> *Common Response Structure for Write Operations*
>>> -
>>>
>>> Example unified structure:
>>>
>>> json
>>> CopyEdit
>>> {
>>> "resources": [
>>> {
>>> "resourceId": "1",
>>> "resourceExternalId": "87c83044-825a-48c8-989b-bbf47d43caec",
>>> "resourceEntity": "LOAN",
>>> "resourceClassification": "REPAYMENT"
>>> }
>>> ],
>>> "changes": {
>>> "key": "value"
>>> }}
>>>
>>> -
>>>
>>> *Alternative Approach*
>>> -
>>> -
>>>
>>> Move away from a common, generic response format and allow each API
>>> to define its own dedicated response object tailored to its functionality.
>>>
>>>
>>> *Modularization & Dependency Hygiene*
>>> -
>>>
>>> Finish modularization and remove circular/unnecessary
>>> dependencies between modules.
>>> -
>>>
>>> Define clear, stable module boundaries (public API vs. internal).
>>>
>>>
>>> 7.
>>>
>>> *Security & SQL Safety*
>>>
>>> Avoid native SQL; use JPQL/Criteria/repositories by default.
>>>
>>> If native is needed, require prepared statements—no string
>>> concatenation.
>>>
>>>
>>> My opening thoughts on Fineract 2.0.
>>>
>>> Regards,
>>> Adam
>>>
>>>
>>> On 2025. May 12., at 22:53, James Dailey <jd...@apache.org> wrote:
>>>
>>> Community -
>>>
>>> It is probably past time to have a discussion about the future of
>>> Fineract and what we want to see going forward.
>>>
>>> I would like to get your ideas for a Survey of users and developers.
>>>
>>> In that survey, which we would push to as many users and developers of
>>> Fineract as possible, we would ask things about developer experience, user
>>> interfaces, API documentation, connecting to payments, enabling connections
>>> to third party systems, security, code quality, and in general a number of
>>> topics that relate to the roadmap ideas that have surfaced in the past two
>>> years.
>>>
>>> I will also include a few of the previously asked questions from our
>>> community surveys in 2019, 2021, and 2022 so that we can have a time
>>> series, e.g. around questions of "how did you learn about the project?" and
>>> "how are you using it?"
>>>
>>> https://cwiki.apache.org/confluence/display/FINERACT/Survey+Results+2022+November
>>>
>>>
>>> Please respond here with questions and topics to cover. If there is no
>>> objection I will formulate the questions and send out the survey using
>>> Google Survey by the end of next week with responses due by June 4th.
>>> I'll ask for the community to promote the survey as much as possible to
>>> relevant people.
>>>
>>> Thanks,
>>>
>>>
>>>
Re: Fineract 2.0 roadmap ideas
Posted by sidhant goel <si...@freo.money.INVALID>.
One thing I'd like to propose is reducing code duplication by refactoring
repeated logic into reusable functions or utilities.
As someone who's recently started working on Fineract, I've noticed that
making changes often requires modifying the same or very similar code in
multiple places. This not only increases development time but also raises
the risk of inconsistencies or errors.
While this wouldn’t introduce any new features, it could significantly
improve maintainability and make future enhancements easier and safer. What
do you all think?
On Sun, Aug 10, 2025 at 10:25 PM James Dailey <ja...@gmail.com>
wrote:
> Thanks Adam - I’m back in this topic.
>
> Any others ?
>
> Sent from Gmail Mobile
>
>
> On Sun, Aug 10, 2025 at 7:54 AM Ádám Sághy <ad...@gmail.com> wrote:
>
>> Hi James,
>>
>> *Possible Topics to Include in the Survey*
>>
>> -
>>
>> *API Endpoint & Parameter Consistency*
>> -
>>
>> Introduce common, generic naming conventions for all API
>> endpoints, commands, request parameters, and response fields to improve
>> clarity and reduce ambiguity.
>> -
>>
>> *Date & Time Handling*
>> -
>>
>> Standardize date/time representation across all APIs. Options
>> include:
>> -
>>
>> Return all dates and datetimes as ISO 8601-formatted strings (
>> date, dateTime, offsetDateTime).
>> -
>>
>> Alternatively, use the system’s provided date format.
>> -
>>
>> Avoid mixed representations (arrays, strings, etc.) for the
>> same type of data.
>> -
>>
>> *Strict DTO-based Request/Response Models*
>> -
>>
>> Remove incoming and outgoing *raw string JSON* handling.
>> -
>>
>> Map all requests and responses to DTOs with clear field-level
>> validations for incoming data.
>> -
>>
>> *Exception Handling & HTTP Status Codes*
>> -
>>
>> Enforce consistent status codes across the platform:
>> -
>>
>> 400 - Request syntax or field validation errors.
>> -
>>
>> 403 - Domain/business rule violations.
>> -
>>
>> 500 - Generic server errors.
>> -
>>
>> Standardize the error response structure for easy client-side
>> handling.
>> -
>>
>> *Common Response Structure for Write Operations*
>> -
>>
>> Example unified structure:
>>
>> json
>> CopyEdit
>> {
>> "resources": [
>> {
>> "resourceId": "1",
>> "resourceExternalId": "87c83044-825a-48c8-989b-bbf47d43caec",
>> "resourceEntity": "LOAN",
>> "resourceClassification": "REPAYMENT"
>> }
>> ],
>> "changes": {
>> "key": "value"
>> }}
>>
>> -
>>
>> *Alternative Approach*
>> -
>> -
>>
>> Move away from a common, generic response format and allow each API
>> to define its own dedicated response object tailored to its functionality.
>>
>>
>> *Modularization & Dependency Hygiene*
>> -
>>
>> Finish modularization and remove circular/unnecessary dependencies
>> between modules.
>> -
>>
>> Define clear, stable module boundaries (public API vs. internal).
>>
>>
>> 7.
>>
>> *Security & SQL Safety*
>>
>> Avoid native SQL; use JPQL/Criteria/repositories by default.
>>
>> If native is needed, require prepared statements—no string
>> concatenation.
>>
>>
>> My opening thoughts on Fineract 2.0.
>>
>> Regards,
>> Adam
>>
>>
>> On 2025. May 12., at 22:53, James Dailey <jd...@apache.org> wrote:
>>
>> Community -
>>
>> It is probably past time to have a discussion about the future of
>> Fineract and what we want to see going forward.
>>
>> I would like to get your ideas for a Survey of users and developers.
>>
>> In that survey, which we would push to as many users and developers of
>> Fineract as possible, we would ask things about developer experience, user
>> interfaces, API documentation, connecting to payments, enabling connections
>> to third party systems, security, code quality, and in general a number of
>> topics that relate to the roadmap ideas that have surfaced in the past two
>> years.
>>
>> I will also include a few of the previously asked questions from our
>> community surveys in 2019, 2021, and 2022 so that we can have a time
>> series, e.g. around questions of "how did you learn about the project?" and
>> "how are you using it?"
>>
>> https://cwiki.apache.org/confluence/display/FINERACT/Survey+Results+2022+November
>>
>>
>> Please respond here with questions and topics to cover. If there is no
>> objection I will formulate the questions and send out the survey using
>> Google Survey by the end of next week with responses due by June 4th.
>> I'll ask for the community to promote the survey as much as possible to
>> relevant people.
>>
>> Thanks,
>>
>>
>>
Re: Fineract 2.0 roadmap ideas
Posted by James Dailey <ja...@gmail.com>.
Thanks Adam - I’m back in this topic.
Any others ?
Sent from Gmail Mobile
On Sun, Aug 10, 2025 at 7:54 AM Ádám Sághy <ad...@gmail.com> wrote:
> Hi James,
>
> *Possible Topics to Include in the Survey*
>
> -
>
> *API Endpoint & Parameter Consistency*
> -
>
> Introduce common, generic naming conventions for all API endpoints,
> commands, request parameters, and response fields to improve clarity and
> reduce ambiguity.
> -
>
> *Date & Time Handling*
> -
>
> Standardize date/time representation across all APIs. Options
> include:
> -
>
> Return all dates and datetimes as ISO 8601-formatted strings (
> date, dateTime, offsetDateTime).
> -
>
> Alternatively, use the system’s provided date format.
> -
>
> Avoid mixed representations (arrays, strings, etc.) for the same
> type of data.
> -
>
> *Strict DTO-based Request/Response Models*
> -
>
> Remove incoming and outgoing *raw string JSON* handling.
> -
>
> Map all requests and responses to DTOs with clear field-level
> validations for incoming data.
> -
>
> *Exception Handling & HTTP Status Codes*
> -
>
> Enforce consistent status codes across the platform:
> -
>
> 400 - Request syntax or field validation errors.
> -
>
> 403 - Domain/business rule violations.
> -
>
> 500 - Generic server errors.
> -
>
> Standardize the error response structure for easy client-side
> handling.
> -
>
> *Common Response Structure for Write Operations*
> -
>
> Example unified structure:
>
> json
> CopyEdit
> {
> "resources": [
> {
> "resourceId": "1",
> "resourceExternalId": "87c83044-825a-48c8-989b-bbf47d43caec",
> "resourceEntity": "LOAN",
> "resourceClassification": "REPAYMENT"
> }
> ],
> "changes": {
> "key": "value"
> }}
>
> -
>
> *Alternative Approach*
> -
> -
>
> Move away from a common, generic response format and allow each API to
> define its own dedicated response object tailored to its functionality.
>
>
> *Modularization & Dependency Hygiene*
> -
>
> Finish modularization and remove circular/unnecessary dependencies
> between modules.
> -
>
> Define clear, stable module boundaries (public API vs. internal).
>
>
> 7.
>
> *Security & SQL Safety*
>
> Avoid native SQL; use JPQL/Criteria/repositories by default.
>
> If native is needed, require prepared statements—no string
> concatenation.
>
>
> My opening thoughts on Fineract 2.0.
>
> Regards,
> Adam
>
>
> On 2025. May 12., at 22:53, James Dailey <jd...@apache.org> wrote:
>
> Community -
>
> It is probably past time to have a discussion about the future of Fineract
> and what we want to see going forward.
>
> I would like to get your ideas for a Survey of users and developers.
>
> In that survey, which we would push to as many users and developers of
> Fineract as possible, we would ask things about developer experience, user
> interfaces, API documentation, connecting to payments, enabling connections
> to third party systems, security, code quality, and in general a number of
> topics that relate to the roadmap ideas that have surfaced in the past two
> years.
>
> I will also include a few of the previously asked questions from our
> community surveys in 2019, 2021, and 2022 so that we can have a time
> series, e.g. around questions of "how did you learn about the project?" and
> "how are you using it?"
>
> https://cwiki.apache.org/confluence/display/FINERACT/Survey+Results+2022+November
>
>
> Please respond here with questions and topics to cover. If there is no
> objection I will formulate the questions and send out the survey using
> Google Survey by the end of next week with responses due by June 4th.
> I'll ask for the community to promote the survey as much as possible to
> relevant people.
>
> Thanks,
>
>
>