Investigate alternatives to Joi for schema definition

dwyl / abase

:house: A (solid) Base for your Web Application.

9 stars 0 forks source link

Investigate alternatives to Joi for schema definition #26

Closed nelsonic closed 7 years ago

nelsonic commented 7 years ago

Joi https://github.com/hapijs/joi was designed for a specific purpose (validation) and it fits that purpose really well. But

http://json-schema.org/ is a proposed standard with a well-defined spec: http://json-schema.org/documentation.html

First step is defining our requirements.

extensible
standards-based
non-complex syntax

eliasmalik commented 7 years ago

JSON-schema looks cool, and has similarities to the structure described in #20.

It looks like there is pretty decent support for many of the data types we might encounter. I haven't checked if it covers everything Joi does, but I imagine anything not covered might be a fairly niche data type, that could maybe be tackled by extending the standard

eliasmalik commented 7 years ago

This obviously wouldn't help us specifying permissions, or view rendering though like we are doing with the "pages" field in the example in #20.

One option is to make each value in the "fields" object be a instance, so they can be parsed by a JSON-schema parser.

Going with this option means we have to either ditch Joi entirely and go with a solution that uses JSON schema to validate requests on Hapi (like ratify), or come up with our own mapping from JSON schema to Joi objects, in which case (h/t @jrans), why bother with JSON schema?

Thoughts, anyone?

jrans commented 7 years ago

the sole mis-answer on this question shows people have thought about storing it.

jrans commented 7 years ago

@nelsonic Having started to work with json-schema as suggested and deciding to implement we found a couple of problems:

You need to make sure the schema they have given acts as a valid schema
Although well defined spec its quite an overhead for users of abase to get up to grips with it if they haven't used before.
Still need to be able to interpret it ourselves and therefore applying more constrictions for the user to learn.

Creating our own api heavily inspired by joi where possible seems like a better idea as we have found the api-reference very good. It's well presented, easy to understand, see all possible options quickly and if followed we can easily implement the validation with joi if we follow a one to one mapping.

samhstn commented 7 years ago

Closing issue, as we have conformed to following Joi's api and away from JSON schema. Will reopen if following Joi's convention becomes problematic.