A breakdown of my learnings on WSGI: Part 1

So I’ve been trying to read quality Python code recently after reading comments made by TJ Holowaychuk in regards to how he improved so fast as a developer. As a result, I found my way to Flask (a “framework” I already work with), which then put me onto Requests, and then finally, Werkzeug.

These were all well regarded and recommended as quality repositories to read if you are interested in improving your code.

Fantastic, I thought; a way to kill two birds with one stone. I can fix my (atrocious) understanding of web architecture and read a proverbial shit-tonne of good quality Python code in the process.

Little did I know how far the rabbit hole would go.

I have enjoyed learning about how the web works according to Python. If you enjoy this sort of post, please leave a comment and I will do my best to write more of them as I venture my way through the annals of tech.

So I started off not really understanding much about anything, I had a feeling that I “knew what I didn’t know”, but turns out I didn’t know enough… About either.

To start off, a brief intro. Werkzeug is a library implementation of the WSGI specification ideated in PEP333 back in 2003. It was built by Armin Ronacher and Co, the same crew behind Pallets, who run the Flask project and a variety of other things. It is used heavily in Flask. It is fairly agnostic in that it is a library, not a framework or anything as opinionated, it is built with the intention of having people use bits and pieces of it in their own WSGI implementations, without having to use the whole thing.

WSGI is a specification, it is not a protocol or implementation. It was released as an abstraction layer to think of good ways to allow Applications and Web Servers do their own thing, enabling bits and pieces to be hot swapped with little or no fuss. Back when WSGI was released, the web world according to Python was very opinionated in the way that by using a framework, you tied yourself into an entire way to do something. There was no “might use Flask here and then Nginx there”, it was the way of the framework, and that obviously bothered enough people in the Python community (they had external inspiration as other languages had solved this issue already) that they decided to set out a way to fix it.

The reason I started on Werkzeug was simple, I wanted to have a better development understanding of the web and Flask, and Werkzeug is the backbone of Flask’s clean as hell 6 line server. So if I was going to understand how Flask worked, Werkzeug would be where to start.

I started off with the Werkzeug tutorial (http://werkzeug.pocoo.org/docs/0.12/tutorial/), first by reading, then after that, by writing it out. After writing it out, I then realised again that I stil didn’t have much of an idea what was happening. So I decided to start breaking out some of the tools I had been learning.

  • Snakefood — A way of mapping module dependencies in code.
  • gprof2dot — A way of creating graphviz images from dot files created from the output of a code profiler.
  • cProfile — A way of performing dynamic analysis on code as it runs, check the memory used, that sort of stuff.

My intention here was to uncover some of the underlying mechanisms behind the code I was writing/copying. Bare in mind that I am no expert of these tools, and my use of them could be totally incorrect, but it was an interesting experiment that only fanned the fire of interest in this domain.

After running the set of tools and then killing the process after 5 Seconds:
Left: One Refresh on the localhost. Right: After letting it running for 5 seconds, with no interaction.

So to clarify the pictures, these are effectively graphs of how the program operates internally, the classes it calls, the execution paths they take. And judging by the largest one, their last operation before their process was killed.

For me, this blew me away, I’d been plugging away trying to get more code visualisation tools running for a while (Hey, I’m a junior), and the way the graphs changed depending on how I interacted with the program was intriguing. So I started digging deeper.

I’ll leave this one here. I am getting the feeling that from my notes, I’d rather keep these short and sweet with decent info, than a long monologue that I just want to mash out and post.