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,
>>
>>
>>
