The Language Project
The Python language was still hatching from its egg, when the World Wide Web (WWW or W3) started the revolution. The LAMP stack would not be ready right away, but when it was, Python was really lucky to be a P language.
The LAMP stack died with Ruby, but only after showing the way: from now one, we’d have stacks, lots and lots of them.
LAMP: Linux Apache MySQL and some language beginning with P.
Originally, that meant either PHP or Perl, but then Python came along. Ruby, based on Perl, wasn’t a P language (didn’t start with P), but was good enough to join the club at the language level.
MySQL had more competition from Postgres and eventually went over to the dark side.
What about Apache?
Both Linux and Apache were strong enough to serve as nuclei for Foundations, meaning umbrellas under which new projects could incubate. Many of Apache Foundation’s spawn became famous.
The Linux Foundation was no slouch either.
Many could tell the history of either better than I. My purpose is more just to spell out the jargon, so I can introduce some more jargon.
Remember all this software was free for the using and the economy helped itself. The ethic of giving back continues.
However many who write about the economy do not have enough technical writing skills to factor in the difference open source has made. To this day, it’s hard to find literate economists.
You have a lot of people who talk financial instruments, but even they don’t have FinTech savvy. Cryptography is where it’s at.
So you probably get the idea. The LAMP stack was how big companies learned to get skin in the game where the World Wide Web was concerned, in the coming decades to become the core engine of the economy.
Google went down for an hour the other day, and institutions around the globe went into a standstill. Something about the authentication service. Suddenly no one was authentic. You can’t make this stuff up.
The economy was transformed by W3. The transformation isn’t over.
Apache is pretty interesting. I talked to one of the principals about whether the Foundation ever gave some thought to taking up the cause of the Apache people, what with that feather and all.
The already good vibe could be made better. I seemed to think this was a terrible idea, but probably only because it hadn’t occurred to him.
So now we get to the heart of my story (you were wondering if it had a heart, I can tell): Apache is and was the heavy lifting workhorse among web servers.
Sure, MySQL was happy to run SQL and return datasets, but the P language was pulling those strings and sending the retrieved data over TCP / IP to the client browser. To do that, it needed middleware, an application. That’s what the P language provided.
But how would Apache, the web server, run the applications exactly?
Well, in the P language called Python, the answer was WSGI. We can find out what those letters stand for shortly, but think of Apache, the webserver in the LAMP stack, getting hit with all these HTTP and later HTTPS requests (S for Security, think cryptography) and the information from those requests magically bubbling up inside a Python program, as attributes of definite objects.
As a coder, you could treat an HTTP request as an object, query the database according to said object’s desires, and formulate an HTTP response object.
WSGI is the layer of magic the Python framework programmer doesn’t have to worry about. Just use you Django and your Flask, your Web2py, and you’re fine.
What happened next?
The HTTP / HTTPS protocol was working nicely, and Web 2.0 had occurred. But now was the time to get more asynchronous and write programs in terms of event loops.
Older code would tend to “block” meaning sit around doing nothing, waiting for something beyond its control, to happen. Having busy computer setting idle when it could be getting on with other business is too intolerable, has been from the beginning, and is what time-sharing is all about.
The languages themselves would have to acquire a greater ability to juggle tasks. After a chapter of using what were called “callbacks” (“I’ll call you back when I’m ready”) the language developers morphed the languages themselves, to keep them more supple. In the case of Python, that meant two new keywords: async and await.
Think of asking Python to cook some eggs, which involves handing off the eggs to some cooker process that runs elsewhere on the network. I don’t need to know the details. Some HTTP request got the order going.
However, our parent process, the one submitting the request, is not about to stand idle and just watch the pot boil. On the contrary, the parent process, really the only process, is free to accomplish task after task, every so often checking the event loop, a kind of merry-go-round.
As the merry-go-around turns, so do the various Python tasks mature, meaning they get to the end of whatever we were waiting to have happen (cook some eggs wasn’t it?). The timer goes “Ding!” and the parent picks up the ball and moves the action forward, until maybe another request gets sent off.
It’s not multi-threading, which is also a design pattern Python implements, because from the point of view of the parent, only one thing is happening at once, but with frequent opportunities to multitask in any case.
Tasks have learned how to yield, i.e. to not block. That was the main thing. First came the keyword yield and the idea of a Python generator, then came these async and await type functions, the kind you could leave waiting and check back with later.
We’re getting to the end of my story.
Remember WSGI? Web Server Gateway Interface.
That was geared around HTTP / HTTPS, with a simple call and response, request and receive model.
However as gamers have always known, you need multiple channels all going at once to make things really action packed, and keeping channels open means not wasting time handshaking over and over.
Enter Websockets. Enter juggling more balls.
WSGI just wasn’t designed for so much concurrency and so ASGI was born. The Django Channels project spearheaded R&D. However Django is a big heavy framework that doesn’t turn on a dime.
So at this point in history, some of the smaller more agile Flask-like frameworks have jumped into the fray.
We have FastAPI running atop uvicorn (not a typo). Python’s new async / await syntax is supported. Performance is speeding up again.
Python Nation is not being left behind in the dust, as we enter the Age of Concurrency (more fluid).
That’s my story for today.