Advantages would be:
- The sharing of database ORM models across multiple programming languages will be seamless.
- Making the API available via Thrift (like the Evernote API) implies native API wrapper libraries can be automatically generated for almost any programming language.
- Using Thrift also means the storage of logs, etc. in JSON / Thrift format will be straightforward and migration to a Lambda Architecture in future would be far more plausible as well.
- Performance enhancements such as converting long keys to actually short keys in backend (for MongoDB, HBase) and using good hash keys (for DynamoDB) can be handled in this layer without every language-specific wrapper having to implement it.
- Switching some data from Postgres to MongoDB or sharding in MongoDB, etc. could be hidden as internals of this layer.
- Rate-limiting, monitoring and scaling would have been easy – and Django memory leaks, etc. would not affect other parts of the system…
- This would have easily enabled having a lot of small apps instead of a big monolithic Django app, etc.
Did we just sort-of reinvent Datomic?
Of course, this is not a new idea at all, take restSQL as an example – my question is why is this not talked about more often?
Do most frameworks support this? If not, why not? If so, why don’t most frameworks don’t talk about such a use case in their documentation? If I use Django, I’ll start writing the models and use South to create migrations, and that’s that. If I have to reuse those model, from say, Java, then you’re on your own. The point is that, by default, Django (or Rails) doesn’t encourage you to do such a thing. If you go for a lighter framework such as Flask, then this becomes easier because the ORM is anyway not part of the framework.
Is this concept felt needed only in a polyglot case (multiple database systems, multiple programming languages)?
P.S. Also read Stevey’s Google Platforms rant.
Update on [2013-04-28 Sun]: Also see the very useful tech talk Designing a Beautiful REST+JSON API.