But the reality is that at some point, your FE and BE teams will diverge anyways and we use an OpenAPI spec as the contract (Nest.js, not Next.js).
So there was no benefit to using TS on both ends; only pain on the BE.
If a team is going to ship an OpenAPI spec and run it through a transformer, then it changes the selection criteria for a BE language:
- Easy for a TS team to adopt; similar core semantics like `async/await`, exception handling, etc.
- Flexible and pluggable OpenAPI spec generation for edge cases and advanced scenarios
- Excellent ORM to improve productivity around CRUD
- Good tooling
- Extensive docs, platform maturity, but modern language features
C# meets all of those in ways that no other language and platform does.
I can't speak to your use case, but for past projects I've not only wanted to share types but actual logic. For instance, if you want instantaneous validation on the frontend, while applying the same logic on the backend with submitted data. In many instances that would be simple and maybe even serializable, but in my case I was working with architectural data that had extremely detailed logic for what was and was not valid.
Using a TS validation library like Zod gives you both the shared validation code for both the frontend and backend, the TS types, as well as the json schema for openapi. It's a triple whammy too good to ignore. Especially as a small team it is huge leverage enabling you to go further faster.
But the reality is that at some point, your FE and BE teams will diverge anyways and we use an OpenAPI spec as the contract (Nest.js, not Next.js).
So there was no benefit to using TS on both ends; only pain on the BE.
If a team is going to ship an OpenAPI spec and run it through a transformer, then it changes the selection criteria for a BE language:
C# meets all of those in ways that no other language and platform does.