zod VS typebox

While Speakeasy also includes unit tests, they're organized at the root of the /tests directory with less granular separation. Its approach emphasizes documentation and type definitions, with extensive model documentation in /docs/models/. The SDK uses runtime validation through zod, which requires developers to carefully handle error objects when the API returns invalid data. This creates a different balance between compile-time and runtime type safety.

I used zod-bird to integrate Tinybird APIs (pipes and events) with Next.js. It's a wrapper around the Tinybird APIs that validates pipe results using zod schemas.

One of the most basic applications of ReScript Schema is parsing - Accepting unknown JavaScript data, validating it, and returning the result of your desired type. There are dozens of such libraries, and the most popular ones are Zod, Valibot, Runtypes, Arktype, Typia, Superstruct, Effect Schema, and more. Also, even though this is slightly different, validation libraries like Ajv, Yup, and others also stand really close.

…but that’s a lot of no fun, dangerous work. Better to use a library that has already solved this problem like Zod or ArkType. It’ll ensure the types match up, and if not, give you an error response that _somewhat_ gives you a clue as to why the decoding went wrong, way more thorough and verbose than JSON.parse’s not so great runtime error messages.

As you can see, encoding and decoding in TypeScript can make your code safer, reduce the amount of type narrowing you need to do, especially if you use Zod. For consumers of your code and api’s, it gives them the flexibility of utilizing your API’s while providing their own types which includes their own encoders and decoders in a type-safe way. TypeScript can safely ensure all erros are typesafe, and those error scenarios are handled in developers who use your code.

🔗 https://zod.dev/

Zod is a TypeScript-first library for schema declaration and validation, offering a simple API to define, parse, and validate data structures with runtime type safety. It supports detailed error handling, and is ideal for validating inputs, APIs, and complex data in modern applications.

This feature is a game-changer because it guarantees that the AI's response will match your specified format. No more hoping the AI will format things correctly or writing complex parsing logic—you define a schema, and OpenAI ensures the output matches it exactly. This not only simplifies downstream processing but also allows you to use libraries like Zod to validate and enforce the schema of your output.

Zod

The original library only supports Zod. While Zod is excellent, many developers use alternatives like Valibot, ArkType, and TypeBox. hono-openapi is validator-agnostic, offering first-class support for multiple libraries.

If you were willing to bring additional zod tooling or move to something like TypeBox (https://github.com/sinclairzx81/typebox), the json schema would be a direct derivation of the tools' input schemas in code.

I'd recommend TypeBox[1] as an alternative, which has a runtime “compiler” for generating optimized JS functions from the type objects. It also produces a JSON schema, which can be useful for generating API docs and API clients if needed.

It also has a companion library[2] for generating TypeBox validators from TypeScript definitions, which I'm currently using in an RPC library I'm working on.

[1]: https://github.com/sinclairzx81/typebox

Big fan of your work and impressed by your productivity. Currently reading https://www.oreilly.com/library/view/unifying-business-data/....

Currently experimenting with programmatic generation of json schemas via https://github.com/sinclairzx81/typebox. Trying to maximize reuse of schema components.

Was wondering if JSON BinPack is a good serialization format to sign json documents? Can it be used to somehow canonicalize json?

The documentation can be found here.

So far I like the commonly used approach in the Typescript community best:

1. Create your Schema using https://zod.dev or https://github.com/sinclairzx81/typebox

2. Generate your Types from the schema. It's very simple to create partial or composite types, e.g. UpdateModel, InsertModels, Arrays of them, etc.

3. Most modern Frameworks have first class support for validation, like is a great example Fastify (with typebox). Just reuse your schema definition.

That is very easy, obvious and effective.

There's a ton of schema validators out there and most devs have their personal favorite. Mine was zod and is now typebox + ajv.

If you're willing to document your API with an OpenAPI schema, then it should be possible to generate TypeScript types based on the OpenAPI schema with something like openapi-typescript. Also, Typebox can generate JSON schemas, maybe it can be used to generate something that the front-end can also use?