Comment by hardwaresofton | Hacker News Reader

Comment by hardwaresofton | Hacker News Reader

For those who don't know already -- one of the best parts about the OpenAPI spec is that it allows generation of the clients and servers and the OpenAPITools/openapi-generator[0] is the tool that does that effortlessly.

If you want to take your CI pipeline to the next level you can run it (dockerized, if you want) from a CI step to generate and commit + tag a completely separate repo to have your API SDK generation completely automated. I've written a little about the dumbest possible way you could do it (i.e. manually writing YAML)[1] for when you don't have proper framework support.

openapi-generator also has some really awesome new features and support for different languages, most recent big release was 4.0 (and most recent as of this post is 4.2.3)[2], been meaning to write a bit about that as well since their haskell support gets better and better every time. Super awesome & convenient project, the value being delivered for free is unreal.

[0]: https://github.com/OpenAPITools/openapi-generator

[1]: https://vadosware.io/post/quick-intro-to-manual-openapi-v3/

[2]: https://github.com/OpenAPITools/openapi-generator/releases

I'm a very heavy OAS user across languages (C#, Java, TypeScript, Python).

I've tried both the client and server generators for many languages, and the output was always unusable garbage.

It's bettee to just write your own server and use OAS for validation and type defs.

Yeah I disagree -- I personally found the TypeScript client to be quite usable, but maybe you've hit more edge cases than I have!

Are there any issues for these corner cases you've filed that could use more attention? I don't maintain openapi-generator but I can definitely forward them to the maintainers

It depends on both the target language (in that the quality of what's generated is variable, and the benefit it gains you is also variable based on how easy it is to get something usable in that language), and how well they defined the API using the spec. I've had a few times where the spec had slight inconsistencies and bugs that made working through and debugging the generated output take as long or longer than it would take to implement a client from scratch for the 20% of the API I actually need.

I am currently evaluating whether I want to use the generators for a typescript node.js/react project.

Which typescript generator are you using? Do you use typescript on the backend too and if so is it easy to keep the generated type definitions in sync? Also for backend what do you use for json schema validation?

I would recommend the `typescript-angular` generator as a starting point for evaluation as it's pretty active and we just added Angular 9 support.

I used and like typescript-axios

This might sound crazy but I wound up writing my own generator and was quite happy with the result (and use it in prod).

How much effort was it? I actually don't the that's such a bad idea.

It was about three weeks of coding (in addition to normal duties), I had to write two libraries:

https://github.com/ityonemo/Exonerate/

https://github.com/ityonemo/Exaggerate/

With OpenAPI spec < 3 there's no support for sum types. This at least for me lead to semi heavy refactoring of the client lib (for Dart lang).

It's worth upgrading to 3. Tooling support is now better for 3 than 2.

I absolutely would but my web framework doesn't have support for it.

Having used the TypeScript client generator and contributed the F#/Giraffe and F#/Azure Functions server generators, I disagree :)

Do you literally mean unusable, or it just didn't fit your stylistic preference?

For some languages, it doesn't even compile. For others, there are OAS features (e.g. allOf, anyOf) that weren't handled correctly.

I actually still haven't found a single implementation of a OAS consumer (mock server, type generator, etc.) that implements the whole spec correctly.

OK, well it's certainly not intended to support the whole OAS spec (and indeed, the ones I contributed certainly don't, just the parts I needed at that specific point in time). This is particularly the case with OAS2->3.

The intention is that people use the generators as a base, and if there's something you need that's not implemented, you write the implementation and contribute it back. No single person is going to implement 100% of the spec in their day job, so as an open source project, coverage will be patchy until enough people extend the implementation to cover their own API surface area.

I don't think "it doesn't cover the whole spec" is fair grounds for criticism (though out-of-the-box generator errors are another story).

> I don't think "it doesn't cover the whole spec" is fair grounds for criticism (though out-of-the-box generator errors are another story)

A spec is useless if it's not fully implemented by any library. Also, I'm fine with imperfect FOSS, but it's frustrating to not know that implementation is incomplete or what exactly is missing. You end up doing trial and error.

All I'm saying is that OAS generators are not net time savers, which you supported yourself by saying that sometimes fixing an implementation is up to the user. That's not a criticism of any person, just a fact.

We built guardrail[0] because we weren't happy with the output of the reference generators. We only support Java (Dropwizard) and Scala (akka-http, http4s, and endpoints.js) so far, however.

[0] https://github.com/twilio/guardrail

Love to see efforts like this -- if you all build a better java generator (and there's the reference ones to fall back on), the whole community benefits.

Agreed. We have opted to write our own clients so we have full control over how the HTTP calls happen, but we use the models generated by OAS tooling as a happy medium.

I've been investigating their generators for work these last two days, and their java generators produce code that doesn't even compile -- when ran on their own schema examples! Total garbage. OneOf (for the polymorphism aspect of inheritance) is the feature that breaks every single one of them.

We just added oneOf support to the Java client generator a few weeks ago. The enhancement will be included in the upcoming 4.3.0 release. You can give it a try with the latest snapshot version for the time being.

Ref: https://github.com/OpenAPITools/openapi-generator/pull/5120

I've had multiple experiences with the generators. I've used it purely to generate the models themselves, doing the APIs (which were usually straightforward REST calls anyway) directly.

I've also written customized templates that removed a lot of the cruft (iirc the JS or TS generator decided to output an API client in three different flavors). Of course the problem there was that the particular generator did not have all code generation in (overridable) templates, but also some hardcoded.

The part about generating clients and servers is the part that has always been the least interesting to me, and the part that I wish hadn't been a goal, because it means bending over backwards to not break the generators. This has really hurt the descriptive power of OpenAPI.

If a viable API documentation tool based on raw unmodified jsonschema with some additions to be able to describe the HTTP actions and parameters, and with the ability to visualize it as documentation, came around then I'd switch in a heartbeat.

Today is your lucky day! Have you heard of jsonschema[0]'s hyperschema[1][2]?

[0]: https://json-schema.org

[1]: https://datatracker.ietf.org/doc/draft-handrews-json-schema-...

[2]: https://json-schema.org/implementations.html#hyper-schema

To add to your useful comment I’d like to suggest the Stoplight desktop editor (electron app).

I’ve tried pretty much all GUIs that existed a year ago or so, and started with Apicurio which was good, but was missing support for oneOf, allOf and the like.

Switched to Stoplight and it has been great! Love that you can just manage your spec in a repo along with the project.

Reply on news.ycombinator.com