5 ms·

Everyone should use TypeScript on the backend because it allows to share types with the front end extremely easily, and things like Astro actions (or equivalent

Everyone should use TypeScript on the backend because it allows to share types with the front end extremely easily, and things like Astro actions (or equivalent, depends on your framework) give you an easy RPC (no need to deal with GraphQL or whatever).

CharlieDigital 2y ago
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...
deskamess 2y ago
Is it available as a backend language in an ASP .NET Core app? It would be nice if there was a VS project template that was Typescript end-to-end.
- koakuma-chan 2y ago
  Not sure, I meant only using Typescript; no C# at all.
  - neonsunset 2y ago
    Using TypeScript in back-end is a downgrade.
    - koakuma-chan 2y ago
      I would be happy to hear why.

CharlieDigital 2y ago

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...

deskamess 2y ago

Is it available as a backend language in an ASP .NET Core app? It would be nice if there was a VS project template that was Typescript end-to-end.

koakuma-chan 2y ago
Not sure, I meant only using Typescript; no C# at all.
- neonsunset 2y ago
  Using TypeScript in back-end is a downgrade.
  - koakuma-chan 2y ago
    I would be happy to hear why.