The IT-architecture of Muscula is one that I'm proud of.
Everybody has JavaScript errors.
That is why Muscula needs an it-architecture that can service a lot of users.

The IT-Architecture of Muscula: Node.JS, MongoDB and CDN

By: Allan Ebdrup, the maker of Muscula. November 29th, 2011.

What is this document?

This document gives an overview of the unique technical architecture of Muscula. I'm very proud of it, and by sharing this, I hope I can inspire others to take some of the ideas presented here and build their own awsome webapplications. Also I hope you will leave comments and ask questions.

Top level overview

At the very top level the application consists of two components: Frontend and backend.

Frontend

The frontend has all the parts that are necessary to render the UI. Every single thing in the frontend is on a CDN. All the html, html-templates, css, images and JavaScript is on a CDN as 100% static files. Every single piece of html in the frontend is served from CDN.

The frontend interfaces with the backend entirely through JSONP calls and the only thing passed through those JSONP calls is pure data as JSON strings. There is no html-markup whatsoever on the backend. The separation between frontend and backend is logical as well as physical. The frontend is hosted on entirely different servers than the backend and on a different domain.

The frontend itself is layered in tiers: Model, presentation and other separations of concerns. I make heavy use of the observer-pattern, and use an object oriented component model. The application itself is a single-page application. All the html-templating is done entirely with JavaScript.

Backend

The backend is build with Node.JS and MongoDB. The backend is also layered in tiers. There is a layer for security, a layer for data access, a layer for returning uniform error messages and status codes and other layers.

Advantages of the architecture

The advantages of this architecture over a more traditional architecture are many.
  1. No session state on the webserver. As the frontend is a single-page application, the session state can be stored in the users' browser in memory. The session state never has to go on the server. The only piece of session state on the server is a login token for handling security. Calls to the backend can go to any webserver in our web farm. There is no sticky-ip. This makes the application more robust and scalable.

  2. One programming language in the entire technology stack: JavaScript. Serialization of data is even done in JSON, a part of JavaScript.

  3. Low operational costs. When everything possible is on CDN, the load is taken of the backend. This means the price of running the backend is reduced, as it needs much less server power. A CDN is cheap, I am using Google app engine, where the price is determined entirely by the amount of traffic you have. This is what lets us give you unlimited page views on all Muscula price plans.

  4. Scalable. A CDN is probably the most scalable thing in the world. The backend also scales incredibly well. In part because Node.JS uses non-blocking IO and is generally fast. And in part because the NoSQL database MongoDB performs and scales so well. MongoDB is designed from the bottom up to scale out on a lot of servers.

  5. Very fast load times for the users of the application. A CDN is the fastest way to serve static files internationally. Node.JS and MongoDB are a fast combination.

  6. When you build your backend, you are basically building a public API at the same time. Also the clear separation between frontend and backend makes the cooperation between the backend-team and frontend-team more efficient.

  7. The static part of your website is immune to denial of service attacks. I have not tested this, but when all your static files are on CDN, they are spread geographically across a lot servers. I think a hacker would have a hard time taking Googles CDN down. At the very least, you will survive having any amount of press coverage by all major media.

  8. Schemaless database. Once you've gone schemaless there is no going back to a traditional relational database, for our kind of application. With a schemaless database the frontend developer can make many changes without involving the backend-team. Furthermore, half the time when the backend-team is involved, they are just advising, not actually implementing the datamodel or having to write new webservices.

  9. No ORM. Everything is JSON strings and JavaScript objects.

The architecture and technology stack have been a dream to work with. And the performance is unbelievable. Please comment and ask questions if you have any.