Comment by mooreds | Hacker News Reader

Comment by mooreds | Hacker News Reader

Parent Full thread

I talked to a startup ( https://stainlessapi.com/ ) about a service they provide where they take an OpenAPI spec and build good SDKs on top of it. This included making sure they are idiomatic, included examples, handled exceptions (Edit: like if one SDK consumer needs a slightly different thing because they use a different, custom API, not like network or language exceptions) if needed, and some other goodness. I passed for now because they don't have the language support we need and I am not sure if we need their level of sophistication, but others may benefit from talking to them. (I think the founder helped build Stripe's API docs, IIRC.)

As we head down our OpenAPI path (https://github.com/fusionauth/fusionauth-openapi has only been built for the last 9 months), I'm very interested in stories like yours. We're very interested in quality SDKs that are easy to update. But since we control the OpenAPI spec for the product, we might have an easier time than you in some ways.

Thanks for sharing!

I prefer graphql because of this.

It's a huge pain to maintain open API files and the generators are of varying quality supporting different specs. They also handle some parts differently in the output.

Which generator have you used for typescript? There are 4 of them and all of them have different issues.

I find the axios one the most stable but keen to know.

How do you also handle refreshing token, incepting request while passing the client through configuration in these?

I find interception and changing response breaks some of the client methods without a way to handle the failure.

Any example or resources you found useful would be appreciated.

We are still early on our journey, but I'll share this post with the Stainless folks (who are further along); maybe they'll chime in.

It shouldn’t be a pain to maintain OpenAPI files.

The same code you write to validate your request/response should automatically generate the OpenAPI see my comment here:

https://news.ycombinator.com/item?id=33221395

Not everyone starts out with this in mind though.

Many legacy codebase don't have an easy way to add schema and make code changes so you end up maintaining a separate file to avoid making changes in the codebase.

> The same code you write to validate your request/response should automatically generate the OpenAPI see my comment here

Or even better the opposite: I have a mini-framework [0] which does the validation and routing based on an OpenAPI spec, so the devs can focus on writing the business logic.

[0] https://pyapi-server.readthedocs.io

Not that painful when you’ve a dedicated API designer or API writer, or when the teams realize the importance of maintaining OAS files as the single source of truth of API design.

Edit: typo.

Reply on news.ycombinator.com