#NodeSummit: Large Scale Web
Moderator, Cade Metz of Wired, panel with Bruno Fernandez-Ruiz (Yahoo), Ilya Grigorik (Google), Sean Hess (i.TV), Mark Mayo (Mozilla).
Sean (i.TV) .. Needed to pick an application language. Started as a "TV Guide" app, with a Python implementation. Realized they needed to change the model of what they're developing. Many new kinds of applications. Needed better scale, allow engineers to work on both client and server side.
Googler .. Not aware of anything that's publicly facing that is Node.js based. Google's "Go" language is an alternative to Node? A lot of interesting alternatives. Most focus on performance advantages .. what might be more interesting is the constraints imposed by Node, and its advantages.
How is Node holding up in the kind of scale where 500 million firefox users are hitting the Browser ID service. They chose Node because of memory footprint. Better than even Python/Django. Their service relies on cryptography on both ends, and they had a good advantage from having the same cryptography code on both ends of the pipe.
For scaling - Node has an amazing capability to produce I/O. The guy from i.TV says they never found where Node itself interfered with their ability to scale the service. Instead they found limits such as in using Nginx, and when they removed nginx from the stack the performance improved.
Is Node at a "nascent" or "immature" stage? Not really? There are serious issues with debuggability in a Node program. Compared to other platforms, you don't have much of a stack to trace back, you have a zillion anonymous functions, anonymous objects, little option for the normal debugging practices to work.
In order to debug applications, had to divide down to small chunks.
Isn't yet a set of best practices for optimum code organization practices.
Node is great when you want to just lay down code and see where you can go. The features of other platforms like static typing that supposedly helps developer code safely, this isn't useful while you're in the exploration phase, but is more useful in later phases where it's in maintenance mode.
Because Node lacks debuggability features - forces the developer to rely on unit and function tests more strongly than they would in other systems.
One thing we might be immature on in Node is the best practices and tools for scaling Node to 10's of thousands of servers.
Because it's so easy to write a proxy server in Node, it lets you ignore for example using Squid or Traffic Server as the caching proxy. Instead you write your own caching server in Node. This means the whole project could be living in one code base, built using one toolset, instead of having dependencies on external systems or languages.
Using frameworks like Express rather than write your own?
Express is great. At Yahoo they started to use Express but then went in a different direction to implement their own framework, Mojito, that will be open sourced in a couple weeks. Issue from Yahoo is that Express and other Node tools are more like a framework to develop a webserver, than providing the webserver for you. With Express and other Node things the app developer in some ways has to go all the way back to the metal of understanding the HTTP protocol, where in other frameworks they do not.
Should the developers have to grok HTTP?
What about in the near future when SPDY starts supplanting HTTP? That is, what if the protocol layer changes out from HTTP 1.1 to something else? If your code is tied to HTTP 1.1 it'll be harder to shift to a newer protocol. It would be better to abstract the protocol away a bit.