Comment by ShadowBanThis01 | Hacker News Reader

Comment by ShadowBanThis01 | Hacker News Reader

ShadowBanThis01

I find it depressing how design systems, which come and go pretty quickly it seems, suffer from profoundly shitty design. Figma is certainly no exception.

Also disappointing is the state of design-system support for programming. I know not everyone wants or believes in code generation, but I find it incredible that this also still sucks. I'm building the front and back end for a new application now, and the amount of manual syncing between them hasn't changed in a decade.

A while ago I had to design a new API for a company's products. After some research, I defined it with OpenAPI. I then wasted weeks or months trying to find

A. Tools that actually supported the current version (3.1), which is the only one that's acceptable because of glaring gaffes in previous specs.

B. Code-generation tools that supported the languages we needed

C. Code-generation tools that worked at all.

It is an absolute shitshow. None of those things is available or works. The moral is that common problems faced by lots (if not most) of us programmers or system designers are still not solved. Don't assume that you're the problem. I made that assumption, but in the end no... the tools and ecosystem were simply shambolic and I would just have to write my own or just strap it on and do the tedious manual work.

To offer a different perspective, I believe the ecosystem around OpenAPI has vastly improved in the last year or so, at least in my technology stack (Node.js & TypeScript).

- I am currently building a product in the space and I've got competitors tackling the problem from many different angles

- Lots of tools & libraries to choose from when working with OpenAPI specifications (yes, lots of outdated stuff too)

- New platforms like Platformatic are making big bets on OpenAPI and building features around it

- People are using OpenAPI specs with ChatGPT to make custom integrations

For code-generation in particular, there's a handful of libraries that use OpenAPI specs to "glue" the backend and frontend together in different ways (ts-rest, openapi-fetch, openapi-types, orval, feTS). Many startups also offer seamless OpenAPI -> SDK generation.

It's an obvious resource at this point, but this site[1] is a good starting point.

[1] https://openapi.tools

Interesting, thanks. I haven't looked at it in about a year. If I remember correctly, the seemingly dominant generator is OpenAPI-Generator; the one that's written in Java with lots of independent modules for various combos of language and frameworks, using Moustache templates.

Among the available generator modules, there's way too much emphasis on Node. Heaven forbid you're using C++, because there was only one generator for that and it doesn't even create code that compiles.

Trying to create a custom generator means wading through reams of duplicated and outdated documentation in various places, and never even finding a list of the data entities that OpenAPI-generator extracts from an OpenAPI document.

Later on I mentioned OpenAPI to some developers (maybe on here, even) and they agreed that the ecosystem sucked so profoundly that even bringing it up in a professional development setting might be a liability to your reputation.

I consider anything before OAS 3.1 useless because it bafflingly prohibited you from applying a description to a reference. This means if you defined a data structure and used it in various places throughout your API, you couldn't annotate each use of it... largely defeating the purpose of the entire document. WTF! A blunder of that magnitude doesn't inspire confidence.

Looking at the page you mentioned, check out the list of server generators. Almost none are up to date. Once you whittle it down to the ones that support OAS 3.1, you wind up with most languages being unsupported.

And finally, the OAS editor I was using, StopLight Studio, has been discontinued; it was never updated to OAS 3.1 anyway. I haven't found a non-Web-based replacement for it, and that resources page doesn't list one that I can see.

Thus far, it's still looking pretty weak.

I think you're right. I see a lot of tools for Node.js, Python, and even Rust, but not so much for other languages.

I'm a bit frustrated with openapi.tools too, I think they could do a better job curating and keeping the tools updated. Their issues page on GitHub makes it look like they are not actively maintaining it. I actually bought openapi.cool this week and I'm thinking of building my own version of it.

Reply on news.ycombinator.com