Our great sponsors
-
go-helpers
A small collection of various helpers we use in our Go projects (forms, settings, structure conversions, ...)
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
ajv
The fastest JSON schema Validator. Supports JSON Schema draft-04/06/07/2019-09/2020-12 and JSON Type Definition (RFC8927)
I'd like to offer a contrasting opinion to all of the other currently negative comments: I've used JSON schema in the past to validate outside input and it was a pleasant and straightforward experience.
There are unfortunately no standard type declarations that I'm aware of, which is a pain, but tools exist to translate schema.org schemas[1] (I have not used this myself).
[1]: https://github.com/charlestati/schema-org-json-schemas
```
The "IsInteger" validator can of course be interpreted as a type, the important thing is though that it can be customized using type parameters and that we can add any number of additional validators that do advanced things (e.g. we could define an "IsPrime" validator that checks for primality of the number).
I find this more elegant than having both a "type" field and various extensions for validations that you need to remember. The validator list mechanism also makes it easy to chain validations and perform sub-validations for lists or maps. I have an open-source implementation of this written in Golang [1] that I use in all my projects. It enables me to write a form specification and a Go struct and validate as well as coerce unstructured data into the struct. It makes it very easy to validate complex, hierarchical documents like configuration files as well, is easy to extend and provides nice errors.
1: https://github.com/kiprotect/go-helpers/tree/master/forms
This is why I originally started a project to convert ts to json schema; https://github.com/YousefED/typescript-json-schema (and also check out a good alternative https://github.com/vega/ts-json-schema-generator)
You can write validation schemas using zod library [1]. They end up looking pretty similar to typescript definitions (same vocabulary, same methods for combining/intersecting/filtering). And if you migrate to typescript you'll get type definitions for free out of those schemas.
[1] https://github.com/colinhacks/zod
Bundling for OpenAPI specification has long been a need for authors to allow to reduce duplication, and to allow to split a big specification in multiples files, but publish a single one.
A few years ago I've written a tool to fit that niche: https://github.com/dolmen-go/openapi-preprocessor
https://github.com/dolmen-go/openapi-preprocessor
I have now to tweak it (well, it will be a major rewrite) to handle $ref relative to $id instead of the file location.
If you like zod, you should check out myzod: https://github.com/davidmdm/myzod
For those looking to sanitize input from Typescript, I highly recommend the runtypes library: https://github.com/pelotom/runtypes
It let's you specify type definitions a DSL in Typescript using syntax very similar to Typescript's type definitions. Once you define your types in the DSL, you get Typescript types and parsing / verification for free. Not as general purpose as JSON Schema, but 1000x cleaner and easier to use.
> I think JSON Schema could have been a bit simpler, but it's still nowhere near to making the same mistakes as XML Schema.
Agree with every single one of your points, and this in particular. Thankfully, there are some heroes out there developing excellent tooling to make working with JSON schema easier. I've been making good use of Ajv[1], and highly recommend it to anyone having to deal with JSON payloads and schemas in a javascript environment. (I'm not affiliated with Ajv in any way, just happy with it.)
Working without a schema is much faster when getting started, obviously, but once things solidify in my experience a schema will help more than it costs and excellent tooling goes a long way in easing that transition from schema-less POCs to stable high quality implementations.
[1]: https://ajv.js.org
I've never seen runtypes, but I've seen io-ts [1]. Are you aware of the pros/cons between them?
[1] https://gcanti.github.io/io-ts/