ajv VS typescript-is

Ajv’s documentation is available here.

In the JavaScript ecosystem you can use the excellent AJV package to validate any JavaScript object against a JSON schema. This is especially useful to ensure that API contracts are maintained when communicating with other services.

Since Fastify supports schema validation with Ajv, the validate module is no longer required on the /shorten route, and we can specify the JSON schema directly on the route. The controllers for both routes will largely remain the same, except that the res parameter is renamed to reply as before:

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

Good validator library: https://www.npmjs.com/package/ajv

Fastify uses JSON schema to define the validation rules for each route's input payload, which includes the request body, query string, parameters, and headers. The JSON schema is a standard format for defining the structure and constraints of JSON data, and Fastify uses Ajv, one of the fastest and most efficient JSON schema validators available.

In Fastify, JSON schema validation is a built-in feature that allows you to validate the payload of incoming requests before the handler function is executed. This ensures that incoming data is in the expected format and meets the required criteria for your business logic. Fastify's JSON schema validation is powered by the Ajv library, a fast and efficient JSON schema validator.

I think you're looking for a json schema validator like Ajv or Zod.

We can use JSON Schema to validate that our data adheres to a specific structure. Ajv is one popular validator tool for JavaScript applications that allows us to create a schema and then validate JSON against that schema. Here's an example of using Ajv to validate one of the above JSON examples against a schema:

Hey HN,

We're designing a new system and have been kicking the can about JSON object definitions and validation. Soon we need to settle on a system to validate API request bodies and provide helpful error messages.

In the past, I've used JSON Schema ( https://json-schema.org/ ) to define definitions and ajv ( https://ajv.js.org/ ) to validate, but it's a bit verbose and ajv validation errors are more cryptic than I'd like to deal with.

TypeSchema looks interesting. It seems solid (and perhaps stable?), but development hasn't been active for 2 years. It also looks like we'd still need to generate JSON Schema and choose a validation library

Anyway, I'm very curious how others are approaching this problem. How do you organize and generate validations for your type definitions? What libraries do you use to validate and provide human readable error messages?

Thank you!

I'll throw https://github.com/woutervh-/typescript-is in the mix as well.

I'm a fan of typescript-is. Provides both compile time and run time validations

For what it's worth, thanks to TypeScript transformers (a feature baked into the compiler), one can create a transformer library that verifies an object is valid for any TypeScript type and conveys that information to the typechecker. And indeed, it's already been made. It allows to parse unknown into a given T. This is nice, because one can generate a JSON schema out of a TS type, for other languages/codebases to integrate safely.

But to make it worth the comment, I’ll point people to typescript-is which uses transformations at compile-time to generate run-time type checking code.

Then there's also typescript-is, which is pretty neat because it converts actual compile-time type definitions to runtime type checks, so it doesn't require changing the type definitions.

typescript-is. This uses a compile-time transformer to generate code for type-checking. You'll need to use ttypescript instead of typescript to compile your code (I recommend setting this up with ts-patch). It won't work if your build pipeline is actually using something like esbuild or Babel to transpile TS->JS.

If you're not using a bunch of generics, check out typescript-is [1]. It takes little work to get it setup, but it generates run time type checks for you. I understand why typescript decided to not add this functionality to the core of the language, but it's starting to feel like the largest missing piece of typescript is a built-in way to generate run-time type-checks for user-defined types from just the type definition.

The happy medium we've found with that module is using the runtime type-check on anything "unsafe" to bless the result using typescript-is's equals functionality, but still allowing programmers to use casting with a comment justifying its necessity. For us our list of unsafe is results pulled from the db, anything parsed from JSON, and incoming request bodies (which can be a special case of parsing from JSON, but not always).

[1]: https://github.com/woutervh-/typescript-is