Live data from Hacker News

The Trello Tech Stack

blog.fogcreek.com

51–60 of 96 posts

Re: The Trello Tech Stack

#51
post #32

Use things that are going to work great in two years. 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? - Don't use a technology that, no matter how good, is just too niche for widespread adoption? - Don't use a technology that we'll have trouble finding programmers to support? - Look for stuff that will take better adva…

It might also include things that don't work so great now, but show promise, and will work great in 2 years at their current rate of development.

Re: The Trello Tech Stack

#52
post #44

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

Socket.io: https://github.com/LearnBoost/socket.io/issues/686 MongoDB (on FreeBSD): https://jira.mongodb.org/browse/SERVER-3927 Redis: https://github.com/antirez/redis/issues/91 . . . are a few.

dodger: I'd be curious to know where y'all bled over CoffeeScript or Backbone, if you don't mind sharing.

Re: The Trello Tech Stack

#53
post #48

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 mainstrea…

What would be the difference in how you would handle this in a single-page JS app like Trello versus a traditional Java/Python/Ruby-based multi-page backend that mostly serves HTML pages?

It seems like at the end of the day you still need to validate and sanitize user input before doing anything with it.

Re: The Trello Tech Stack

#54
post #48

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 mainstrea…

What would be the difference in how you would handle this in a single-page JS app like Trello versus a traditional Java/Python/Ruby-based multi-page backend that mostly serves HTML pages? It seems like at the end of the day you still need to validate and sanitize user input before doing anything with it.

I was inquiring more about the backend js use in node and mongo.

You might, for instance, find that simply sanitizing user input isn't enough when you're using the same interpreted language at multiple stages. If an attacker could cause the right front end code to be executed on the app server, or backend code to be executed in the database you could potentially compromise a lot.

Re: The Trello Tech Stack

#55
post #44

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

Socket.io: https://github.com/LearnBoost/socket.io/issues/686 MongoDB (on FreeBSD): https://jira.mongodb.org/browse/SERVER-3927 Redis: https://github.com/antirez/redis/issues/91 . . . are a few.

The MongoDB one is a real cliffhanger. What happened?

Re: The Trello Tech Stack

#56
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?

Its news to me.

Re: The Trello Tech Stack

#57
post #44

Earlier quoted context omitted.

Socket.io: https://github.com/LearnBoost/socket.io/issues/686 MongoDB (on FreeBSD): https://jira.mongodb.org/browse/SERVER-3927 Redis: https://github.com/antirez/redis/issues/91 . . . are a few.

dodger: I'd be curious to know where y'all bled over CoffeeScript or Backbone, if you don't mind sharing.

Actually, those have been great (and thank you for making them)! We had an outage during beta because somebody forgot to wrap an array comprehension assignment (CoffeeScript) and we didn't test right. Backbone has been really good, and while we had some complaints, I think many have been resolved in more recent versions - we're on something ancient.

Re: The Trello Tech Stack

#58
post #55
post #44

Earlier quoted context omitted.

Socket.io: https://github.com/LearnBoost/socket.io/issues/686 MongoDB (on FreeBSD): https://jira.mongodb.org/browse/SERVER-3927 Redis: https://github.com/antirez/redis/issues/91 . . . are a few.

The MongoDB one is a real cliffhanger. What happened?

We worked around the bug (which only happened when we were doing REALLLY long queries when we disconnected a client) and moved to Linux, where the bug does not exist. Awesome sysadmin Tim GDB'd into Mongo and figured out that it was an issue with SpiderMonkey, fixed in later versions.

Re: The Trello Tech Stack

#59
post #22

Earlier quoted context omitted.

nginx supports http1.1 reverse proxying as of a few weeks ago http://wiki.nginx.org/HttpProxyModule Mikito Takada (Zendesk) has some really helpful information regarding socket.io + haproxy specific workarounds via http://blog.mixu.net/2011/08/13/nginx-websockets-ssl-and-soc...

Thanks. Looks like it's available only on the development version - I wonder if it's production ready... Also - I took a look at the article - it does not mention using a total node approach of using something like node-http-proxy for load balancing. Any idea on such a set-up? I need HTTPS as well.

A pure-Node approach is a lot simpler: you can just use Node's HTTPS (if you don't care about load balancing) and attach Socket.io to it. Just don't put your Socket.io server behind Nginx if you want WebSockets support.

With load balancing, I would recommend going with Stud/Stunnel and HAProxy. Terminating SSL with a specialized piece of software is nicer (separate SSL overhead to another box), and using a separate load balancer allows for more flexible options, e.g. serving static assets from Nginx. There is nothing wrong with node-http-proxy, it's just that these two projects have been around for longer and are better understood from an ops perspective.

You cannot use round robin load balancing, you need to have at least IP-based stickiness with Socket.io for now. Well, you can round robin if you use the Redis store but you'll run into inefficiencies with https://github.com/LearnBoost/socket.io/issues/686 . I'll do a bit more coverage on other SIO deployment-related issues once I get the chapter on Socket.io finished for my (free) book in a few weeks.

If I were starting now, I'd just ignore the Flash sockets transport since it makes the whole stack more complex due to not looking like HTTP to load balancers, and start with Engine.io / WebSocket.io to take advantage of their simplicity.

Re: The Trello Tech Stack

#60
"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.

http://lostechies.com/derickbailey/2011/09/26/seo-and-access...

Post reply on HN