... 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, <chee...@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 <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,
>>>>
>>>>
>>>>
