io-ts VS zod

Use libraries like io-ts for runtime validation:

Qué rico. Si tenés chance meté un proceso de code review fuerte, y para el tema de I/O probá a usar https://github.com/Effect-TS/schema ó https://github.com/gcanti/io-ts que les da una solución obvia al tema de "tipos para lo que devuelva el backend", aunque es en realidad mucho más capaz que eso.

My fave is still io-ts (https://github.com/gcanti/io-ts/blob/master/docs/index.md) as I find it more flexible than zod at the ingress. The author is also working on the Effect ecosystem which also looks interesting.

I’ve been using io-ts for this and been very happy with it. [1] It’s similar to Swift’s Coding protocol in case you’re familiar.

[1] https://gcanti.github.io/io-ts/

Yeah, there are a few new concepts and it's not the easiest to pick up right away. The best introduction is here on the main documentation page.

We use https://github.com/gcanti/io-ts/blob/master/Decoder.md which has a very similar interface. It can even be used to mutate the data using https://github.com/gcanti/io-ts/blob/master/Decoder.md#the-parse-combinator.

A good way to significantly improve the reliability of your app is via improving type-safety by moving away from using any to unknown. One relevant example could be when you type your backend responses and when stringifying JSON to using unknown combined with some sort of runtime type checking. It can be done either by using built-in functionality like type guards or using an external library like io-ts, zod or yup.

Usage of TypeBox is similar with io-ts and zod, but it is much powerful and faster than them. Also, TypeBox can generate JSON schema very easily. Therefore, if you're looking for a validator library for new project and not suffering from legacy codes, I think TypeBox would be much better choice than io-ts and zod. TypeBox can totally replace them.

Author here. I wrote a fairly detailed writeup here[0] for those who are interested in the reasons for this approach.

Ultimately you're right that npm doesn't work well to manage the situation Zod finds itself in. But Zod is subject to a bunch of constraints that virtually no other libraries are subject to. There are dozens or hundreds of libraries that directly import interfaces/classes from "zod" and use them in their own public-facing API.

Since these libraries are directly coupled to Zod, they would need to publish a new major version whenever Zod does. That's ultimately reasonable in isolation, but in Zod's case it would trigger a "version avalanche" would just be painful for everyone involved. Selfishly, I suspect it would result in a huge swath of the ecosystem pinning on v3 forever.

The approach I ended up using is analogous to what Golang does. In essence a given package never publishes new breaking versions: they just add a new subpath when a new breaking release is made. In the TypeScript ecosystem, this means libraries can configure a single peer dependency on zod@^3.25.0 and support both versions simultaneously by importing what they need from "zod/v3" and "zod/v4". It provides a nice opt-in incremental upgrade path for end-users of Zod too.

[0] https://github.com/colinhacks/zod/issues/4371

There are libraries that let you define refinement types[0] but it does require a bit of runtime overhead, and the added complexity depends on the library.

[0] https://zod.dev/?id=refine as an example

Zod Documentation

Use libraries like Joi or Zod to validate the chaos

Zod - https://zod.dev/

@apexjs-org/openapi is an OpenAPI 3.1+ description library for TypeScript. You can use this package to easily create a type-safe OpenAPI (Swagger) description with Zod schema support in Node.js. In this tutorial, we use express-openapi-validator to bring the OpenAPI description to life with automatic validation and request handling.

note: In the boilerplate we used zod but you can use any other similare libraries for this part.

I'm a big fan of Zod and find it the best choice regarding the ecosystem and developer experience it provides. Although, despite its large size, it's tailored more toward the frontend world. If you're developing a backend or an application with high throughput, you should definitely give Sury a try.

In this project, we take a code-first approach when working with Firestore. Instead of relying on Firestore rules or ad-hoc validation, we define the shape and structure of a valid message directly in our application code using Zod.

The next thing to do is write our first Genkit flow to ingest data from a URL into the collection. Flows are functions that you can run via the Genkit UI or through code. Flows have strongly defined input and output schemas using zod.