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