So why would I chose this? How do I even implement it on the server? There's a lot of talk about client libraries, even with OpenAPI as an output format (nice!), but what about the server side?
You never have to actually write any OpenAPI schema yourself nowadays.
This also doesn't seem to address the one problem I always had with OpenAPI: Polymorphic types. Mapping an OpenAPI schema between strongly typed languages like Scala or TypeScript. OpenAPI 3 supports this now with discriminators but most code or schema generators aren't supporting this very well or at all yet.
https://swagger.io/docs/specification/data-models/inheritanc...
The JSON[2] module for REST looks similarly impressive, but I haven’t personally used it.
1. https://github.com/manifold-systems/manifold/tree/master/man...
2. https://github.com/manifold-systems/manifold/tree/master/man...
Aren't there enough tools already for OpenAPI to do this?
Contrary to this approach, we (https://WunderGraph.com) ingest one or more OpenAPI and GraphQL apis and combine them into a backend for frontend. We have code generators for all major frontend frameworks, like react, svelte, Vue, solid, astro, etc... These don't just make calling APIs type-safe but also handle authentication, etc...
The BFF approach allows us to securely inject API keys or add a middleware using Typescript.
I'm curious what people think of this approach. Our users don't usually integrate one or two APIs but rather 20 or more. I guess it would be quite expensive if you had to write a custom specification for each service.
Very disingenuous to compare this to an LLM, it has none of the advantages and fails to differentiate itself from many preceding peers.
My current way of achieving codegen sdk w openapi is using the readme/api sdk framework maker, if you have good specs it works pretty great.
Add tests to the sdk, and you're both testing your openapi implementation, docs, and sdk in one test
Would you mind expanding on what you're talking about here? It sounds intriguing, I'm just not following.
In my case I had a backend with annotatted swagger docs, which generated the OpenAPI spec from it using https://www.npmjs.com/package/next-swagger-doc
but basically it will take any openapi spec url, and generate an SDK for it. So you'll get your named routes for free as sdk a la mySDK.allUsers() or mySDK.findUser(id) or whatever your openapi spec exposes
:-)
That's how it felt when I was developing for it. But that's because I was interested in cool new things, not decade-old, establish enterprise stuff.
I suppose it has changed a bit in recent years, but it still doesn't exactly follow trends very enthusiastically. Which can be a good thing. But also means tooling around legitimately useful new things can be quite lacking.