Hacker News Reader

Comment by causal | Hacker News Reader

Zod is a lot better than some of the alternative solutions I've seen. That said, the need for this sort of explicit validation always felt like a failure of where modern web development has taken us. It's so frustrating how full-stack development requires so many ways of describing the same shapes: JS input validation, Swagger for API definition, server-side input validation, ORM for schema conformance, and TypeScript often requiring separate definitions on server and client side. It's so tedious.

View on HN

TypeScript's insistence on being a static checking/compile time only system is such a sad wound to the whole ecosystem. I don't want TypeScript to be a runtime checker, but I want it to export useful usable type data for classes, functions, objects. TypeScript feels like the best source of truth we have, but instead so many of the attempts to reflect on what we have are all going it alone, having to define their own model and their own builders for describing what stuff is. You've mentioned 5 major areas where reflection is a core part of the mission, and each of these have multiple implementations.

There is the old TypeScript type emitter, reflect-metadata, which would provide some type information at runtime, but it targets very old decorator and metadata specifications, not the current version. I don't super know how accurate or complete it's model really is, how closely it writes down what typescript knows versus how much it defines its own model to export to. https://www.npmjs.com/package/reflect-metadata

We are maybe at the cusp of some unifying, some coming together, albeit not via typescript at this time, still as a separate layer. The Standard Schema project has support from I dare say most of the top validation libraries. But extending this to API definitions, ORM tools is in extremely early stages. https://github.com/standard-schema/standard-schema?tab=readm...

Yes. Although I am more familiar with TypeScript and prefer it for a few reasons, I've been inspired seeing how Pydantic has been used in the field for both design-time and runtime validation.

Hard agree - TSC already has this information, why should so many libraries in the world duplicate it ? A single source of truth works better than everyone repeating the same in different, finicky runtime validation libraries.

> I don't want TypeScript to be a runtime checker

I do.

If the types are internally consistent, then they don't need runtime validation, it'd just be extra code to download and run.

If you accept external data, you may already opt in using something like Zod. I don't see why conflate the two things just because their quacks echo the same.

But that’s the whole point of something like this. You do it once and dynamically generate everything else downstream. So change it once in the zod schema and it propagates with type checking through your entire app.

The zod schema becomes the source of truth.

Does zod really support that? What if the code base start out with a go backend and a TS/JS component is only added later? It would be nice if the source of truth was a bit more language agnostic.

Better to use something like OpenApi and generate your zod schema using it.

And thus is born the 15th IDL for cross language API calls...

Does it? I don't use Zod on my JVM backend. How would I?

In addition to using OpenAPI, I generate TS interfaces from my data classes in a Gradle task.

One way might be to convert the Zod schema to a JSON schema and then to Java? I found a library to do that. [1] But I don’t know how lossy that would be. A purpose-built converter might do better.

[1] https://jsontypedef.com/docs/java-codegen/

Looks like there are libraries for generating zod schemas from OpenAPI definitions and others.

https://zod.dev/ecosystem?id=x-to-zod

Does it?

Most Go, Java, and Python APIs are practically all Swagger based.

You shouldn’t typically need to redefine your data all over the places. There are zillions of converters for everything to zod, and zod to everything.

If you already have JSON schema/swagger schemas, generate zod from em. If you use a typescript orm, I bet you $10 there’s a zod generator for it.

Honestly zod has gotten so popular that for me, it’s the unifying schema definition that everything else in the stack can rely on. And since directly defines the types, devs actually keep it up to date (swagger docs at my company are ALWAYS lagging behind changes)

All APIs are experimental and in a state of constant flux and evolution, including the web.

The only time status quo is fine is when it's for clients and employers who just want stuff done and don't care how.

In that context, all these unfortunate layers of complexity at least mean more billable hours.

> All APIs are experimental and in a state of constant flux and evolution, including the web.

for better or worse the web only adds, don't change or remove APIs

> It's so frustrating how full-stack development requires so many ways of describing the same shapes: JS input validation, Swagger for API definition, server-side input validation, ORM for schema conformance, and TypeScript often requiring separate definitions on server and client side. It's so tedious.

Many of the same people who complain about how complicated modern web dev is would also shudder at the suggestion to just replace all those things with TypeScript (and Zod, if that's your TS schema definition and validation library of choice).

We use drizzle + Hono + client with zod. So the entire chain from ui to client to server to DB follow same validation and shape.

I've heard of this stack, glad to hear it works, still hate that you need three separate external dependencies to do it

How do you use the same validation for drizzle and zod? I have been writing duplicate schemas and hoping they match...

Drizzle has a zod addon, to generate zod schema from table defn. So table defn is source of truth, we mix generated zod schemas to get hono request validators. Same zod schema are also used on client to validate forms.

How else would you do it? You could use something like trpc for full end to end type safety but that requires using TypeScript on both the frontend and backend (which not everyone does) and also locking yourself into only the web platform (so no mobile, etc).

Yes there should at least be a way to consolidate so that we can agree on format to treat as the source of truth that we can generate the other formats from.

OpenAPI TypeScript is the closest thing I’ve found to perfection when your API is written in a different language than your client.

https://openapi-ts.dev/

GraphQL is another one, with schema introspection and codegen for queries and types.

Reply on news.ycombinator.com