Part 1: Understanding how software works for non-technical people
This article will break down the high-level overview of how software works in today’s world.
March 5, 2017
This article will break down the high-level overview of how software works in today’s world — and what all those terms mean that you probably often hear in conversations. This is geared for a non-technical crowd (non-technical in the sense that you know how to use technology, but don’t know how to program/make technology) — so if you are a software engineer reading this please don’t feel the need to correct every little detail.
The hot trend it software today is web-based applications. This means applications you access directly in your web browser (like Facebook) as opposed to an icon on your computer (like Microsoft Word).
Web-site vs Web-application
To begin, it’s important to know the difference between a web-site and a web-application. A web-site simply presents static information and doesn’t allow for much user interaction. Think of a local business’s website. They are there to give you their hours, talk about what they do, and maybe give you contact information. There isn’t much interaction from your end. You are accessing the site, digesting the information, and then leaving.
Now a web-application, this is where the fun happens. A web-application involves various layers and user-interaction. Examples are Facebook, Twitter, eBay, and Gmail. When you access these, it involves logging in/out, processing payments, writing on your friends walls, checking your email, etc. i.e lots of interaction from your end. An easy way to think about it is that a web-site shows the same page to everyone. If anyone visits a local business’s website it’s going to look exactly the same for everyone. However a web-application, will be unique to each user. If you log into Facebook it will be vastly different than if your friend logs into Facebook. You will see your posts, your news feed, your photos; and they will see all of theirs. This lets us know that Facebook is serving a unique page to every single user who logs in to use the platform. Since they have over a billion users — this means that Facebook needs to be able to serve over a billion different versions of Facebook!
Now that you can see the difference between a web-site (static non-changing information) and a web-application, we can dive into the difference of two terms you probably often here around tech friends: front-end and back-end. In short, here are the differences between the two:
Front-end: This is the code that drives everything that you can physically see on your screen. For example do you see a large blue button that changes color when you hover over it? That is front-end code saying “make this button blue, make it large, and when the user hovers, change the color”. This is front-end code insofar that you are able to actually see what is happening. A reason you are able to see this is that front-end code is actually executed (or run) directly in your own web-browser! This is a reason why it’s also often referred to as 'client side' code.
Back-end: This is everything in the background you cannot see. Think of it as an iceberg. The front-end is the tip, and the back-end is the beast below the surface that contains 90% of the mass. When you enter in your username and password on Facebook and click ‘login’ there is A LOT going on in the background that you cannot see. To yourself it simply looks like “login, wait a second, and boom I’m in”. During that second of waiting though, all the back-end code is doing the heavy lifting. This includes security measures such as authenticating your username and password and making sure there’s nothing ‘suspicious’ about your login. It also includes ensuring the correct user gets the correct account. Imagine if you tried to log into Facebook but instead of your account, you were logged into someone else’s. This would be a big problem! The back-end code ensures everything runs smoothly and accurately.
A good metaphor for these two is to imagine a car. The front-end code says “it’s blue, it has 4 doors, and a back windshield wiper”. Remember that the front-end code is what we can physically ‘see’. The back-end code, is the part below the iceberg that does the heavy lifting. So here this would be the engine. The backend code is the real driving force behind any web-application. Making a car frame isn’t that hard, making a functional car engine though…
Knowing these differences, we can also now say that web-sites contain mostly front-end code since there isn’t much going on behind the scenes. You go to the local business’s website and what you see is what you get (and the same for everyone). Because you can physically see everything on the page, that is simply front-end code.
- HTML is the noun. This language tells us what is on the page. It could be text, images, videos, or whatever we want. Using our car example, HTML says “There is a car”
- CSS is the adjective. This describes and styles the noun HTML gave us. It will make text blue, make an image larger, and make the background of the page be red. For the car, HTML says “there is a car” and CSS says “the car is blue”
After the front-end comes the back-end. This is where web-applications enter the picture.
The purpose of the back-end is to serve and ‘change’ the front end. For example, when you log onto Facebook you are presented with your account. Once logged in you see your own pictures and friends. Since you can ‘see’ the pictures this means it’s front-end code. However, the important piece is how that code got there. The back-end code did the heavy lifting and said “ok this is Mike logging in. I’m going to send the front-end code that properly shows him his own account and not that of someone else”. Effectively, the back-end code is there to ‘deliver’ the code to the front-end that you can see from your end.
Lastly, there is the database. A database is where all your information is stored. Your Facebook pictures, posts, friends, etc are all stored in a database. The reason back-end code exists is because of databases. Databases are extremely good and effective at storing large amounts of information (imagine how many Facebook photos there are in the world), so they are necessary to have. However, front-end code cannot talk to the database. Back-end code has the advantage of being able to talk to both the database AND the front-end. So, when you log into Facebook what happens is that: The back-end code verifies your account information, it retrieves your data from the database (photos, posts, etc), it then serves the code to the front-end that displays the information from the database to your screen!
When you hear developers talk about ‘the stack’ this is what they are referring to. Since there is a hierarchy of the pieces of the app, it is eloquently called a ‘stack’. The stack is the front-end code, back-end code, and the database. The beauty of web development is that there are many different options for the programming languages you can use. Some are better for some tasks, others are better for different tasks. You will often see or hear developers go red in the face defending their choice of language. However there’s no clear answer except for a case by case basis. The question “which programming language is better?” is like asking “which car is better?” with zero context. Unless you know the purpose of the car (road trip? drag race?), the details (how many passengers are needed?), and the rest of relevant data (who’s paying for it? how long do I need it for?) — then the question is pointless.
One last term you will hear often is ‘framework’
Frameworks are what makes modern web-development so fun and fast. They also significantly lower the learning curve for beginners who are trying to build something. More or less a framework is a bunch of pre written code that gives you a foundation. It takes care of a lot of the nitty gritty details that go into building a web-application.
Imagine if you had to build a car. If you don’t use a framework you have to build everything from scratch. The frame, tires, engine, mirrors, all of it. Now this will give you a much better understanding of how everything works behind the scenes and will let you fix any issues that come up in the future pretty quickly. However it will take a lot of time as it’s a steep learning curve.
Now if you use a framework, imagine if you had to build a car — but you can start with a pre-built frame and tires. This significantly lowers the learning curve and will let you get a working car up and running much faster. The downside here is that since you didn’t build everything from scratch — you may not have a deep understanding of the systems that keep the car running smoothly. If there is a problem down the line, there’s a higher chance you will need to reach out to someone else to fix the issue. It’s generally accepted that all web-applications should use a framework for the speed of development, but it’s on the developer to take time and really research what’s going on under the hood to get a better understanding of the foundation. As long as the developer is serious about learning the underlying concepts, you will get the best of both worlds.