February 10, 2020
The thing is, when you start doing, you often stop thinking. You just follow the patterns you were taught and keep it moving. By now forcing myself to learn different patterns, I can finally take some time to look around at what I’m doing. Or so is my line of thinking.
I trust you’ve used software before. You’re reading this article on software. Probably in your browser, an application on your computer or phone. Some applications are made specifically to work inside your browser. Those are web apps.
How do you make such a thing?
And there we already reached a bit of a problem. Because how did the browser know that this was the fifth time the user clicked on the button?
You see, the browser itself isn’t necessarily going to keep track of how much a user did a thing. You’re going to need to save that data somewhere and pull it up when you need it. Similarly, if a user has given their name, you would want to still remember that name when the user opens up the application again.
Data you want to use to decide behaviour, you have to store somewhere.
There are a few options to do just that. A completely free and simple option is to have that user store that data themselves on their own computer. So each time the user clicks the button, the new amount of clicks is stored on that user’s computer. We can do that without the user knowing it. It’s a thing in the browser called local storage.
If you’ve ever wondered how your social applications know that you’re still signed in, well, chances are they saved a bit of information in your local storage. So if you ever clear out your browser, chances are you are no longer signed into your account.
And there also resides the downside of using local storage to save information about the amount of clicks. The user could delete the data whenever they want. And then we haven’t even talked about the fact that it’s called local storage. So if your user would have used a different browser or a different computer, you would have no way to access the data.
We need a database and a server as well.
The database shouldn’t come as a surprise after the last couple of paragraphs. We are in dire need of a place to store stuff that is not local and cannot be messed around with by the user itself. And while a database is most certainly a non-local thing, meaning it doesn’t live on the user’s computer, but instead is hosted somewhere neutral where it can be accessed from anywhere, it can still be accessed by anyone who knows where it is.
So a malicious user might still delete or amount of clicks or change our name to something non-flattering. In fact, that user might fill our database with their personal coming-of-age novel (yikes!).
Needless to say, we need a way to control what goes into the database, and who does it. We need a bouncer, some security, a gatekeeper. We need all of them. And unlike real life, for your database it is completely fine to hire way too many of them and have them be overly strict. Because when it comes to data, you have to be careful to the max.
Luckily we can setup a server which can perform those roles. It can validate if a new name is an actual name and not 100 random characters, it can identify who you are and whether you are allowed to use the app, and it can seal off any access to the database that we don’t want.
We just need to write a program that lives on our server. Our virtual bouncer. Although, to be fair, our program is capable of much more than just bouncing. In fact, programs on servers often perform complex logic.
It’s the basics of how web applications work.