81–90 of 121 posts
What is wrong with protobufs and grpc?
Both of them. Both of them are wrong.
Earlier quoted context omitted.
Exactly - this is already a solved problem. https://docs.nestjs.com/openapi/introduction
yes, the whole world runs on nestjs
https://github.com/RicoSuter/NSwag
There is no need to be facetious, solutions like these exist for many platforms and ecosystems out there. I can't possibly entertain all of them.
By all means, if such similar solution does not exist for your platform, then TypeSpec could indeed be a solution for you.
With best regards.
Spec api code, imo. Feels like it's going backwards - there's really no reason why it has to be a .tsp, instead of a .ts with actual api code. It's even using @annotations. In fact the annotations i see in the screenshot (@route, @query, @path) are practically the same in NestJS. I feel that we should be focusing on enhancing that paradigm instead. In fact I already have a working POC of NestJS -> OpenAPI -> Client l…
Basically my PoV. The API code itself is the best possible documentation. Not to mention, how else do you see what complex logic might happen in an endpoint? It seems typespec deals only with extremely simple CRUD APIs, for which again just reading the code would be good enough. In scenarios where you want to offer the API consuming team some mock, I'd argue time would be better spent providing them with a a json-ser…
Looking at https://smithy.io/2.0/index.html which can already generate much more than TypeSpec based on the docs and awesome list.
Earlier quoted context omitted.
It’s probably more like smithy?
That’s what I thought when I saw this: smithy without the need to bring Gradle into your project
Earlier quoted context omitted.
Basically my PoV. The API code itself is the best possible documentation. Not to mention, how else do you see what complex logic might happen in an endpoint? It seems typespec deals only with extremely simple CRUD APIs, for which again just reading the code would be good enough. In scenarios where you want to offer the API consuming team some mock, I'd argue time would be better spent providing them with a a json-ser…
If you can define single spec and autogenerate everything (client/server/OpenAPI et. al.), then spec first is superior. Looking at https://smithy.io/2.0/index.html which can already generate much more than TypeSpec based on the docs and awesome list.
Earlier quoted context omitted.
+1. It even looks very similar to TypeScript. Why not use TypeScript as a description of APIs in the first place? Get TypeScript types and even generate OpenAPI schema on the fly to serve it at `/openapi`?
Exactly - this is already a solved problem. https://docs.nestjs.com/openapi/introduction
Would be nice if you could just import those typespec files in typescript (and other languages?) and get automatic typescript types from them. Codegen is annoying and error prone.
+1. It even looks very similar to TypeScript. Why not use TypeScript as a description of APIs in the first place? Get TypeScript types and even generate OpenAPI schema on the fly to serve it at `/openapi`?
A subset of typescript could work, but I imagine it would be fairly confusing to support some features here and other features there.
I think they are going for a minimum common denominator approach and eventually add other targets besides OpenAPI.
Earlier quoted context omitted.
Basically my PoV. The API code itself is the best possible documentation. Not to mention, how else do you see what complex logic might happen in an endpoint? It seems typespec deals only with extremely simple CRUD APIs, for which again just reading the code would be good enough. In scenarios where you want to offer the API consuming team some mock, I'd argue time would be better spent providing them with a a json-ser…
If you can define single spec and autogenerate everything (client/server/OpenAPI et. al.), then spec first is superior. Looking at https://smithy.io/2.0/index.html which can already generate much more than TypeSpec based on the docs and awesome list.
How would you handle a typical case where based on request data an endpoint fetches some additional information from various sources and depending on that performs several different actions?
This is the most common scenario I've encountered outside of extremely trivial CRUD endpoints.
EDIT: don't get me wrong, I'm not being purposefully obtuse - I was a big swagger advocate back in the day, however over time I came to realize that effort was much better invested in writing clear API code and possibly a mock impl like json-server.
Feels like cheating, next to the yaml of openapi anything will look good. And that's all while I'm still considering openapi one of the best things that have happened. But I've also been kind of holding my breath for typescript making it's breakthrough as a schema language. More specifically its surprisingly big non-imperative, non-functional subset, obviously. And at first glance this seems to be exactly this, "what…
Challenge accepted!
https://github.com/bufbuild/protovalidate/blob/main/examples...