Tuesday, October 16, 2012

Lean Tornado

Tornado is a lean web framework. Vague, yes. Allow me to explain. Tornado doesn't get in the way of the developer trying to build an application by imposing too many conventional constraints. Each web framework that gets put out there in the community, be it Python or otherwise, adopts its own conventions. Usually from inception onward. Conventions establish a standard set of practices, patterns — call them what you will — they're essentially rules that explain how to best utilize the framework because some other developer had done it that way before. By and large, this approach works. Develop a toolkit that has a vast collection of reusable components and an instruction manual on how to use them in isolation as well as building new, larger components from smaller ones. By following these conventions on how to get the most reuse out of these parts, the developer really only needs to tap their previous project experience with similar code and the rest should just fall into place — assuming they've read all the documentation and learn how to follow the patterns of the framework very quickly.

If you've done any developer hiring lately, you're probably thinking about how important it is that the candidate be able to learn and adapt to new technology quickly. There is a high probability that your project will use something new — a new framework — that best suits the problem at hand. At the very least, you'll need the skill to sift through the framework code, examples, documentation, to perform an evaluation. Even if you don't call these out in the job requirements — saying "fast learner" is meaningless — you're probably looking for these traits as you observe the new hires in action. This is how I came to the conclusion that Tornado really does stay out of your way when trying to accomplish goals in a web application that doesn't require a robust set of web components — just a solid foundation with which to build web handlers.

The antagonist here was Django. I'll qualify that last statement with: I love Django and use it frequently to solve a variety of challenges. But who says I can't use it to highlight strengths of other web frameworks? A key strength behind Django is the fact that it comes with "batteries included", meaning all the components you would need to construct a modest web application that scales reasonably well with little to no modification of the suggested deployment methods. That covers 95% of applications, at least in their initial state — before their requirements evolve as a side-effect of real-world deployment. The challenge is figuring out what you don't need. A lot of the more sophisticated web applications out there don't actually touch on every single feature of the framework they're utilizing. Instead, the development team has the job of picking the framework that best serves a handful of capabilities, while minimizing the "left over" bits. This evaluation task is important, especially in gauging how well developers can identify dead-weight and strong assets of frameworks. It in turn let me see the strength in the developers who informed me that Tornado was the best bet, and that Django was too restrictive should we decide to follow their best practices and patterns.

Switching gears slightly and thinking about what features we do want included in the framework — regardless of what we're trying to build with it. The end product of any framework will ultimately share the same generalization in that it's a web application. It resides on a server which delivers content to the client, and accepts subsequent requests from the client. Those things have to work well as they're universal. Another quality to look for in a web application framework is getting off the ground quickly. A developer with even a little experience in the general domain of web applications should be able to pick up framework and start targeting it for development with little issue or learning curve. I find that this quality is inherent in most Python web application frameworks, some more so than others. Django excels at providing the developer with an intuitive starting point and there is no learning curve to speak of. Tornado is similar and even shares many of the concepts found in Django. Where Torndao differs is in the maintenance of that knowledge. We can get off the ground quickly with Tornado and from that point dive into the details — a process that doesn't take long because there isn't much to it. In contrast, we can certainly get off the ground quickly with Django — but it takes much longer to become any kind of expert simply due to the wealth of knowledge to dig through.

Perhaps a more fundamental limitation exists with regard to how web application frameworks permit developers to compose the architecture of the system itself. This challenge exists to a degree with all frameworks, out of necessity, since they're trying to compose part of the architecture for us. They give us the means by which we map incoming HTTP requests to handler functions. They give us utilities that let us tweak the internals of the framework to a degree. They might even provide us with an ORM, or front end tools that assist with content ultimately delivered to the client. It's these components, and the conventions prescribed to developers to best use them that can block our application's architecture in significant ways. The less moving parts there are, the less convention there is to follow, and the more freedom we have within the confines of the framework itself. Perhaps these boundaries are a good thing. You'll never know unless you look at the positive side of each pattern from the perspective of the applications architecture.

How does Tornado achieve this lean quality? It has less components for developers using it, of course, but how can it be a successful tool if it is missing features? The way I see it is that Tornado does really well at offering a robust request handling engine. It has lots of flexible features within this context — asynchronous handlers for background processing as an example. Where it trims the fat is in the components that reside closer to the application layer. Things that might interfere with the way the developer might want to implement a particular task are lean. They only provide the essential tools that we may or may not use. I think that plays well into the development mindset — if you under-emphasize optional components, developers are more apt to focus on the essential stuff, like IO loops.