Live data from Hacker News

OpenAPI Generator allows generation of API client libraries from OpenAPI Specs

github.com

41–50 of 73 posts

Re: OpenAPI Generator allows generation of API client libraries from OpenAPI Specs

#41
I was very excited about this project when I first encountered it as it seemed to be the best centralized community-driven way to generate code for multiple languages and supporting v3.

The more time I spent with it the more disappointed I became. The reason why you are forced to write Java and write your own generator alongside the rest of the project is unclear to me. Extending the mustache templates is a pain (and handlebars experimental). Every little change you want to make requires you to change the library itself. Most generators I looked at (TS clients, Go clients and servers, Python clients) generated dubious code and project structures for actual usage.

My current approach to deal with all of this e.g. in Go server generation is to output to some temp directory and have (long) post generation scripts parse the current and generated AST to (1) restructure to my liking, (2) merge changes where appropriate (the generator would overwrite your code otherwise) and (3) generate helper files with Go templates, which are actually pleasant to use. (2) is necessary if you don't want to have generated maps all over the place to access the handler for this route, the middleware for this other one, etc. You won't have to edit generated files, but good luck figuring out what's going on. As long as you clearly state what methods can be edited and which ones are always replaced with the generator output you should be fine with (2).

You may be thinking:

> why do all of this instead of writing your own generator?

to which I answer: Touché.

Re: OpenAPI Generator allows generation of API client libraries from OpenAPI Specs

#42
I tried using it as a Go code generator (I only needed structs and marshaler / unmarshaler helpers), but it ended up being way too difficult to use and I couldn't get it to work properly. After a bit of searching, I bumped into Deepmap's implementation https://github.com/deepmap/oapi-codegen which works great. They even added support for oneOf, anyOf and allOf which makes things a lot easier.

Re: OpenAPI Generator allows generation of API client libraries from OpenAPI Specs

#43
I’ve been trying to use this to generate sane, idiomatic Kotlin models, and am so far a little frustrated by the choices the generator makes - especially with regards to how to represent `anyOf` And `allOf` constructs.

Has anyone had success with generated Kotlin? I’m also curious if there are other Kotlin generators out there.

Re: OpenAPI Generator allows generation of API client libraries from OpenAPI Specs

#45
post #30

We used this to generate api functions for our react application and then discovered and switched to Orval. It generates react query functions instead of „normal“ axios functions. Also it has support to generate a complete api mock with msw + faker.js - really nice.

This looks cool. Previously I was only aware of this blog post regarding React Query hooks from OpenAPI schemas: https://xata.io/blog/openapi-typesafe-react-query-hooks

I take it that you’re happy with Orval. What are the biggest downsides?

Re: OpenAPI Generator allows generation of API client libraries from OpenAPI Specs

#47

Used OpenAPI Generator a few times and I'm happy with it. In my latest React Native project I generate the API client and inject functions into React Query. I know there's Orval that aims to generate React Query right away but I wasn't happy with its developer experience.

What are the DX issues you found with Orval?

Re: OpenAPI Generator allows generation of API client libraries from OpenAPI Specs

#48
I’ll soon discover whether doing this is a good idea or not. Will it encourage good practices or hinder them?

Remember that you don’t have to generate both your server and client APIs from the schema (schema first). Many API servers (I’m particularly aware of OpenAPI and Sanic from Python land) allow you to export the OpenAPI definition from your existing API (code first).

Re: OpenAPI Generator allows generation of API client libraries from OpenAPI Specs

#49
I've found apenapi generated clients very helpful with statically typed languages and very unhelpful with dynamic languages.

For dynamic languages I'd recommend using an http library directly.

Consider the code without a generated client code:

client.get("/hello")

And the code with a generated client

client.hello()

In a dynamic language they're about the same.

But in a statically typed language

- I know the second case is calling a route that exists

- The response is typed

- If there is request data or query parameters the language helps me use them correctly

- My editor displays documentation about the request if I hover over it, including if it has been deprecated

Re: OpenAPI Generator allows generation of API client libraries from OpenAPI Specs

#50
I recommend steering clear of this project entirely - if you really care use something like gRPC instead. Every time I've used it, it has failed spectacularly to generate models as promised and I've had to write the clients by hand anyway. There are just far too many bugs in the respective language generators and it all seems to fall apart when you start using anyOf, oneOf, etc.

It only takes a quick stroll of the issues to find that many features of OpenAPI aren't supported in certain generators, so it's a total waste. I do still like OpenAPI as a design tool and it produces very human readable documentation as well, so it's still useful if you intend to only use it just for that. Just keep your expectations very low when it comes to generation.

Edit: I forgot to mention that clients are subject to breakage if you change the names of models - model names are not actually a part of the contract in my opinion - only the protocol aspects should be (path, params, body, etc.). I don't see how they would solve this but it's a major pain. If you imagine writing a client yourself, it would not break if you tweaked a model name, so this is a huge downside.

I have a scenario where the model names are only there for branding (a numerical enum that has a human readable model name), but are now being hardcoded into the spec in a way I didn't want. I really didn't want to give the models generic, unreadable names in the docs but that seems to be what OpenAPI wants me to do.

Post reply on HN