11–20 of 22 posts
> Our goal is to remove the need to develop custom client SDKs for an REST API. Aren't there enough tools already for OpenAPI to do this?
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...
What does this do better than OpenAPI? OpenAPI has many code generators. And more importantly: Many servers support it, making it really easy to implement. 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...
Looks interesting 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
I searched for what you're describing here, and I don't believe I found the service you're describing - I'm not seeing how it could generate code. 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
> Our goal is to remove the need to develop custom client SDKs for an REST API. Aren't there enough tools already for OpenAPI to do this?
What does this do better than OpenAPI? OpenAPI has many code generators. And more importantly: Many servers support it, making it really easy to implement. 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?
Don't see much of a reason to use it, its also important to mention that code generation goes both ways. You can generate the schema from a service in FastAPI or Spring and generate the client code from that schema. There are already existing code and schema generators for almost every strongly typed language and web framework, including Go, Scala, Typescript, Java and Rust. You never have to actually write any OpenA…
> Our goal is to remove the need to develop custom client SDKs for an REST API. Aren't there enough tools already for OpenAPI to do this?
to be fair a lot of them are absolutely terrible. The top .NET one seems to be maintained by very unprofessional amateurs, has ~> 1000 open issues, some open for years, and definitely doesn't do multipart encoding correctly. Not that problem would be solved by having yet another spec.
> Our goal is to remove the need to develop custom client SDKs for an REST API. Aren't there enough tools already for OpenAPI to do this?
to be fair a lot of them are absolutely terrible. The top .NET one seems to be maintained by very unprofessional amateurs, has ~> 1000 open issues, some open for years, and definitely doesn't do multipart encoding correctly. Not that problem would be solved by having yet another spec.
Earlier quoted context omitted.
to be fair a lot of them are absolutely terrible. The top .NET one seems to be maintained by very unprofessional amateurs, has ~> 1000 open issues, some open for years, and definitely doesn't do multipart encoding correctly. Not that problem would be solved by having yet another spec.
Yeah the .NET ecosystem around openapi is horrible. I at least want the typescript client story to be good
:-)
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.
Earlier quoted context omitted.
Yeah the .NET ecosystem around openapi is horrible. I at least want the typescript client story to be good
> Yeah the .NET ecosystem (...) is horrible :-) 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.