A Vision For the Real Time Web Future: The PEEIN Stack

#1

The future of the web is real time. Can Ember.js answer alternatives like the MEAN stack and full stack frameworks like Meteor and Derby? I believe it can. In fact most of the pieces are already in place:

  • Postgres
  • Ember.js / Ember CLI
  • Express-
  • Io
  • Node.js

In Ember CLI, we already kinda have a server and framework for development back there which is Node.js / Express. It would be possible to create a “distribution” with Ember-CLI and a few addons to make it easy to install and setup this entire stack. Specifically, we need ember-cli addons for setting up express-io on the development server.

So what is the real missing link? An Ember Data adapter and serializer for the realtime socket-io layer of express-io that can work with data as created by any of the ORM solutions for Node.js and Express. I use Bookshelf at work, and unless someone has a better suggestion, I think the data format should be compatible with Bookshelf Models.

I’d love to hear your feedback on this vision, and if any of you would like to help write the Ember Data adapter.

#2

I had a related but slightly different thought the other day. When FastBoot is released, Ember will be able to run on a server. If there were a Postgres adapter for Ember Data, you could have the beginnings of a isomorphic full-stack framework: if the app is running on the client, the data layer would make an HTTP request, and if it were running on the server, it would make a SQL query. In a first implementation, the web server might simply provide all RESTful actions for every model; in subsequent implementations, it might provide a way to scope down the available actions, and then some sort of authorization scheme.

The awesome thing about this approach is that you would only have to define your model logic in one place, and it would be re-used between the client and server. Validations, authentication, and authorization could similarly run isomorphically where appropriate.

The non-awesome things would be that it would require basically writing a new ORM (or hooking an existing one into an ED adapter), and for most apps would eventually lead to object-relational impedance mismatch (and client-server model impedance mismatch). But I think it would be a powerful tool for getting a new app off the ground quickly, and unlike Meteor or Derby that use their own niche toolsets, would let you continue to use the same tools even if you eventually decoupled your client and server-side applications (you could continue to use Ember client-side and Postgres for your data store, and just add your custom server layer between).