3 ms·

How do you guys share types between your frontend and backend? I've looked into tRPC, but don't like having to use their RPC system.

david422 9mo ago
I do it naively. Maintain the backend and frontend separately. Roll out each change in a backwards compatible manner.
- Etheryte 9mo ago
  So in short you don't share types. Manually writing them for both is easy, but also tedious and error prone.
  - Arainach 9mo ago
    Each layer of your stack should have different types. Never expose your storage/backend type. Whenever you do, any consumers (your UI, consumers of your API, whatever) will take dependencies on it in ways you will not expect or predict. It makes changes somewhere between miserable and impossible depending on the exact change you want to make. A UI-specific type means you can refactor the backend, make whatever changes you want, and have it invisible to the UI. When the UI eventually needs to know, you can expose that in a safe way and then update the UI to process it.
    - Etheryte 9mo ago
      This completely misses the point of what sharing types is about. The idea behind sharing types is not exposing your internal backend classes to the frontend. Sharing types is about sharing DTO definitions between the backend and the frontend. In other words, sharing the return types of your public API to ensure when you change a public API, you instantly see all affected frontend code that needs to be changed as well. No one is advocating for sharing internal representations.
    - hu3 9mo ago
      Usually you only share API functions signature and response types. It's tempting to return a db table type but you don't have to.
- jim201 9mo ago
  I used to dread this approach (it’s part of why I like Typescript monorepos now), but LLMs are fantastic at translating most basic types/shapes between languages. Much less tedious to do this than several years ago. Of course, it’s still a pretty rough and dirty way to do it. But it works for small/demo projects.
denysvitali 9mo ago
protobuf?
- piva00 9mo ago
  Protobuf is decent enough, I've used Avro and Thrift before (way way before protobuf came to be), and the dev experience of protobuf has been the best so far. It's definitely not amazing, code generation in general will always have its quirks, but protobuf has some decent guardrails to keep the protocol backwards-forwards compatible (which was painful with Avro without tooling for enforcement), it can be used with JSON as a transport for marshaling if needed/wanted, and is mature enough to have a decent ecosystem of libraries around. Not that I absolutely love it but it gets the job done.
esafak 9mo ago
I have a library translate the backend types into Typescript. What language do you use on the back?
- supermdguy 9mo ago
  Typescript, using Zod with Express for parameter validation.
  - esafak 9mo ago
    Why do you even have to ask, then? TS on both sides is the easiest case.
shepherdjerred 9mo ago
Typespec is up and coming. Otherwise there are plenty of options like OpenAPI
programmarchy 9mo ago
FastAPI -> OpenAPI -> openapi-typescript

david422 9mo ago

I do it naively. Maintain the backend and frontend separately. Roll out each change in a backwards compatible manner.

Etheryte 9mo ago
So in short you don't share types. Manually writing them for both is easy, but also tedious and error prone.
- Arainach 9mo ago
  Each layer of your stack should have different types. Never expose your storage/backend type. Whenever you do, any consumers (your UI, consumers of your API, whatever) will take dependencies on it in ways you will not expect or predict. It makes changes somewhere between miserable and impossible depending on the exact change you want to make. A UI-specific type means you can refactor the backend, make whatever changes you want, and have it invisible to the UI. When the UI eventually needs to know, you can expose that in a safe way and then update the UI to process it.
  - Etheryte 9mo ago
    This completely misses the point of what sharing types is about. The idea behind sharing types is not exposing your internal backend classes to the frontend. Sharing types is about sharing DTO definitions between the backend and the frontend. In other words, sharing the return types of your public API to ensure when you change a public API, you instantly see all affected frontend code that needs to be changed as well. No one is advocating for sharing internal representations.
  - hu3 9mo ago
    Usually you only share API functions signature and response types. It's tempting to return a db table type but you don't have to.
jim201 9mo ago
I used to dread this approach (it’s part of why I like Typescript monorepos now), but LLMs are fantastic at translating most basic types/shapes between languages. Much less tedious to do this than several years ago. Of course, it’s still a pretty rough and dirty way to do it. But it works for small/demo projects.

denysvitali 9mo ago

protobuf?

piva00 9mo ago
Protobuf is decent enough, I've used Avro and Thrift before (way way before protobuf came to be), and the dev experience of protobuf has been the best so far. It's definitely not amazing, code generation in general will always have its quirks, but protobuf has some decent guardrails to keep the protocol backwards-forwards compatible (which was painful with Avro without tooling for enforcement), it can be used with JSON as a transport for marshaling if needed/wanted, and is mature enough to have a decent ecosystem of libraries around. Not that I absolutely love it but it gets the job done.

esafak 9mo ago

I have a library translate the backend types into Typescript. What language do you use on the back?

supermdguy 9mo ago
Typescript, using Zod with Express for parameter validation.
- esafak 9mo ago
  Why do you even have to ask, then? TS on both sides is the easiest case.

shepherdjerred 9mo ago

Typespec is up and coming. Otherwise there are plenty of options like OpenAPI

programmarchy 9mo ago

FastAPI -> OpenAPI -> openapi-typescript