Migrations in the base template

[kaievns]

I don't think migrations should be a part of the base template. A lot of projects, especially in a microservices oriented architecture don't need migrations. So, I recon it should be a separate thing.

Also, do we really want a home grown migrations engine? It's a pretty delicate area, proper fail overs, rollbacks, and support of transactions is a must. I'd feel much easier about running migrations, especially in production, if we were using a battle tested solution.

Moreover, migrations solution for an SQL and NoSQL dbs might be quite different in their nature and would benefit from using context specific packages. I don't think the one size fits all is the best approach here

[davidbanham]

I agree they should be a component rather than part of base. I think what we probably want is everything pretty decomposed, but then an alias that installs All The Things. I think by default you should get a full suite of things, but if you only want to install bits and pieces you can do it manually one-by-one.

I looked for an existing RethinkDB migration engine and couldn't find a good one, so I wrote this. It's not rocket science.

Also, Redbeard is tied to RethinkDB. We don't need to worry about migration strategies on SQL or other document stores since that's not a target.

The whole point of Redbeard is the realtime stuff, in my view. The use of JSON schemas as models, the admin UI and the other ecosystem stuff is also really nice, but it's the realtime stuff that's the killer feature.