Appetite for alternate client implementations?

[stocky37]

Hey guys, I'm just wondering what your appetite would be for the following:

• A cleaner API that implements some oft-used use cases for clients
  • For example, something like:

    client.pokemon.byId(1) (returns Pokemon type)
    client.pokemon.list(offset=0, limit=20) (returns List<Pokemon>)

• Alternate client implementations (i.e. JAX-RS), each in a separate module, so users can choose which type of client they would like to use
  • They should all implement the above interfaces, so can be swapped out with one another if necessary
  • Standard caching wrapper that can be used with any of the actual clients

I'm basically looking at doing this myself already (see stocky37/pokeapi-java-clients for very initial ideas), I'm just wondering if you would be interested in me contributing it here or would prefer me to keep it separate.

[sargunv]

I've been considering scoping out a v3 that's easy to maintain using some code generation to actually produce the data classes and implementation from a source schema, using Ditto to aid in schema generation.

I'm not sure about JAX-RS, haven't heard of it yet. What are the use cases you see for supporting multiple client implementations?

[stocky37]

Code generation from the source schemas sounds good, but I'm not sure a tool exists to convert the schemas yet. wuseal/JsonToKotlinClass seems the closest thing, but it's only an IDE plugin. Could be a start though. I see they have a ticket in for making a maven/gradle plugin wuseal/JsonToKotlinClass#147.

As for the multiple clients - different environments generally have different restrictions or needs for what they want to run. For example, retrofit is great on mobile as many of the other similar libraries use libraries that don't exist on android. However, if you wanted to make a more complicated backend service you might want something with more performance, flexibility and config options, ss well as better non-blocking support, threadpool, caching etc. Or they might use a framework that has better integrations with one type of client. Not that retrofit isn't ok at most of the above, there are just other options that someone might prefer.

However, that doesn't mean the other options need to be accomodated in this repo.

[sargunv]

I was thinking more like transforming the data from Ditto into an OpenAPI spec and then generating all sorts of clients from that using something like Swagger Codegen.

[stocky37]

Ahhh gotcha that makes more sense. That would be great for the base client/different base clients. I see there is compatibility for most of the popular client libraries.

I guess I'm talking about a more fully featured client that implements some things that would normally be implemented on the api, but aren't implemented on PokeAPI for infra cost and performance reasons. Things like searching for a Pokémon, or filtering by generation or some other field.

[sargunv]

Ah, I see. I'd be hesitant to introduce such functionality into the client library for a couple reasons:

(1) if the function exists, people will assume it's reasonably performant, while in reality some of these use cases will essentially require requesting an entire resource type and iterating through the results. If users are made to do that themselves, they won't be surprised when it's slow.

(2) functionality like navigating relations is better suited for a GraphQL API (which I believe can also be auto-generated from a REST API's Swagger spec). Writing custom code for those use cases will quickly become a larger maintenance burden with how many models exist.

[stocky37]

No worries, I do intend to ensure it's performant with caching. Might definitely eat up some memory though when I'm done.

I'll develop something separately for now then and see if you like the look of it when it's done. Happy to leave this as-is though. :+1: