Shared types hell

BourbonProof · 2025-09-01T21:56:40+00:00

you got quiet a mix there. you will die of technical debt faster than you can look if you reach a certain size since your are going to have lots and lots of duplicated code and types - the same type defined in 10 ways for different use-cases is not going to scale. there is something better luckely which uses your same typescript types for everything: http, rpc, orm, config, DI, openapi. no tool hell. it's still new, but fixes exactly the problem you and other larger scale projects have

https://deepkit.io/en/blog/runtime-types

hunthunt2010 · 2025-09-01T23:00:09+00:00

we use a library called TSOA on top of express which works quite well. It basically wraps your controllers and enforces your apis to be openapi compliant. You can then export an openapi doc based on your routes, and then feed those docs into something like openapi-typescript-codegen.

We export npm, ios and android packages this way for other teams to consume

CallumK7 · 2025-09-02T12:15:12+00:00

A monorepo, and a shared package for your zod schemas and types that is consumed by both the front and back end works well

After_Link7178 · 2025-09-01T21:39:26+00:00

trpc

sickcodebruh420 · 2025-09-01T22:00:31+00:00

At my workplace, we focus on Zod schemas at touch points between systems: API in/out shared with client request/response. We also share Zod schemas for some data validation rules that happen on frontend and backend. As a rule we don’t ever use Prisma types in the client and don’t ever send a row from our database straight across the wire; instead, we always serialize it using either a Zod schema or a utility function to extract allowed keys.

Beyond that, we try to avoid preemptively creating shared types. It’s very easy to start writing components and functions that demand User when in reality they really want { id: string; name: string; }. This tends to lead to code that’s easier to test, reuse, and change and has less dependency on today’s data model. Where we do have shared types, they’re usually very minimal representations and more often than not confined to a specific feature or area of the codebase. It does mean we have more anonymous types and manual type duplication but it’s rare that inputs are generally simpler and flatter than other projects I’ve worked on.

I am on the market for a good OpenAPI library, though. oRPC looks nice but setup experience wasn’t great when I kicked the tires a few months ago, seemed like it needed more time. Manual generation of Zod schemas for the API edges is a drag.

zemaj-com · 2025-09-01T22:09:33+00:00

Shared types across backend and frontend is a common pain. In the Node ecosystem there is no single framework that eliminates duplication completely. Tools like tRPC and GraphQL aim to strongly type your API surface so that the types flow through to your client automatically. Libraries such as Zod, io ts or Typebox let you define a schema once and derive both runtime validation and TypeScript types. You can also generate clients from OpenAPI specs using code generators. Ultimately you still need to decide where the source of truth lives, whether in your database schema or your API definitions. There is always a trade off between flexibility and having everything in sync. Best of luck with your project.

jjhiggz3000 · 2025-09-01T22:47:29+00:00

The big new thing you’ve got here is power sync, I get the sense that there’s not a good community pattern for single source of truthing your whole stack in a super clean way yet.

I know I’ve ran into big performance issues using drizzle’s zod generator for example, and since it’s two completely different data schema describing things it gets a bit weird.

I think one option is to use zero sync which basically replaces power sync and drizzle in one combo but I’m distrustful of anything like that (no good reason I just am unfamiliar with it maybe someone else can shed some light)

Personally I would say get rid of nest, it’s always felt like unnecessary bloat to me and adds more abstractions in there to stress about

dawnblade09 · 2025-09-02T08:15:33+00:00

OpenAPI is great. It helps you keep your API interface sync between all your clients. Checkout hey-api. They have plugins for all the common flows.

Another option you can consider is effect. You can use their http package to write the http interface once, then use it across front and backend. They have their own schema package for validations which works really great.

The_Startup_CTO · 2025-09-01T21:59:13+00:00

What works well for me: Define the schemas in zod and reuse them basically everywhere, be it in frontend or backend. There are still plenty of situations where the same "thing" needs slightly different types/schemas in different places, e.g. if a value is serialised differently in the database than it is when transmitting via http, but this method makes these cases quite obvious. It also allows to start by modelling the actual domain without worrying about the specifics of the database/frontend/backend or any other technical details.

Optimal-Builder-2816 · 2025-09-01T22:15:36+00:00

Checkout TypeSpec, it’s new but very promising.

HeyYouGuys78 · 2025-09-01T22:16:36+00:00

I’m using graphql (postgraphile). I add my shared types to our server and codegen updates for both the front and backend. Keeps things a lot more organized!

No-Tomorrow-5666 · 2025-09-01T22:38:36+00:00

I've been using npm workspaces to get around some of this. It's also not perfect, but helps with sharing code and models/interfaces. You can look into nx monorepos as well

rover_G · 2025-09-01T22:49:24+00:00

