Hacker News Reader

Comment by david422 | Hacker News Reader

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

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.

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.

Reply on news.ycombinator.com