swagger-codegen

> unless the author is using async/await as variable names (and i wonder why they would) Kubernetes-cli did, [0] inadvertently due to code generated by Swagger. [1] That doesn't mean only that project either - it means anything _depending_ (not necessarily directly!) on it is also broken under 3.7. [2] [0]: https://github.com/kubernetes-client/python/issues/558 [1]: https://github.com/swagger-api/swagger-codegen/pull/8401 [2]: It bit me.

I have made negative experience with using a custom swagger-codegen [0] template - the library is quite diffuse with no clear direction in which PRs are merged and which aren't, making it a mess to read and extend. I have however, managed to generate the exact Typescript bindings I wanted using it. In contrast, I have been using NSwag [1] to generate C# client code with far greater comfort, and it seems to support multiple Typescript clients already. [0] https://github.com/swagger-api/swagger-codegen [1] https://github.com/RSuter/NSwag

In my particular case, I want to use aiohttp on Python, which swagger codegen supports client generation for but not yet server generation (but see https://github.com/swagger-api/swagger-codegen/issues/7451). Admittedly, gRPC doesn't support asyncio either (https://github.com/grpc/grpc/issues/6046), but gRPC has its own server frameworks already, and is not as well suited for the kinds of applications where you'd want a Python server anyway. But Swagger Codegen is.

That is in no way different than REST: 1. (same) 2. Based on the screen designs and workflows, front end dev team writes the REST contract that they want. They mock the endpoints (i.e. using nock [0] or Angular's MockBackend) for the contracts and come up with the DTO definitions. 3. Backend folks start implementing the REST endpoints by orchestrating microservices (or by creating a REST service facade for an existing REST API). 4. Once the backend REST endpoints are done, switch out the mock endpoints for the real ones There is no need or benefit for using GraphQL here, all this can be done with REST already. Tooling around REST is great, i.e. you could use TypeScript to generate .d.ts files for your REST Dtos based on the swagger API schema [1]. Or with plain JS, use a JS runtime library that validates the DTO schematics/REST contracts

Few implementations add hypermedia support in the real world. For one, Swagger is for humans not machines to consume. At it's core it is a way to standardize documentation that can be easily displayed to humans. c# - https://github.com/Azure/autorest Java - https://github.com/swagger-api/swagger-parser/blob/master/RE... And basically everything else. https://github.com/swagger-api/swagger-codegen/blob/master/R...

> Should they do the same thing as you did? They can, I recommend they look at the swagger-codegen[0] api stub templates. There clients as well. [0]: https://github.com/swagger-api/swagger-codegen/tree/master/m... > At some point, you write a library right? Normally a flask-ext forms around a established python library. Yes now we are back at the tight integration problem, but at-least your knowledge of the py library will not be lost in another eco-system. > I wish the Django ORM were ripped out of Django so we could have libraries that depend on Django's ORM without them depending on the entire Django stack... Django ORM support SQLAlchemy's model declarations... Then we live in a world where you can swap out the ORM API at the application layer, but have libraries that are compatible with both and don't need to be reimplemented for bot

Have you looked at dumping json-schema? Because then something like json-editor[0] will just work out of the box. Got extensively tested with swagger v2(openapi)[1]. After the json-schema you write a quick swagger spec and modify a couple of mustache templates[3] to generate a crud interface for server and client. In your language of choice. All with one magic yaml file; but file format agnostic as well; Personally I struggle to read the json format. [0]: https://github.com/json-editor/json-editor [1]: https://github.com/swagger-api/swagger-editor/tree/2.x [3]: https://github.com/swagger-api/swagger-codegen/

If you're defining your APIs using Swagger/OpenAPI (https://swagger.io/specification/), you can autogenerate Rust client and server stubs using the standard Swagger code generators (https://github.com/swagger-api/swagger-codegen/). In case you're not familiar with Swagger/OpenAPI, it's a format for specifying (generally REST-ful) HTTP APIs. The key benefit over just writing your API directly in Rocket is that you specify your API once and then generate client and server implementations that join up - even if they're in different languages. (I did a lot of the development work on the "rust-server" Swagger codegen, and blogged on it at https://www.metaswitch.com/blog/metaswitch-swagger-codegen-f...)