[cjonas]

I spent the last year and half working on a project where we planned to use OpenApi/AsyncApi to generate typed api clients and validate api requests between all our services and applications (written in typescript & C#).

Going into it, I thought we'd be on a well traveled path, but that was far from the case...

Typescript has some decent code generation packages (although fragmented) and request validation can be hacked via AJV... But tooling around C# was halfbaked at best.

In the end, I didn't really feel like OpenApi provided the API "contract" I had originally hoped for.

If I could start over, I would probably use something like gRPC for internal service communication (would maybe still use OpenAPI for any public API)

[BuckyBeaver]

This is exactly what I expected: a well-traveled path. I assumed I was doing something wrong or just not "getting it," and spent weeks digging through the scattered doc and poring over Java code and templates... and the generated code, which wouldn't even compile. In our case, we needed C++ for client and server... a hugely under-served scenario.

Using OpenAPI and Stoplight was very useful for thinking the API through and how the whole thing could work, but the code-generation aspect was a total bust. And talking to some new colleagues later who had some knowledge of it, I found that I wasn't alone in my opinion that the tooling is trash.

Even worse, the prevailing opinion on the ecosystem is so poor that it might even be a professional liability to propose (or admit to) using it. The implication was that it (or at least the code-generation facilities for it) is by and for people who don't know what they're doing. Oof.