BT

The Post-HTTP Era: Real-Time Web Apps With Meteor

by Zef Hemel on Jun 12, 2013 | NOTICE: The next QCon is in San Francisco Nov 3-7, Join us!

During the HTML5 Track at QCon New York 2013 Matt DeBergalis gave a talk on Meteor, the open-source real-time web application framework that Debergalis co-founded. According to DeBergalis, the client versus server-side pendulum has swung many times: from the mainframe (server-side) to the desktop (client-side) to the web (server-side) and now to the modern web where clients get increasingly capable and more and more work happens in the client again. However, the tools to build these modern web applications, DeBergalis argues, have not caught up. The goal of Meteor is to provide the developer with the tools to build these types of real-time web applications more easily and consistently.

Today's modern web applications consist of two disparate parts:

  1. The server-side may be built using e.g. PHP, Java or Ruby, using specific server-side APIs, and tools for building software and managing dependencies.
  2. The client-side uses one or many JavaScript libraries, HTML, CSS and is built using its own build too, for instance Google Closure Compiler.

The two communicate using essentially a custom wire protocol, usually encoded using JSON over HTTP or Websockets sending commands: send me this piece of data, persist this new piece of data, render this piece of data etc.

Meteor is rethinking this approach and aims to make everything real-time. For this purpose it does not deem HTTP a good fit, instead, communication (beyond delivering the web resources) happens via websockets using its DDP (Distributed Data) protocol. The DDP protocol is a generic protocol (encoded using JSON) that supports three core operations:

  • Subscribe: using the protocol a client logs on and says: "I'm interested in data collection X, send me an initial snapshot of all its data, then keep sending me deltas so that I can keep my cache up to date."
  • Publish: "property X of entity Y has changed its value to Z."
  • Remote-procedure call: these are used to execute a remote procedure and to return the result in a fault-tolerant way.

Meteor comes with a DDP implementation for server and client written in JavaScript (Node.js with Fibers on the server). However, the protocol is implementation-agnostic, so alternative implementations can be written. For instance, there is a .NET client library already.

The second component of Meteor is its view engine, automatically keeping the DOM up-to-date with underlying data, similar to what AngularJS and Web Components support.

The third component of Meteor is packaging. Since Meteor components are not just server-side or just client-side, current package systems are not suitable. Meteor's packaging system distributes both the server and client-side components.

Meteor itself decides what parts of your code base need to run in the browser and what parts will run on the server. DeBergalis says that there is currently work underway to use static source code analysis techniques to better partition code, so that only the code that the client absolutely needs is pushed.

Real-time pushing of data is not the only real-time aspect of Meteor. One of the most striking elements of the demo was hot code pushes: whenever the developer saves a file, Meteor not only automatically reloads the code on the server, it also automatically packages up the code and pushes it all the clients, ensuring that all clients are running the latest and greatest version of the client-side code compatible with the server-side code.

Meteor is an interesting full-stack approach to real-time web application development. To learn more about it, consider reading the documentation and look at examples at its website, there is also a book written on Meteor, which we reviewed here on InfoQ.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

I stopped at Meteor.isClient() and Meteor.isServer() by Ryan McDonough

There are some good ideas in Meteor, but I need some convincing that packing the client and server code together is a good idea. Especially when the framework has functions that allow you to check if the code is running in a client or server environment. Personally, I'd rather a void all of these if/else conditions in my code and, you know, package the client and server separately. I'm not even getting into the arguments on security, etc..

Re: I stopped at Meteor.isClient() and Meteor.isServer() by Matt DeBergalis

You can do that. Code in the /server directory is never sent to the client.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT