Our primary advantage right now is extensibility and simplicity. We are working with users that want to implement features that cant be generated with current generators and we enable them to implement those. Our generator does work for those basic use cases when you want a client to interact with an API, but if you need something more, like state management, sse, etc, we make the SDK easy to work with and extend.
If you've used some oss generators, their code is often a complete headache to just read. OpenAPI generator is a good example.
THis is very similar to what Oxide.computer has done. They wrote their own tooling to go from Rust API to spec to Rust and TS client. Very specific to their use case, but I think its the right approach. If something is wrong in the client, you probably generated a bad spec, and therefore something in the API is rotten and should be adjusted. Using the spec as an intermediate to know if upstream is bad, can be a great benchmark for developers.
My co-founder and i have a long term goal of building an end to end tooling chain for OpenAPI to generate spec and clients/tests/docs under one roof. Its definitely far off in development, but think its where devs are moving
You can write OpenAPI in JSON, which can help a bit with encompassing the complex and frankly fractured ecosystem of OpenAPI.
I have found that the tooling tends to have the problem of not knowing how to catch edge cases like webhooks, websockets, complex auth and additional logic beyond just an HTTP request. Many tools add layers of configuration and extension to work around these, but i feel it misses the mark.
I'm building Borea.dev to solve this pain by keeping the source of truth in your OpenAPI doc and allowing for custom code implementations. We support Python rn, are building out generators for multiple other languages and we're open source :P hope it helps
I understand these engines have their own full SDK for developing with the engine, but I'm curious about the external ecosystem/integrations/libraries. It isn't a space I'm super familiar with, but I'm interested in it, not only from the standpoint of it being an interesting technology I've never played with before, but also because I'm curious if there are similar issues in the game engine SDK space as there are in the application SDK space.
Or maybe even a whole different host of issues and practices. Not sure, that's what I'm looking into.
If you've used some oss generators, their code is often a complete headache to just read. OpenAPI generator is a good example.
Hope that answers your question :P