Ask HN: Is anyone using REST API code generator in production?

20 pointsby craig_murrayvor 7 Jahren16 comments

I'm aware of some comparisons conducted a while ago on some API code generators listed below but these comparisons seem to be outdated:

- apimatic.io: https://apimatic.io

- AutoRest: https://github.com/Azure/AutoRest

- Swagger Codegen: https://github.com/swagger-api/swagger-codegen

- OpenAPI-CodeGen: https://github.com/Mermade/openapi-codegen

- OpenAPI Generator: https://github.com/OpenAPITools/openapi-generator

- go-swagger: https://github.com/go-swagger/go-swagger

Is anyone using these tools in their environment? Any caveat?

5 comments

wing328hkvor 7 Jahren

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...).

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...) 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...).

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

bbdouglasvor 7 Jahren

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_murrayvor 7 Jahren

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

craig_murrayvor 7 Jahren

Thanks "wing328hk". I'm aware of the fork and the 4.0.0 release.

The list looks impressive and I look forward to more users sharing their real life experience adopting these code generators.

Kudos to your work on open-source projects.

mwoodlandvor 7 Jahren

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_murrayvor 7 Jahren

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

craig_murrayvor 7 Jahren

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/bq64ek/compare...

lakenvor 7 Jahren

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_murrayvor 7 Jahren

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

ethan92492vor 7 Jahren

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_murrayvor 7 Jahren

Thanks for sharing the positive experience with OpenAPI Generator

thiago_fmvor 7 Jahren

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_murrayvor 7 Jahren

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.

willio58vor 7 Jahren

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.

atianvor 7 Jahren

Good for you.

whttheuuuvor 7 Jahren

haha