4 ms·

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 h

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.

mooreds 4y ago
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.
aserafini 4y ago
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 https://news.ycombinator.com/item?id=33221395
- searchableguy 4y ago
  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.
- BerislavLopac 4y ago
  > 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 https://pyapi-server.readthedocs.io
remoquete 4y ago
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.
NonNefarious 4y ago

mooreds 4y ago

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.

aserafini 4y ago

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 https://news.ycombinator.com/item?id=33221395

searchableguy 4y ago
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.
BerislavLopac 4y ago
> 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 https://pyapi-server.readthedocs.io

remoquete 4y ago

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.

NonNefarious 4y ago