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

Schema/DSL for Decorators + FieldItems #549

Open
toastercup opened this issue Jan 13, 2018 · 1 comment
Open

Schema/DSL for Decorators + FieldItems #549

toastercup opened this issue Jan 13, 2018 · 1 comment

Comments

@toastercup
Copy link
Member

toastercup commented Jan 13, 2018

Currently, the structure of Decorator and FieldItem data fields is the wild west - you pass the JSON values directly to the model with no guardrails preventing invalid or extraneous values. As we start to consider migration tools, these constraints will become vital - for example, plugins can use them to determine if an upgrade will break any existing FieldItems or Decorators. It also provides a path for migration of these data columns. Additionally, it makes these structures self-documenting and far easier to work with and comprehend.

We have a few choices at our disposal. We could allow core & plugins to:

  • build DSLs for each structure using Docile (likely the most idiomatic approach)
  • define JSON Schemas for each structure using ruby-json-schema (likely less overhead, more portable to other languages should they want to reflect on these structures)

Let's discuss the pros/cons of each in more detail here before we come to a decision.

@toastercup toastercup changed the title Proposal: Schema/DSL for Decorators + FieldItems Schema/DSL for Decorators + FieldItems Jan 13, 2018
@toastercup toastercup added this to OKRs in Roadmap Jan 13, 2018
@MKwenhua
Copy link
Contributor

I would 100% suggest JSON Schemas over Docile. DSLs are less explicit and harder to heard especial when distributed through out the entire application. The more clear and straight forward the information the better, and I think JSON is easier to read than a struct.

When anyone new joins the team, having a new custom made DSL would be another abstraction someone would have to learn before they can really contribute to Cortex. DSLs are rarely a good idea(sometimes they can be when included in a framework), but any other time it does nothing more than obfuscate the code.

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

No branches or pull requests

2 participants