JSON as a Universal DB Model DSL

December 30th, 2009 by John Nelson Leave a reply »

I write web applications rarely and reluctantly. I am not the most qualified to initiate a project based on the following ideas. If I did, it would likely  fall into a state of disrepair once my ephemeral attention has shifted back to playing with stock prices. However, I think it is a good idea. I am hoping someone who has both the time and interest codes it up. This is a new level of lazy.

var user_model = [
    // column name , generalized type,   , validation rule,   hidden?
    ['first_name'  , 'text'              , 'name_regex'              ],
    ['last_name'   , 'text'              , 'name_regex'              ],
    ['middle_name' , 'text'              , 'name_regex'              ],
    ['birth_date'  , 'date'              , 'over_18'                 ],
    ['location'    , ['double','double'] , undefined,        ,   true],
    ['addresses',  , 'has_many'          ,                           ]
];

Basically, from a Rails perspective, replace your ruby database migration DSL with code that parses the above JSON (e.g. user_model.json) and creates the appropriate schema. Replace your ActiveRecord validations with the validations from the json model. (Depending on your language, there may be differences in REGEX syntax. Having some well defined common REGEX definitions, such as EMAIL_VALIDATION, might be appropriate.) On the client side, you can display most forms automagically, based on the order defined in the json model (if it is in fact an array.) Furthermore, you can also run client side validations before submission. (If your validations are so weak that sharing them remotely represents a security risk, you are probably doing something wrong.) It might also remove the need for many controllers. A lot of CRUD is so generic that it might be possible to have a single /:model/:action/* controller. Scaffolding is not DRY. Finally, as the lingua franca, sharing model definitions outside your project’s language is simplified.

Any takers?

Advertisement

2 comments

  1. John DeHope says:

    I think about this all the time. I belive you could reduce 80% of a typical line of business app down to something like this. A lot more than what you have here is needed. But it’s more content, not more concept. Things like the state or status of core business entities, which fields are important under which states, users being grouped into roles, and which roles can perform which state transitions, etc. Like I said this is just more data than you have, not fundamentally different. Like you, I see the main benefit in this being that you could write consumers (ui, validation, permission, storage, etc) that are totally generic, just fed the schema, and everything else is automagical. I’m still building my castle in the sky, on this one.

  2. Arnab says:

    Good idea. See JAQL (http://www.jaql.org/), an IBM project that allows for querying over JSON (and is hadoop-ified), making it easier to do analytics, etc.

Leave a Reply