The Trello Tech Stack

<i>Use things that are going to work great in two years.</i><p>This is one of those remarks that is obvious to someone who knows what it means but mysterious to someone who doesn't. So what does it really mean?<p>- Don't use a technology that, no matter how good, is just too niche for widespread adoption?<p>- Don't use a technology that we'll have trouble finding programmers to support?<p>- Look for stuff that will take better advantage of impending improvements in hardware and communications?<p>- Avoid frameworks for which support may wane?<p>- Avoid technology that we may have to support ourselves?<p>- Avoid anything proprietary whose owner may disappear?<p>- Make sure that whatever you choose, it will work well on mobile technologies, even as native apps?<p>- Choose technologies abstract enough to minimize our costs but not too abstract to be inefficient?<p>- Any combination of the above?<p>- What considerations have I missed?

Not to pick on him, because I think the overall received wisdom on new tech has shifted and morphed a great deal over the last few years, no doubt including Joel's...but I can't resist pointing out that, my how times have changed...<p><a href="http://www.joelonsoftware.com/items/2006/09/01.html" rel="nofollow">http://www.joelonsoftware.com/items/2006/09/01.html</a><p>In other words, it's nice to see Joel greenlight something like this, I'd say it's kind of a sign of the times in terms of the industry's overall comfort level with what would be termed 'hip' technology, or 'new' or whatever moniker you want to attach to it.

This part caught my eye:<p>"The Socket.io server currently has some problems with scaling up to more than 10K simultaneous client connections when using multiple processes and the Redis store, and the client has some issues that can cause it to open multiple connections to the same server, or not know that its connection has been severed."<p>I wonder if they ran into redis's hard-coded 10k connection upper-limit. As it turns out, their configuration for "unlimited" connections actually has a cap of 10k. I believe in master this is going away, but if you need more than 10k connections on redis &#60;= 2.4, you need to manually patch the daemon, in case anyone else runs into this.

How vulnerable are all javascript approaches in terms of injection type attacks? Do apps like node and mongo effectively prevent them, or is it still possible to shoot yourself in the foot? I've read some off hand comments along the lines of "as long as you're not a total moron you have nothing to worry about", but that sounds a lot like what was said about sql injections and xss before exploiting them went mainstream and it turned out everyones apps were filled with them. Has anyone audited a real world app built with a stack like this and come away with any experience to share?

Just had to share this:<p>Our stack is Redis, MongoDB, Nginx, SCSS, HAML, Coffee, Rails and NodeJS. I'm extremely happy with these choices.<p>Recently me and a friend did a small weekend project: www.bubblefap.com (nsfw) The design and code is a homage to ugliness. We only used PHP-ActiveRecord and that's it. and I had so much fun!<p>I just hacked away! I was cowboy coding, hacking away, and I didn't need to think about frameworks and architecture and integration with fog and hacking Rack to support flash uploads. Oh, good times :-)

Node.js, Redis, <i>and</i> MongoDB? They've gone full web-scale!<p>In all seriousness, though, it looks like they are using Redis for exactly the right reasons, and the larger architecture is pretty much the definition of a sane forward-looking design.

I think this is the best write-up I've seen of a full Javascript/CoffeeScript stack.<p>I've always been hesitant to get too far away from my LAPP(ython) stack, but I'll almost certainly be hacking something together with these components to see how I like writing everything in CoffeeScript.

Nice job, guys. I love this architecture. This looks a lot like my dream stack for future web work.<p>Would love to hear some more about the "bleeding" experiences you've had.

"We custom-built a client-side Model cache to handle updates and simplify client-side Model reuse."<p>Is this related at all to backbone.iosync.js?* Or, if not, is it something that Fog Creek will be open to sharing in the future?<p>* <a href="https://github.com/logicalparadox/backbone.iobind" rel="nofollow">https://github.com/logicalparadox/backbone.iobind</a>

Question: They tout MongoDB's "generally fast" read speed. Any idea what this is in relation to? In "fast", are they suggesting that it is faster than a typical RDBMS? If so, does anyone know of any supporting benchmarks or breakdowns of how they accomplish this and to what extent?<p>Its news to me.

