Hacker News Reader

Comment by supermdguy | Hacker News Reader

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.

View on HN

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

So in short you don't share types. Manually writing them for both is easy, but also tedious and error prone.

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.

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.

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.

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.

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

Typescript, using Zod with Express for parameter validation.

Why do you even have to ask, then? TS on both sides is the easiest case.

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

FastAPI -> OpenAPI -> openapi-typescript

protobuf?

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.

Reply on news.ycombinator.com