let’s talk about building blocks. Not just any building blocks, but the things which I personally consider to be the building blocks of modern software.
- Infrastructure
- Server side code
- Client side code
- And the bits that allow them all to communicate.
So, what do I mean by infrastructure?
Imagine for a moment, you are entering a room in a building that on the outside is no different from any other office building. But as soon as you cross the threshold you know this is a different world. Metal shelves of technical “stuff” line the room, like a library, but instead of the comforting quiet of books, you are surrounded by the quiet roar of thousands of fans. Narrow corridors of blinking lights light something out of a science fiction (or horror) movie. Only rather than having those ridiculous panels which click on one after another, the room is lit by standard office type downlights. It is freezing cold here by the door, but you know that near the shelves it will be another story.
Most of you already know what I am describing. Some of you have worked in places like this, managing the hardware that supports so much of what we use daily. This is a server room. Depending on the size of the room, and the number of shelves and units there could be hundreds, thousands, or millions of different bits of software running in here. I would say this is the most basic level of the building blocks. From the servers each with different CPUs, GPUs, Specialised Units, SSDs, HDDs, RAM, Network cards, etc, to the routers and cables connecting them all together. We don’t all have our own tiny server rooms anymore, instead we give in to the economies of scale, and we build castles in the air (sorry, I mean we build in the cloud).
With that comes a level of abstraction – we have software to manage the hardware that we need to run our actual software. That’s the kind of stuff I end up working on. We have these containers (thanks docker) which make the environment the code is running on always look the same, regardless of whether it is on a Windows Desktop, a MacBook, or the production server. We can collaborate more easily because of that, and in many ways the maintenance of the system is easier, because when the hardware inevitably fails we just pick up the container and put it on another server. No one even needs to know there was a hardware failure. If we do it right, obviously.
The second building block, which ties super closely the the third, is the server side software. Some people might even say some of what I call software is basically infrastructure, and I’ll leave you to argue with the data scientists about whether a database is infrastructure or software, but to me it is software. There is a piece of specialised software, in which I can define certain structures, and my data will be stored according to the rules defined in software. This, along with the bits of code which wrangle the data and make decisions about authorisation and authentication are what I would call server side, or backend code.
Running happily on the server you have these functions which when given a specific input, do a bit of logic, calculation, or other algorithmic magic, and spit out a hopefully deterministic result. And when I say hopefully deterministic, I really do mean hopefully. There are some people who work with probabilistic algorithms, and writing tests for those is a bit of a nightmare. I have heard it said “there are lies, damned lies, and statistics.” I’m just the right level of uneducated to agree with that. Nevertheless, this is the stuff which I usually call “business logic”. It is the stuff which is unique to your business. Unlike the bits of code which handle the encryption or the bits of code which tell the database how to do its job.
I mentioned that this ties in really tightly with the client side code. So, why do I say that? Because the client is where the user interacts with the system. Nowadays the most common client is a website or web application. Sometimes it is a desktop app, or a mobile app. And in our world, frequently a command line interface. The client handles some basic rules of how the system accepts inputs and handles outputs. I am not a fan of writing user interfaces that look pretty, mostly because digital design software infuriates me because my brain is not wired the way it expects, but I do have to interact with it nevertheless.
Not all of the code which runs on the client side is a critical building block, but without some form of it users cannot provide inputs for the business logic running on the server side. So in that way, the user interface is one of the fundamental building blocks of modern software. It isn’t all just “make this look pretty” although there is a lot of that involved. It is also validation, tracking what you did so you don’t have to do it again, reloading data from the server when something changes. It is signing you out when your session expires, so that you have to go ahead and sign in again.
Block four is not so much of a building block as it is the string holding all the pieces together. Communication protocols. If infrastructure, server side code, and client side code are multitudes of different sizes and shapes of Lego pieces, then the commands which link them together over the network are the axels and elastic bands which take your random collection of pieces and turn them into a fully functioning trebuchet.
The most common thing we use for this is APIs. Application Programming Interfaces. Basically we define the shape of input we will accept and the shape of the output we will return, and promise that we won’t change that shape without first telling you or at least performing a major version update. They come in a number of different flavours, most commonly REST, but there is an upswing in the use of GraphQL that I am seeing. Some people have valid reasons for using gRPC and protoBuf, but as an industry we have mostly agreed to give up on SOAP. This might be why remote teams are doing so well, actually; and no, you don’t need to know what all those different protocols are, I really just wanted to make a soap joke.
If you’re a deep backend person or platform engineer, and you use Kubernetes, we can argue about how they have misused the term API just to confuse matters further. But in essence, these are the connective tissue in our little Lego model. The web-app uses HTTP and REST requests to the server. The server does some processing, and depending where the database software is running, might make some specially formulated network requests to that. The the server sends a response over the HTTP connection back to the client which formats it into something readable, and we are all happy.
So, there we have it. Pippa’s four building blocks of modern software, at lightning speed, and with about as much substance as a lightning strike.
Pippa Hillebrand 