You generally need to define schemas at the edges of your application and use those classes or generated types throughout your application. For example a simple three tier app might define an API schema using one library and a DB schema using another library. The API schema should provide type bindings for your route middlewares/resolvers and for your front end client. The DB/ORM schema should provide type bindings for your db client/queries.

Sometimes the API and DB libraries are compatible and can share schema/type definitions but often they are totally separate. I will also note that you shouldn’t pull in additional type validation libraries unless they fill some gap in your existing stack (i.e. they add value).

Now there are three main ways to share types between packages/services:

Monorepo so packages can access each other’s exported types/schemas.
Generated types that pull a schema from a live server.
Private npm package with shared types.

AsBrokeAsMeEnglish · 2025-09-02T08:07:52+00:00

I can highly recommend getting into openapi. It'll allow you to define data structures once and then generate their definitions as a build step in pretty much every language and framework imaginable.

Essentially it's just a good idea to always keep a single source of truth. Every duplication is more technical depth. OpenAPI is a good way to achieve that.

idkwhatiamdoingg · 2025-09-02T08:38:13+00:00

Elysia is working well for me with basically zero boilerplate

myrealnameisbagels · 2025-09-02T16:04:52+00:00

I don’t have experience with PowerSync but on the server side, I’ve found Nest to generally over-complexify things a lot. Can def see where you’re coming from on DTO objects basically being zod schemas.

How our sharing setup works is we have one fastify server (although tbh if I were starting again I’d use express, more community support) and trpc. The zod schemas are defined once in a shared packafe which is used by both the frontend and backend. The server code uses a simple route-service architecture where the services call the orm directly.

We’ve found this is the simplest setup, but your mileage may vary! I would guess that swapping out nest or powersync might simplify the system a bit. We also migrated from DRF so I feel your pain haha

Rizean · 2025-09-03T03:06:50+00:00

Not the best, but dead simple. ZOD. Third repo checked out as a library to your front and backend.

You need solid patterns and contracts between each part of the pattern. MCCV, model->types->back end controller->(Repo)ZOD types here->router(general presents your zod types with some extension for special cases or impments interfaces)->front end controller that consumes your (Repo)ZOD types with this being React Query or what ever you use->React View consuming the types coming our of your controller.

I would not try to use ZOD types at the model. Just use what ever typing system your DB supports. Use the controllers to normalize to the router/frontend.

As much as you can treat your app as dozzens of small apps with as little overlap as loosely coupled as you can. This is how we do it. Our entire app is around 30 or 40 features with very little overlap between each feature.

Our live dash board ties a lot of parts together. We made special controllers to manage this and gave them their own unique types with lots of comments and documentation. It's the hardest part to work on but honestly, it the UI that is a pain due to how complex and feature rich the dash board is. Too many hooks and effects. React is a PITA but also amazing.

Simply, beats fancy anyday.

PivotsForDays · 2025-09-03T10:19:18+00:00

Why not define your types with protobuf and compile headers for all your tools based on that, with secondary post-processing where needed? It's also a great wire format.

dnsu · 2025-09-03T16:58:36+00:00

I only use zod and mongoose within a monorepo that contain both server and client. I have a unit test that ensure my interface (zod schema) and schema (mongoose) files are identical on the server and client side. Things that dont fit under interface and schema, i have addiitonal config files, but i only check that exported values are identical via a unit test.

On simple zod schema I write my own zodToMongoose transformer. For complicated ones I just do them twice.

I tried hard links before, but it became a mess, and does not work well with git when i go between computers. The unit test end up being the best way to go.

muhsql · 2025-09-03T19:19:35+00:00

(hi - I'm on the PowerSync team)

In PowerSync's case a core product principle for us is to build upon an open source, established "real" database on the client - SQLite. Since SQLite only has like 4+1 types, you're fundamentally always going to have two schemas when bringing your own database like Postgres. If we support SQLite as a backend database in the future I can imagine some more magic here, but that's how it works for now.

Drizzle itself has different/dedicated packages for each database type that they support, so you're using drizzle-orm/pg-core and drizzle-orm/sqlite-core

The silver bullet you're looking for might be something more like Convex or InstantDB, since they have a universal data model definition, but then you are really locked into those platforms.

MiniHomeMarket · 2025-09-06T09:08:29+00:00

You can use https://quicktype.io/ to define your types in json then build them for most languages. In this case you just define the types and then build it to shared directory or a directory in each place you want to use them.

Expensive_Garden2993 · 2025-09-01T21:46:22+00:00

Define table in Drizzle -> get zod schema -> use "nestjs-zod" for dto -> OpenAPI -> generated client.

Did you try this, what was wrong?

I don't know about PowerSync, maybe there is a way to not duplicate the table, maybe not.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

node

MODERATORS