Let's say I have a backend server written in http4...

# http4k

[Arnab]

Let's say I have a backend server written in http4k. In addition to my API, I want to offer clients a Kotlin SDK. How would I go about doing this? Is it possible to just create some kind of client based on the functions that I use in the server directly? Does anyone have experience doing this? What would the folder structure look like? Or better yet, does anyone have an example of this that I can take a look at and learn from?

[dave]

Depending on the way you're constructing your app, there is some support - but nothing automated.

if you are using the OpenAPI module then you can use the Toolbox to generate a client from the OpenApi spec. This should get you most of the way.

Effectively, the functional approach has no knowledge of the structure of the routing, so it's not possible to reverse engineer the routes. We did have a way of describing the routes in v5 but it got dropped as a part of the big refactor from v5-6 🙂

[Arnab]

Hm I might have been unclear 🙂

Let's say I have a server that uses some functions from an Object like this:

Object UserRepo {

  fun getSomeUser(userId: String): User ...

}

val getUser : HttpHandler = ...

Now in my SDK, I just want to expose a function like:

mySDK().getUser(userId = "xxx") // this would just call the UserRepo.getSomeUser() function

And this is the functionality I want to expose. I don't need 1:1 parity necessarily.

Of course, exposing a OpenApi spec and asking our clients to codegen a client is viable as well 🙂

[James Richardson]

Do people actually want an SDK? Very often the way that other companies and teams write software - their expectations, style, libraries and languages differ a lot, so what you think is great, they might not like. For example sdk that I get often have poor types, use a mixed bag of logging libraries, have poor error handling etc etc, much easier for me to write to a network api/spec.

[Arnab]

Do people actually want an SDK?

Yup. Not everyone, but some people do 🙂 and we want to support them as well as those that prefer the openapi spec as a starting point.

For example sdk that I get often have poor types, use a mixed bag of logging libraries, have poor error handling etc etc, much easier for me to write to a network api/spec.

I want to handwrite this SDK to combat exactly that. Using errorhandling in SDK, we have an opportunity to have an opinionated way to support usecases.

[James Richardson]

Yeah, but is your opinionated the same as their opinionated? 🤣- that's where these things get tricky and difficult!
In your example mySDK() (which i realise is not even an example, just a concept), you'll want to construct it with urls, http clients (so ppl can test with your sdk), timeouts, retry strategies, proxies, logging or reporting stuff, events collectors etc etc.
As to writing it.. you could use your own openapi spec to generate the client? Then test it against your own fake server etc... or just write it by hand, doing the same thing...

[James Richardson]

Then does your client use exceptions, Results (which ones?), coroutines, koin, etc..

[Andrew O'Hara]

If you're using http4k-api-openapi, you can share the `ContractRoute`s between the server and client. I sometimes do this for the fakes of my external clients. Only wrinkle is that if you're adding a Security to the ContractRoute, you need to be able to override the Security to null for your client.

You can also share your DTOs, their lenses, and your samples used for the ContractRoute

[James Richardson]

I am unsure about this, as the needs of a client and server are different... a client only needs what it needs, a server sends what it does. I wonder if it might lead to unintentionally lock step version dependencies, or having to weaken nullability requirements in various places. I didnt do this though tbh, so a concern not an experience!

[Andrew O'Hara]

I'm not really sure about it either, tbh. So far, I've only done this in server apps where the client and fakes share the same contracts and lenses. I'm working on a new project that will distirbute clients using the same contracts and lenses though, so we'll see how it goes.