4 ms·

It's pretty easy to generate TypeScript bindings on the fly with .NET and OpenAPI and then generate TS client bindings[0]. I don't think simply having the same

It's pretty easy to generate TypeScript bindings on the fly with .NET and OpenAPI and then generate TS client bindings[0]. I don't think simply having the same types is a great reason to use TS on the backend given that many teams end up generating OpenAPI bindings in any case because the front-end models are typically a subset of the backend models (it is probably an anti-pattern to share your Prisma models with your FE). [0] https://github.com/CharlieDigital/dn9-openapi-codegen https://github.com/CharlieDigital/dn9-openapi-codegen

koakuma-chan 2y ago
> because the front-end models are typically a subset of the back-end models That’s true, and Pick<BackendModel, …> works extremely well for me. Setting up GraphQL or OpenAPI or any other code generation is way too arduous compared to just using TypeScript (also allows sharing logic).
- CharlieDigital 2y ago
  > (Setting up OpenAPI)...is way too arduous It's actually quite minimal in .NET 9 :) Just a few lines of config and then pick your preferred Node tool of choice for generating the types from the spec. It's a 1 time setup and you get very clean separation at the boundary. Even with Node frameworks like Nest.js, it is quite simple[0]. Beyond front-end use cases, the OpenAPI spec is pretty much required anyways if you are building a real API since tools like Redocly and other API documentation tools use the OpenAPI spec to generate your docs. Infrastructure like AWS API Gateway also consumes OpenAPI[1]; it seems to me quite handy to use the OpenAPI schema then as the source for client-side DTOs. [0] https://docs.nestjs.com/openapi/introduction https://docs.nestjs.com/openapi/introduction [1] https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html https://docs.aws.amazon.com/apigateway/latest/developerguide...

koakuma-chan 2y ago

> because the front-end models are typically a subset of the back-end models That’s true, and Pick<BackendModel, …> works extremely well for me. Setting up GraphQL or OpenAPI or any other code generation is way too arduous compared to just using TypeScript (also allows sharing logic).

CharlieDigital 2y ago
> (Setting up OpenAPI)...is way too arduous It's actually quite minimal in .NET 9 :) Just a few lines of config and then pick your preferred Node tool of choice for generating the types from the spec. It's a 1 time setup and you get very clean separation at the boundary. Even with Node frameworks like Nest.js, it is quite simple[0]. Beyond front-end use cases, the OpenAPI spec is pretty much required anyways if you are building a real API since tools like Redocly and other API documentation tools use the OpenAPI spec to generate your docs. Infrastructure like AWS API Gateway also consumes OpenAPI[1]; it seems to me quite handy to use the OpenAPI schema then as the source for client-side DTOs. [0] https://docs.nestjs.com/openapi/introduction https://docs.nestjs.com/openapi/introduction [1] https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html https://docs.aws.amazon.com/apigateway/latest/developerguide...