On Thu, Jan 13, 2022 at 7:29 PM Aleksandar Vidakovic < chee...@monkeysintown.com> 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 <edca...@mifos.org> 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 <chee...@monkeysintown.com> and @Michael >> Vorburger <michael.vorbur...@gmail.com> 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? >> >>
