How does TypeCompiler validation compare to ajv validation?

[FabianFrank]

How does the TypeCompiler introduced in 0.30.0 compare to ajv based validation? Does it support all the same features? How does it perform compared to ajv, are any benchmarks available? I'm assuming most TypeBox users use ajv for runtime validation today and might be wondering, like me, if the switch is worth it.

[sinclairzx81]

@FabianFrank Hi!

The TypeCompiler has actually been around for a while (just over a year) and works quite well. I personally use it over Ajv these days, and there's a few ecosystem frameworks integrating it into their infrastructure. It's biggest draw is the JIT performance (as benchmarked here and here) (currently the fastest available for JavaScript afaik)

The decision to move from Ajv to TypeCompiler really just depends on how "all-in" you want to go with TypeBox. Be mindful that the compiler isn't a typical JSON Schema validator as much as it is a TypeBox type validator. While it operates on the same schematics Ajv does, internally it uses TypeBox's symbols and exact schema representations to optimize compilation and assertion. It also supports non JSON serializable data validation (things like bigint, undefined, Uint8Array, etc) which are beyond the formal JSON Schema specification.

Some high level things to consider if you're thinking of moving to it.

Specification Support

In terms of specification alignment, the compiler supports validation features of JSON Schema draft 7 and some of Draft 2019-09. It's currently missing support for less used keywords like if/then/else, dependentRequired, $dynamicAnchor, $dynamicRef and a few others. However, the if/then/else schematics are planned before the end of the year, and dependentRequired may follow soon after. In general, anything you can see expressed as a TB SchemaOption should be supported.

String Formats

The TypeCompiler doesn't include any built in string formats (things like email, uuid, etc). Typically these would be added in via addFormats using the ajv-formats package. TypeBox preferences explicit configuration for these (and provides some examples here which can be configured fairly easily).

Integration

TypeBox's compiler infrastructure (as well as much of the Value infrastructure) is written mostly to be a validation backend for framework integration (with specifically https://github.com/sinclairzx81/sidewinder in mind). Generally, you're going to get the most mileage if you've control of the framework you're integrating on. For ecosystem frameworks that already standardize on Ajv however, it's generally better to use that than try bolt on the compiler (although sometimes it can be worth it just for faster application compilation and start up)

Hope that brings a bit of insight!
Cheers
S

[rolanday]

Hi @sinclairzx81 , qq regarding above:

TypeBox preferences explicit configuration for these (and provides some examples here which can be configured fairly easily).

Can you please share recommended usage pattern? I'm wanting check string format w/ little or no add'l configuration. Docs provide following example:

// String must be an email
const T = Type.String({                              // const T = {
  format: 'email'                                    //   type: 'string',
})                                                   //   format: 'email'
                                                     // }

This (email format string validation) does not work out of box. However, I can use the following instead:

const T = Type.String({
  // format: "email",
  pattern:
    "^[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?$",
});

Is there a better approach? I'm new to TB and t's not clear to me how to fold the example functions shared above into TB validation path, or if these are just for reference (for getting regex patterns).

Thanks for creating/sharing this package btw! I discovered because recently switched to fastify, and the integration for validating schema is bliss.