The infrastructure of an application is often a hidden world for users, but it is one of the most important layers. For the app I am building for my Talent Program Minor 'Apolloview', this is also the case. In this blog post, I will attempt to explain the basics of infrastructure engineering, a form of high-level development that is the first and most important step of building the back-end or server layer of an application.
If you’re not familiar with the project 'Apolloview,' I recommend reading my previous blog post, 'One small step for "Tooncultuur"' in which I go into the details of the Apolloview project.
You lost me at “server layer”
So time for a little explainer, because if everyone understood infrastructure engineering, I wouldn't have to create this blog post. An app usually has two sides
An app usually has two sides. The first side, the client side, is on your device. This is everything you see and touch: the user interface, the styling, and animations. It also handles all the functions that are specific to your phone, such as notifications and vibrations. You could think of the client side as the front of a restaurant: the menu, the tables, and the waiter who takes your order.
Then there is the second side: the server side. This is not stored on your phone but runs on powerful computers in a large data center. The server layer processes all the data the app needs and enables communication with other users. Think of this as the kitchen in our restaurant example. The waiter (the client layer) takes your order and sends it to the kitchen (the server layer). The server layer processes your order, gets the right ingredients (data) from the pantry, and prepares your dish. The finished result is then sent back to the waiter (the client layer) who serves it to you. The server layer, therefore, handles the complex work behind the scenes, ensuring you have a smooth user experience.
It’s not about the sketch, but the conversation about it
How do you start programming a server layer, do you start writing code in Go or Rust? Or do you sign up for AWS and acquire more debt than your student loans? or do you push a container to the cloud based on a gut feeling, hoping it stays healthy? All these answers are wrong. The right answer is grabbing a pen and paper.
Under the hood, all back-end code is really about one main thing: moving data from the server to the client, there and back again. So, start drawing all the places your data has to go to. This isn't about creating a perfect technical diagram, it's about building a simple, high-level map. Draw a box for each major action, like "User scans artifact code" or "Fetch artifact data," and use arrows to show how the data flows from one step to the next. Inside each box, write a simple description of the action in pseudo-code, no need to name a specific service or platform.
If you don’t have access to paper or enough space to draw, I can highly recommend Excalidraw. Excalidraw is an open-source whiteboard application that you can open in your browser, and it stores all data safely on your own device using browser storage. #not-sponsored
The process of paper prototyping forces you to think through the entire chain of events from a server's perspective, revealing dependencies and potential problems you might not have considered. It's in these initial sketches that you have the most important conversations, figuring out exactly what the data needs to do and where it needs to go before you ever write a single line of code.
An idiot admires complexity
In this modern day and age when you're building the "train line" of your app's infrastructure, the truth is that most of the "stations" are already built. While Amazon can be a controversial company, their cloud platform, AWS (Amazon Web Services), is undeniably awesome. They provide a pre-built service for nearly everything you could possibly need. Instead of building your own storage solution, you can use S3 to store files in the cloud. Rather than setting up a database server, you can use DynamoDB to store and retrieve your data with just a few lines of code. And for tasks that require a quick bit of processing, a service like AWS Lambda lets you run code without ever thinking about a server. Best of all, these services scale with your needs. The costs for a small-scale app can be near zero, so you only pay for what you use.
I hope this blog post gave you a little insight into my life for the past few weeks. Infrastructure engineering sounds complicated, but when you break something down into steps and use tools like Google and AI to learn without creating a black box, everything is possible to learn. If you're interested in this side of development, I would highly recommend learning to use Docker and a system programming language like Go or Rust (I prefer Go as it is simpler). When it comes to learning AWS, don’t try to learn everything at once. Focus on a few core services like S3 for storage and Lambda for serverless functions, and practice by building a small, simple project. The AWS Free Tier is a great way to experiment without worrying about costs.
An idiot admires complexity and a genious admires simplicity.
Terry Davis, creator of temple OS