5 ms·

they seem to mean on the backend

CharlieDigital 1y ago
Motion eng here: yes, this is a pure backend change; FE remains powered by React and TS with no plans to change it any time soon. Main pain points with TS have become more obvious as the team grew and the codebase resulted in a multitude of different models representing the same thing. - Prisma model representing the things (plural because Prisma generates a ton of variants for the different read/write scenarios) going in/out of the DB - Zod models for OpenAPI generation - Zod models for deserialization where we have `jsonb` - DTO models at the boundary - Additional front-end payload models that wrap the DTOs A developer building a simple API endpoint do to a read will often up writing a handful of models for the same entity to move it back and forth...A lot of this work simply ends up being related to the loss of runtime types requiring a lot more modeling work creating a spaghetti of Zod and types. Lots of papercuts in day-to-day and increasingly difficult to get otherwise competent engineers onboarded. At least I'm not under the impression that this is a Silver Bullet. Will C# make it better? We'll see!
- Merad 1y ago
  For basic CRUD like is emphasized in TFA you probably only need EF models to represent the db and DTOs to form the input/output contracts of the API. Many .Net shops (claim to) do DDD and will have an extra layer of domain models, but if you understand that your API is primarily CRUD they're just unnecessary complexity. While you won't be able to share your back end models with the front end, OpenApi spec generation is pretty much automatic so you can generate the models or client code.
  - CharlieDigital 1y ago
    Yes; I think that's one thing that made this transition more sensible: we are not really sharing much of the BE with the FE and most of it is at the boundary already anyways.
- junto 1y ago
  I don’t know if you’re using this already but there are quite a few tools to autogenerate the typescript api clients from your backend code every time you build. Makes life super easy. You can also just do it in your CI/CD.
- sajadjalilian 1y ago
  After thinking for a year about my frontend choose; I decided to go with Razor-Pages + HTMX for all my new projects from now on.
  - kant2002 1y ago
    What do you use for HTMX in Razor? any library or some manual plumpbinng? How do you disable layout?

Motion eng here: yes, this is a pure backend change; FE remains powered by React and TS with no plans to change it any time soon. Main pain points with TS have become more obvious as the team grew and the codebase resulted in a multitude of different models representing the same thing. - Prisma model representing the things (plural because Prisma generates a ton of variants for the different read/write scenarios) going in/out of the DB - Zod models for OpenAPI generation - Zod models for deserialization where we have `jsonb` - DTO models at the boundary - Additional front-end payload models that wrap the DTOs A developer building a simple API endpoint do to a read will often up writing a handful of models for the same entity to move it back and forth...A lot of this work simply ends up being related to the loss of runtime types requiring a lot more modeling work creating a spaghetti of Zod and types. Lots of papercuts in day-to-day and increasingly difficult to get otherwise competent engineers onboarded. At least I'm not under the impression that this is a Silver Bullet. Will C# make it better? We'll see!

Merad 1y ago
For basic CRUD like is emphasized in TFA you probably only need EF models to represent the db and DTOs to form the input/output contracts of the API. Many .Net shops (claim to) do DDD and will have an extra layer of domain models, but if you understand that your API is primarily CRUD they're just unnecessary complexity. While you won't be able to share your back end models with the front end, OpenApi spec generation is pretty much automatic so you can generate the models or client code.
- CharlieDigital 1y ago
  Yes; I think that's one thing that made this transition more sensible: we are not really sharing much of the BE with the FE and most of it is at the boundary already anyways.
junto 1y ago
I don’t know if you’re using this already but there are quite a few tools to autogenerate the typescript api clients from your backend code every time you build. Makes life super easy. You can also just do it in your CI/CD.
sajadjalilian 1y ago
After thinking for a year about my frontend choose; I decided to go with Razor-Pages + HTMX for all my new projects from now on.
- kant2002 1y ago
  What do you use for HTMX in Razor? any library or some manual plumpbinng? How do you disable layout?