Does anyone know of any open-source projects out there using a similar stack? I'm particularly interested in learning more about client-side view rendering with Backbone and Mustache... server side can be any of Node, Rails or Django.

"We use a really excellent async library"<p>Does anyone happen to know if this is an open source or in house library?

This is a great write up. We have a very similar stack for a separate team based project we're working on. The only difference is the front end stack, and we have tornado sitting back on the backend to serve http requests when needed. What's the benefit of Mustache/Backbone over just writing your own client side templating, in a practical sense? Last time I used a KVO framework, there was a performance penalty that I did not like. Does Backbone have any performance issues? Or even mustache? What's the trade off of having these frameworks versus generating custom tempting code?

This post raises a few questions for me... and perhaps some one more versed in these stacks can provide answers.<p>- Does the use of CoffeeScript alleviate the MC Escher-esque quality of callbacks within closures involved in working with Javascript on both the server and client (and the data store)? I can totally see the appeal of CoffeeScript's syntax. Giving the programmers something different to look (and learn) at probably provides some cognitive benefit as well.<p>- Is there an acronym/name (ala LAMP) for the Node/MongoDB/Redis stack?

"Client-side MVC" is kind of unfair to backbone.js. I haven't confirmed it myself, but I've seen people explaining how it's also suited to server-side rendering, which means it's not ruled out for competent authors doing progressive enhancement.<p><a href="http://lostechies.com/derickbailey/2011/09/26/seo-and-accessibility-with-html5-pushstate-part-2-progressive-enhancement-with-backbone-js/" rel="nofollow">http://lostechies.com/derickbailey/2011/09/26/seo-and-access...</a>

Great write up. Hopefully that ephemeral data in Redis can scale.<p>They could have used something like Pusher for about half of their implementation (the websockets, message pushing, polling, etc)<p>I bring this up because I built an OSS Pusher clone[1], for those people that want to deploy their own, built on the Play! framework.<p>[1] <a href="https://github.com/danbeaulieu/PushPlay" rel="nofollow">https://github.com/danbeaulieu/PushPlay</a>

If you could do this over again, would you still choose socket.io for websockets, or would you go with something else like PusherApp?

When I first saw Trello I "felt" that something cool was going on under the hood. So I did a little poking to see what JS technologies you guys were using. The piece I was most excited to learn about was backbone. Had never seen it before and was really impressed by the space it was filling and what it's capable of. Thanks for the write up.

Great writeup!<p>Can you guys share what (if any) test suites were used? Was curious on this point.

I have read about various issues in using HAProxy and socket-io (websockets mode). I am currently working on a project that's heading towards that direction - anyone has anything to share on that front?

Great write-up... It made me want to go play with these exact components!

Love the stack, already working on something similar (mine involves nginx, though.) Given we haven't deployed, it's refreshing to see a similar diagram from those already out in front.

Great writeup, I wish more companies did this: be open about their tech stack and experiences.<p>This inspired me to write about how I think, they could've gone even further: <a href="http://wuher-random.blogspot.com/2012/01/single-page-web-apps-and-rest.html" rel="nofollow">http://wuher-random.blogspot.com/2012/01/single-page-web-app...</a>

I am wondering where and how you terminate the HTTPS connections for websockets. Can you share some details on that?

" sending changes to Models down to browser clients". _Down_ to the client? He draws the stack with the client on top and the storage at the bottom, and then says 'down to the client'? I have a collegue who also does this. I never figured out why. Can anyone explain possoble reasoning behind this wording?

Awesome job guys. I'm really digging this stack. It is giving me motivation to learn more about Backbone.js

Does it just go without saying these days that jQuery is required? Trello uses it, as well as jQuery UI, date.js, and highcharts.js far as I can tell.<p>I mention it because they mention other parts of the client stack (Backbone.js for ex), but not said libs.

It seems Socket.io has not had any contenders yet..

Surprised that they didn't incorporate any ASP.NET MVC in there. I was under the impression they were a Microsoft shop?

Pretty cool; any insight as to how they deploy code to production servers?

Very cool. What do you use for search?

The UI could be less cluttered.