Hi All -  I'd like to resurface this discussion.

Some % of the questions I see on the Mifos slack are about the
availability of the APIs at Demo or the use of Swagger, or something
about the status of the work on
https://github.com/apache/fineract/tree/develop/fineract-client -->
Looking at the GitHub, I see that there were some changes made in
January 2023 on the dev branch.

Meanwhile, the site is down at
https://demo.fineract.dev/fineract-provider/swagger-ui/index.html ,
which should be pulling from the dev branch.

I also note the documentation effort at
https://fineract.apache.org/docs/current/#_fineract_client_documentation

So, can someone comment?  What is the focus now or the immediate next steps?

Thanks,
jdailey

James Dailey



On Thu, Jan 13, 2022 at 11:26 AM Michael Vorburger <[email protected]> wrote:
>
> On Thu, Jan 13, 2022 at 7:29 PM Aleksandar Vidakovic 
> <[email protected]> wrote:
>>
>> Hi everyone,
>>
>> ... my 2 cents:
>>
>> 3. https://github.com/openMF/fineract-client was an earlier effort (don't 
>> remember which community member created it); the Swagger descriptor was 
>> there already for a couple of years (got added to Fineract as a GSoC 
>> project), but we (actually Michael) just recently added a separate module to 
>> the Fineract repo to do this in one build; all in all I'd say they should be 
>> pretty much the same... maybe the one in 
>> https://github.com/openMF/fineract/tree/develop/fineract-client could be a 
>> little fresher given that it's automatically updated when the Swagger file 
>> is updated.
>
>
> I agree with what Aleks states here, and would add the following additional 
> points:
>
> https://github.com/openMF/fineract/tree/develop/fineract-client is not the 
> repository of Apache Fineract. That repo on openMF is a fork, which from an 
> Apache point of view is really no different from the 921 other forks listed 
> on https://github.com/apache/fineract/network/members (in my view).
>
> What I think this email thread is really asking about is presumably 
> https://github.com/apache/fineract/tree/develop/fineract-client (NOT 
> https://github.com/openMF/fineract/tree/develop/fineract-client; note the 
> /openmf/ vs /apache/ difference) -VS- 
> https://github.com/openMF/fineract-client?
>
> I would venture as far as stating that 
> https://github.com/apache/fineract/tree/develop/fineract-client is now 
> "Apache Fineract's official Java client", and for someone who isn't already 
> using https://github.com/openMF/fineract-client and previously invested in 
> it, I suggest that we recommend using that, only.
>
>> 4. Automatic or not... kind of both: the challenge with the current REST 
>> resource classes in Fineract is that pretty much all of them are not type 
>> safe; there's a lot of manual JSON de-/serialization done; in most cases the 
>> HTTP body lands in a String variable first, and as there's no way for the 
>> Swagger annotation processor to detect what's going on in those String blobs 
>> we had to handcraft some mock classes that are only there to give 
>> context/type info to the Swagger annotation processor. This was done that 
>> way to maintain 100% backward Java source compatibility. It should cover 
>> most of Fineract's API, but there are for sure parts that are a bit out of 
>> sync. Note: there's been a discussion to introduce type safety in the REST 
>> resource classes, using Jackson instead of GSON, get rid of those mock Java 
>> type classes and most (if not all) of the handcrafted JSON 
>> de-/serialization... there'll soon be a first PR to try this out with a 
>> small self-contained module (maybe client API or something similar).
>>
>> 5. See my previous point; the Java code generation is fully automatic in the 
>> Fineract repo, but the mock type classes that are used to generate the 
>> Swagger file are handcrafted... if something is missing then it was already 
>> missing in the Swagger file (aka the mock classes).
>
>
> We very much welcome any PRs from any interested parties using 
> https://github.com/apache/fineract/tree/develop/fineract-client with 
> suggested improvements for it! ;-) For example for the fullname field 
> mismatch you noticed - go ahead and fix it! :) You may also be interested in 
> having a look through the currently 52 open issues mentioning 
> "fineract-client" in the Apache Fineract JIRA, see 
> https://issues.apache.org/jira/issues/?jql=text%20~%20%22fineract-client%22%20AND%20status%20%3D%20open,
>  contributions to any of those are certainly appreciated. (Further analyzing 
> and "triaging" these issues is a form of contribution as well, of course.)
>
>> 6. I know that the Fineract client (the one from the Fineract repo) was used 
>> in commercial projects; I have no numbers about volume and performance 
>> though.
>
>
> Re. performance, I feel reasonably confident in stating that given that the 
> Apache Fineract Client is based on Swagger Code Generation and the OkHTTP 
> client library, which are both very widely used, running into any significant 
> client side performance issues at scale are somewhat unlikely. Sure it's not 
> quite Google Protocol Buffers level binary serialization performance, but in 
> the bigger picture of things, the Fineract "backend" (fineract-provider) is 
> very very likely the much more interesting part of performance investigations 
> than the little Java object to JSON conversation happening in fineract-client 
> (in my view).
>
> Of course, any party considering production use would do their own due 
> diligence and scale testing. (The Apache Fineract community is also very 
> interested in any Pull Requests contributing both scale testing tools and 
> performance improvements to the project.)
>
> I hope this helps?
>
>
>> Cheers,
>>
>> Aleks
>>
>> On Thu, Jan 13, 2022 at 7:03 PM Ed Cable <[email protected]> wrote:
>>>
>>> Chinmay and Danish,
>>>
>>> There is some interest and inquiry coming from users in the community 
>>> regarding the Fineract Client.
>>>
>>> I was hoping you all along with some of the past contributors to this 
>>> project like @Aleksandar Vidakovic and @Michael Vorburger could help me 
>>> with some of the below questions:
>>>
>>> 3. What is the difference between these 2 clients:
>>> https://github.com/openMF/fineract/tree/develop/fineract-client
>>> https://github.com/openMF/fineract-client
>>>
>>> Are either of these client’s considered production ready?
>>>
>>> 4. Is 
>>> https://github.com/openMF/fineract-client/blob/master/swagger-api-spec-file.json
>>>  hand coded or generated?
>>>
>>> 5. We have noticed that both fineract-clients only have fullname field 
>>> supported when creating a Fineract Client (the database entity). This has 
>>> led to the conclusion that neither are based off the Fineract-provider 
>>> JAX-RS but are probably hand coded. We are wondering which one is best 
>>> supported now and into the future, or if we should hand code our own client.
>>>
>>> 6. Have either client been used in high volume use cases?
>>>

Reply via email to