
Ask HN: Is anyone using REST API code generator in production? - craig_murray
I&#x27;m aware of some comparisons conducted a while ago on some API code generators listed below but these comparisons seem to be outdated:<p>- apimatic.io:  https:&#x2F;&#x2F;apimatic.io<p>- AutoRest: https:&#x2F;&#x2F;github.com&#x2F;Azure&#x2F;AutoRest<p>- Swagger Codegen: https:&#x2F;&#x2F;github.com&#x2F;swagger-api&#x2F;swagger-codegen<p>- OpenAPI-CodeGen: https:&#x2F;&#x2F;github.com&#x2F;Mermade&#x2F;openapi-codegen<p>- OpenAPI Generator: https:&#x2F;&#x2F;github.com&#x2F;OpenAPITools&#x2F;openapi-generator<p>- go-swagger: https:&#x2F;&#x2F;github.com&#x2F;go-swagger&#x2F;go-swagger<p>Is anyone using these tools in their environment? Any caveat?
======
wing328hk
I'm the top contributor to both OpenAPI Generator and Swagger Codegen. Just
want to share a bit more to ensure everyone is on the same page.

OpenAPI Generator is a fork of Swagger Codegen. The fork took place in May
2018 - a year ago. For the reasons behind the fork, please refer to the Q&A
([https://github.com/OpenAPITools/openapi-
generator/blob/maste...](https://github.com/OpenAPITools/openapi-
generator/blob/master/docs/qna.md)).

Fast forward to today, we just released OpenAPI Generator v4.0.0 - the 20th
release since the fork, thanks to the awesome contributions from the vibrant
developer community. Please refer to the release note
([https://github.com/OpenAPITools/openapi-
generator/releases/t...](https://github.com/OpenAPITools/openapi-
generator/releases/tag/v4.0.0)) for more information about the release.

For a list of companies and open-source projects using OpenAPI Generator in
production, please refer to the project's README
([https://github.com/OpenAPITools/openapi-generator/#4---
compa...](https://github.com/OpenAPITools/openapi-generator/#4---
companiesprojects-using-openapi-generator)).

I hope you will find OpenAPI Generator useful in your work and personal
projects.

~~~
bbdouglas
Yelp uses openapi-generator to create REST clients for the Java services
within our microservice architecture. Defining the API's in Swagger and auto-
generating the client code is a big improvement in understandability and
maintainability over what we used to do, which was to write bespoke clients
for each microservice.

Openapi-generator is opinionated when it comes to how the data model classes
are defined, and the feature set depends on which underlying HTTP library you
choose (Jersey, Feign, Retrofit, OkHttp, etc), so we needed to invest some
time when getting started to make necessary adjustments. But overall it has
proven to be robust and meet our needs.

~~~
craig_murray
Right, we arrive at a similar conclusion. We will need to tweak the templates
a little bit to meet our needs.

------
mwoodland
I used them at my financial services software company. They've made it through
to our client's test environments, but as they're a large financial company
things move very slowly and they're not in production yet.

We wanted to ensure our APIs were backwards compatible and we felt like the
best way to ensure that would be by making them contract led. This also means
that we can design our APIs and write the spec files and get feedback without
having to implement anything.

So our APIs are defined by the swagger spec files.

The open API generator was perfect for this as it meant we could write our
spec files, and then generate interfaces for our spring boot application based
on the swagger spec files.

Then to implement the API all we need to do is implement the interfaces that
the open API generator generated for us.

The generator is very flexible (the mustache files allow you to modify what
gets generated) and the community - particularly wing328hk were very helpful.

We submitted a number of pull requests with changes that helped make things a
bit smoother for us, and require less custom configuration of the generator.
The development community was very active and happy to provide feedback and
accept our pull requests.

All in all I would definitely recommend a contract led approach (and the open
API generator) for developing RESTful APIs.

~~~
craig_murray
I like your recommendation on the contract led approach. The active
development community is definitely a big plus.

------
craig_murray
I originally started this discussion in Reddit but they don't allow self-post
(or text-post) so we will continue the discussion here instead.

You can still find some user stories in the following Reddit posts (hidden
from public):

\-
[https://www.reddit.com/r/programming/comments/bps96v/questio...](https://www.reddit.com/r/programming/comments/bps96v/question_is_anyone_using_rest_api_code_generator/)

\-
[https://www.reddit.com/r/programming/comments/bq64ek/compare...](https://www.reddit.com/r/programming/comments/bq64ek/compare_autorest_apimatic_and_swagger_codegen_2016/)

~~~
laken
It's not that Reddit doesn't allow self-posts, it's because you asked the
question in a subreddit that isn't mean to have questions in the title, which
is also why they removed the self-post functionality from their subreddit.
There is /r/AskProgramming for that which allows self-posts.

~~~
craig_murray
That's correct. Next time I'll try /r/AskProgramming to ask similar question.

------
ethan92492
I've loved using OpenAPI Generator. This dramatically simplifies the
propagation of staticaly typed responses to clients, keeping client code
easily in sync with the latest server classes. It works really well!

~~~
craig_murray
Thanks for sharing the positive experience with OpenAPI Generator

------
thiago_fm
Just use GraphQL. REST is dead.

I've had a lot of experience with REST & JSON API and those "generators" or
abstraction people create always end up being very inflexible. With GraphQL,
you have full control on what you return, as well full control over how you
want to change your data. Easy to avoid n+1 etc. Maybe that's just me, but I
think this question is already answered. Took us a few years to discover a
better way.

I've been using GraphQL for the last 2 years and haven't had ANY complaints so
far. It doesn't try to push you some mindset of how should things look like
and instead just try to get out of the way, enabling you do craft requests and
responses as you'd like. Of course, with that power, you need to make sure
that things stay consistent, but that problem also exists for REST/JSON API's.

~~~
craig_murray
GraphQL is definitely something we're looking into. From what we understand,
it's not a silver bullet to every single problem. It totally makes sense in
certain cases (e.g. facebook).

Glad to know you have very positive experience with GraphQL so far.

~~~
willio58
I’m using both on a project I’ve been working on. Anything that doesn’t work
nicely with graphQL I just toss into the REST api.

