Hi, ... just as a reminder: pretty much the whole REST resource classes in Fineract abandoned type safety and keeps the request JSON body in a simple string variable. That makes it pretty much impossible to extract any information about the data structures. To get around that Sanyam added manually in his GSoC project helper classes that have no other functionality than re-introducing type information about the JSON data structures; he did this by painstakingly introspecting the payloads. The Swagger descriptor is generated based on those manually maintained helper classes. I think this was a good choice given the constraints (minimal code changes, 100% backward compatibility), but it is very maintenance heavy... and if I think about it then I am not so sure if these helper classes were on everyone's radar (e. g. when introducing new REST endpoints)... I didn't check, but I would bet since Sanyam submitted these changes not a lot of updates happened in that area. Also: there might have been some small parts of the REST API that were not mapped at all. If I would bet again then I'd say the Swagger file we have covers maybe 80% (again, not scientific, could be more, could be less) of the entire API which is more or less accurate (i. e. isn't missing any attributes, has all types correct etc.).
Now that we have a Fineract Java client (code generated based on the Swagger descriptor) as an official module we could use that client in the integration tests. That would help with 2 things: reveal any wrong Swagger mappings immediately and remove a ton of handcrafted boilerplate REST Assured client code (that makes up probably half of the integration test code); could help us make the integration tests a bit more appealing. I don't think that the integration tests - as they are now - cover 100% of the REST API (don't remember that we have too many pull requests in that area either), but I think it would be a good start to use the official Fineract Java client... this would make any missing pieces more visible. Mid/long term I think the best solution would be to fix the JSON mapping in all REST resource classes. Instead of feeding Google GSON with raw JSON strings and manually mapping it to Java classes we should use the Jackson parser (pretty much standard in Spring Boot apps and really fast) and let it do all the de-/serialization and mapping to Java. Again, that would make a ton of code (10%? 15%?) disappear... code that we don't have to maintain and test. For that to happen we would need to replace those JSON string blobs with proper types (DTOs) in the REST resource classes. Once that is in place then the whole Swagger stuff (or OpenAPI for that matter) is just a case of simple annotations and we can ditch all these manually maintained helper classes. When we add new REST endpoints then we just have to remember to put proper annotations everywhere, easy. Side effect: makes API requests/responses faster... Cheers, Aleks On Sat, Oct 23, 2021 at 5:27 PM Ed Cable <[email protected]> wrote: > Chinmay, Michael, and Manthan, > > We were running into some questions regarding the swagger definitions. Are > they generated from source code and can be used to generate client > libraries? If so, does it currently cover all of the APIs within Fineract > 1.x? > > We have been reviewing the fineract-client email threads > http://mail-archives.apache.org/mod_mbox/fineract-commits/202010.mbox/%[email protected]%3E > and gist report > > https://gist.github.com/Grandolf49/f79537436a467dac0baa9458a38290c5 > > but still had some doubts. > > @[email protected] <[email protected]> Can you share what additional > questions you have? > > Thanks, > > Ed > > > >
