Meteor: Right on Time

In the modern world of fast-evolving software technologies and the ever-changing UX trends, it’s crucial for the web developer to keep up-to-date creating optimal approaches to implement the business logic of each individual project. Not only that but web and mobile applications usually tend to expand, and there are almost no limits of this growing. There are only pitfalls in technologies, and any new framework tries to get rid of them.

In the case of Meteor, the fresh Javascript web platform, it was designed to decrease the department between client and server in web-based applications. While UX requirements to dynamism, especially in single-page projects, pushed web front-end development to the state when Javascript frameworks evolved — most notably Angular, Backbone and Ember (first releases in 2009, 2010 and 2011 respectfully). They solved the problem of front-end Javascript code structuring but required a separate server back-end to work properly.

Where has this led to?

This has led to lots of projects being made using some back-end framework and a separate front-end framework which were connected more or less successfully. Taking into account that those layers were written in different languages by different developers lacking grasp of each other’s technology, multiple issues were likely to occur in between. Besides, it could architecturally turn a single-page application into a mess with redundant data processing.

For instance, if the server uses Ruby on Rails and an SQL database, a typical flow of events after each AJAX request would be something like that. JSON data is translated into Ruby object then the script makes a request to the database using SQL. The results are converted to Ruby objects again, then back to JSON, so that the client-side script could parse it and make some additional data processing. It seems like too many conversions, doesn’t it?

Node.js and Meteor.js

Node.js, a server-side Javascript environment released in 2009, made it possible to build a client-server application using only Javascript as a programming language. But it appeared to be too low-level compared to Rails and other contemporary server-side frameworks. There was an evident public demand of the framework which could combine Node.js technology with front-side functionality, preferably supporting MongoDB as the database operated using Javascript.

In 2011, Meteor appeared as an open-source project causing a lot of fuss from the start. It was the third most starred GitHub repository in 2012 (currently it’s the tenth in all history), which was a definite success undoubtedly planned by its creators who have paid proper attention to its promotion. They have declared a goal “to build a new platform for cloud applications that will become as ubiquitous as previous platforms such as Unix, HTTP, and the relational database” and by the end of 2014 reached version 1.0 which usually means that the software creators appreciate using it in production.

So, what’s the trick about it?

The main feature of Meteor is called Distributed Data Protocol or DDP. It is the medium between clients and servers which implements the concept of publishing and subscribing. On the server side some portions of data are “published,” meaning that the client has straight access to it which then makes it possible to initiate database queries in client-side code. The client “subscribes” to certain data to get live updates if the data was changed and to refresh web page elements without writing any additional code.

Let’s take a collaborative text editor as an example. The clients are subscribed to the document, so each client gets a live update when its state changes refreshing only the altered part of a document. This enables each client to see the results of each other’s actions instantly with little delay. There is a delay only because the client polls the server for possible updates every 10 seconds (this limit may be overcome, you may read about it here).

Latency Compensation

Another convenient feature of Meteor is the latency compensation. When a user updates some portion of data it gets updated in UI before there is an actual response from the server predicting this response. Then if the response differs from expectations, the template partial gets updated once again. There is not much new about it. Front-end developers were doing it years before by writing custom code. The innovation here is that it works right out of the box, saving development time, which is what frameworks are made for.

For a closer view of Meteor, you may use its comparably well written documentation or plenty other resources which are quite sufficient because of its growing community.

The framework is too young now, but it has a great potential to become one of the most demanded web platforms erasing the borders between front-end and back-end development. It fulfills the expectations of web developers and all it needs is to mature after more tasks are implemented in various projects and more contributions from programmers are suggested. As for now this evolution seems rather inevitable.

Written by: Sergey Chuguev on April 24, 2015.

Originally published at 111 Minutes Blog.