Tag Archives: Architecture

Trello Architecture

Trello is a state of the art technology website developed by Fog creek software for managing anything (be it personal tasks, Vacation planning, project planning etc.) collaboratively by a group of people or individual.

This is how the application is designed and working:

Trello Arch

  1. Trello is a Single-page app that would generate its UI on the client and accept data updates from a push channel.
  2. They use CoffeeScript which does all the client side functionalities.
  3. The main client side technologies other than CoffeeScript:
    i)    Backbone.js (client-side MVC).
    ii)    HTML 5 pushState
    iii)    Mustache (templating language)

4.    Trello servers serve virtually no HTML, In fact, they don’t serve much client-side code at all. Since it’s a single-page app, a single minified and compressed approx 250K app is downloaded initially in the form of JS file, after that everything else is asynchronous.
5.    Initial single minified/compressed js file contains third party libraries, compiled CoffeeScript and Mustache templates and a CSS file (Compiled from LESS source with inlined images).
6.    This minified initial file is served through CloudFront CDN, so initial load of the app is fast irrespective of geographic location.
7.    In parallel, Trello kicks off an AJAX data load for the first pages data content and try to establish a HTML 5 websocket connection to the server.
8.    After data is returned from server through Ajax call, Backbone.js is in play to bind the data to DOM and display the content, just like our Knockout.js.
9.    There won’t be any page transition from one page to another after full initial page is loaded. HTML 5 PushState is used to move between pages and to provide consistent links in the location bar and just load data for backbone based script to handle transition.
10.    To represent HTML as client side model, Mustache is used as a templating language.
11.    When there is browser support on HTML 5 websocket (chrome, firefox and safari), websocket connection is made so that server can push changes made by other people down to browsers listening on the appropriate channels. So when anything happens to a board you are watching that action is published to trello server processes and propagated to your watching browser with very minimum delay, usually under a second.
12.    When browser don’t support websockets (browser like IE), they use AJAX requests to get updates every couple of seconds while user is active, and back off to polling every 10 seconds when the user goes idle.
13.    Major server side technologies are:
i)    Node.js ( server side technology)
ii)    Redis (To share data between users at the server)
iii)    MongoDB (Database )

14.    Server side of Trello is mostly built using Node.js. Trello wanted instant propagation of updates, which meant that they needed to be able to hold lot of open connections, so an event-driven, non-blocking server seemed a good choice, so they chose node.js.
15.    Client simply invoked those functions written in node.js throw a thin wrapper over a websocket.
16.    Trello uses Redis for data that needs to be shared between server processes but not persisted to disk.
17.    Interesting use of Redis is for sending changes to Models down to browser clients. When an object is changed on the server, they send a JSON message down all the appropriate WebSockets to notify those clients, and store the same message in a fixed-length list for the affected model, noting how many messages have been added to that list over all time. Then, when a client that is on AJAX polling pings the server to see if any changes have been made to an object since its last poll, they can get the entire server-side response down to client.
18.    Since trello have to work extremely fast, they used MongoDB to store data permanently.
19.    MongoDB is a documents database, so it stores a trello card’s data in a single document.