That’s a nice approach, and I (being a frontend dev) like the attitude very much 👍 There are some considerations though that I’d suggest to take into account, as I genuinely believe that there’s no “one size fits all” solution.
Swagger UI is just a tool, one of many, which makes work with OpenAPI specification generated from BE code a bit more convenient. There’s a bunch of them. And there’s quite a few tools that allow generating frontends (framework-specific btw) from OAS in a flexible way.
OAS is not just the way to “read BE”, at least in team work. It’s a living documentation and a contract, BE-FE interface so to speak, which allows to reason about different features without digging into implementation.
OAS is a good industry standard. And it allows to build framework-agnostic tools on top of it. That’s probably a more universal approach, as it provides a way to work with APIs both in design-first and code-first way, either you use swagger, or stoplight, or whatnot.
I’m pretty sure none of that is a news for you, so it’s not to bring some controversy to the topic, rather an opinion in response to the suggestion in summary section. It’s not just that universal answer probably.
But I will definitely give it a try as a big fan of Nest.js myself 👍
I agree with your insight and always try to follow OAS standards.
The reason for introducing this tool is that TypeScript's openapi-generator is immature, so many front-end developers read and write interaction code by themselves without automating SDK generation.
Of course, as @nestia/migrate is not matured yet, it could be another immature SDK generator for someone's insight \o/.
You may try "npm init rpc", it's also generate client sdk based on server implementation. You don't need to specific the interface in multiple places with it.
I use the create-* package to generate the skeleton of backend server, and it generates the typescript client on the fly.
I can then use the client sdk in SPA (angular or react).
I know there are at least 10+ e-commerce projects based on this design (booking, office automation, e-shop, e.t.c.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That’s a nice approach, and I (being a frontend dev) like the attitude very much 👍 There are some considerations though that I’d suggest to take into account, as I genuinely believe that there’s no “one size fits all” solution.
I’m pretty sure none of that is a news for you, so it’s not to bring some controversy to the topic, rather an opinion in response to the suggestion in summary section. It’s not just that universal answer probably.
But I will definitely give it a try as a big fan of Nest.js myself 👍
I agree with your insight and always try to follow OAS standards.
The reason for introducing this tool is that TypeScript's
openapi-generatoris immature, so many front-end developers read and write interaction code by themselves without automating SDK generation.Of course, as
@nestia/migrateis not matured yet, it could be another immature SDK generator for someone's insight \o/.Have you tried swagger-typescript-api?
You may try "npm init rpc", it's also generate client sdk based on server implementation. You don't need to specific the interface in multiple places with it.
That's interesting. Do you use it for something? What does it make under the hood actually? The package and repo look quite weird and obscure.
I use the create-* package to generate the skeleton of backend server, and it generates the typescript client on the fly.
I can then use the client sdk in SPA (angular or react).
I know there are at least 10+ e-commerce projects based on this design (booking, office automation, e-shop, e.t.c.)