Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

type checking - tcomb or other #11

Open
danalexilewis opened this issue Apr 17, 2017 · 3 comments
Open

type checking - tcomb or other #11

danalexilewis opened this issue Apr 17, 2017 · 3 comments

Comments

@danalexilewis
Copy link

After reading @ahdinosaur comment in the feathers action issue: #9 (comment) I went and did a little reading around json-schema and type checking.

gcanti did publish a module for json-schema to tcomb and in an issue a zerkalica asks about ajv - commenting that it has more feature but is too bloated for front end (200kb at time). https://github.com/epoberezkin/ajv

I looked at ajv and thought that it looked active and I started wondering if this would be a good alternative for tcomb for us.

Main benefit I see is using json-schema to define our types rather then tcomb objects. json-schema is obviously more established and is used in other languages. We could then also look to develop a json schema as part of our discovery phase.

Main flaw is maybe its size - though given we are using other bloated libraries I don't think this matters to much.

@ahdinosaur
Copy link
Member

ahdinosaur commented Apr 17, 2017

@agentlewis is your question "tcomb or json schema?"

(the side conversation about arj is distracting, especially when looking at the source is not close to 200kb, and there are many many high-quality json schema implementations.)

i'm keen for json schema, since it's an established standard and there are many high quality libraries that would allow us to have a single set of schema definitions that we can use for form validation, server endpoint validation, maybe form generation, maybe server endpoint generation, server endoint documentation, etc.

from Slack,

json schema is: https://spacetelescope.github.io/understanding-json-schema/. it's pretty powerful, a standard that hasn't changed in a while so lots of tools, but more syntax so say what you want.
also things like https://mozilla-services.github.io/react-jsonschema-form/, similar to tcomb-form
https://www.brandur.org/elegant-apis
also swagger and raml support json schemas: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#schemaObject, https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md/#using-xml-and-json-schema

@danalexilewis
Copy link
Author

@ahdinosaur Ok fair enough that wasn't clear.

Clarifying and interested in my understanding being corrected:

Within tcomb we both define the data model with types and use the library to run validations.

Where as with json-schema we solely define the data model and types.

Therefor to use json-schema we need a library to run the validations - eg ajv - which looks to be popular and therefor fitting with the paradigm of dogstack: using popular tools.

Thanks for the links - I think they are getting at what I was asking.

In this particular case I was riffing on Samza and my interest was in using type validations in place of a relational schema (sql). This would both be to provide final data checking and it is where I wish to start development in future projects.

@ahdinosaur
Copy link
Member

ahdinosaur commented Apr 24, 2017

after some thought, yeah i think we should use json schema with ajv. also there's built-in support for this in feathers.

see also root-systems/dogstack#47 for a discussion on static typing, where we could generate static type interfaces from our json schemas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants