... 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 <sidhant@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 <jamespdai...@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 <adamsa...@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 <jdai...@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,
>>>
>>>
>>>
