February 10, 2020
After years of building applications for the web with Javascript, I’m now jumping into the world of Ruby on Rails. If you’ve never built a web application, I’m sure this doesn’t mean much to you. You might even have no idea at all, what I’m talking about. And to be fair, sometimes that same feelings creeps into my soul as well.
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?
If you keep it simple you only need one thing. One HTML-file with some Javascript code. If you upload that file to the internet, you have created a web application.
The HTML is to structure your page. You can use CSS to style your page. And Javascript is going to bring you interactivity. The thing that turns a static website into a real application.
I can’t teach you Javascript in this one article. But I can tell you a bit about how it all works on a high level. With Javascript, like most programming languages, you can tell the computer to do a thing when something happens.
So if the computer, or actually browser in the case of web applications, notices that a user clicks on a button, with Javascript you can then decide that a big orange circle should appear on the screen. Likewise, you could decide that if a user clicked the button five times, a little alert should appear on the screen to calm the user down.
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.
A web application that thus wants to remember your name and amount of clicks across computers and without risk of deletion, needs a different solution. Unfortunately that means just an HTML-document with a bit of Javascript isn’t going to suffice anymore.
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.
Back to our HTML-file that still shows our button. We need to connect it to our server, so the server can run our little logic and bouncing program. Javascript is still the answer. It allows us to make contact with our server and send and receive information.
When a couple of days later we open the application again on our friend’s tablet, we just need to sign in, and tell our server who we are. In response the server tells the database to get our information, and then relays it back to our HTML-file, who with the help of a bit of Javascript can show our number of clicks.
It’s the basics of how web applications work.