A simple introduction to the language of coding.
Photo by Stanley Dai
Think of coding not as a skill, but as a language. This series will explain some key words relevant to coding, while helping you get a better sense of what happens behind the scenes as you interact with websites and apps.
The goal of this series is not to teach you how to code, but to teach you the language of coding.
My belief is everyone should be able to understand and speak the language, even if they don’t end up coding. Whether you work in product, sales, marketing, operations, or customer support, this post is for anyone beginning to code who would like to learn more.
Unfamiliar tech jargon is a common hurdle for beginners when reading technical posts. Big technical words, like legal terms, can be intimidating if you don’t know them. Any intimidating terms which are defined below in the glossary will be followed by an asterisk(*).
One of the most essential actions, which everyone has taken at some point, is creating an account using your email and password. Today, I’d like to walk you through what’s really happening behind the scenes with the typical email and password sign-up. Let’s explore!
For creating an account:
There is a series of actions that involve the frontend* interacting with the backend*.
Step 1: Checking you don’t already exist
When you click the sign-up button after entering an email and password, the information you entered is first sent as a request to the server* to verify whether your account exists. If it does, then you are redirected to log in, rather than sign up.
Step 2: Storing your account details securely
If the server* confirms that you aren’t already in the system, it’s ready to create a new account! On a higher level, what the system needs to do is store in the database* that your email and password will let you into your account.
However, there is a big issue — Passwords cannot be stored in the system the way you type them for security reasons — if someone gets access to them, they can pretend to be you. They have to be modified before being stored. You may have entered a password, say “drgkjlDKHKJ123”, but it will be stored completely differently in the database. Remember the Equifax data breach? That happened because sensitive information was not stored securely.
The modification process looks like this:
First, something called a salt is generated, which is nothing but a random string that is usually mixed into your password for added security. Then, that entire string is taken and put through an algorithm. This process is called hashing, and the algorithm is called a hashing algorithm. Say you and your friend both have the same password. Adding a salt before the hashing process will make sure that the hashed passwords are completely different. The hashed password, the salt, and your email are then stored securely in the database*.
One thing to note is that once your password is hashed, it is an irreversible process, so you can’t get it back in the original form. If you ever go through a “forgot my password” flow on a website and you actually get your original password in an email you now know it’s stored insecurely because hashing is an irreversible process.
Step 3: Creating sessions and cookies
Now the server is ready to signal to the frontend that you are ready to log in. But first, it has to take one more step. The backend must create a session and then send a token (a piece of information that can be used instead of a username or a password to tell the system it is actually you). The token is then stored on your browser in something called a cookie. Whenever you visit any page on that website and are logged in, that information will be used to verify your identity. Isn’t that cool? A session also has an expiration. So, for instance, if I were to visit Groupon for the first time, a session would be created for, say, 30 days. Within those 30 days, Groupon would remember my information, after which it would get deleted and I would have to log in again.
Something to note here is that cookies and sessions are created independently of a login process. For example, if you visit a grocery website and add things to your basket without logging in or if you leave the website and come back after certain amount of time, you will still be able to see them there.
One note here is this is what should happen ideally, but sometimes websites do not follow it and that’s when your information is at risk of being compromised.
For login:
So, now let’s explore the action of logging into the system.
You enter your email and password, but this time the server must verify that the email exists. If it doesn’t, then you are redirected to create an account as described above. If it does, the password you entered at this point goes through the above steps of modification and is then compared to what we have stored in the database*. If it’s the same, you are authenticated. If not, you are taken back to the login page again and prompted with a “Forgot your password?” link in addition to the same login form.
For remembering logins:
If you look at most web forms*, you will see a “Remember my password on this site” checkbox. If you check that, it will not need you to enter any information to be logged in next time.
Here’s what happens: Remember how your browser now has a cookie* stored on it? The next time you visit the website, the server will actually request that cookie* on the browser so it can identify you and let you in.
Glossary of terms used:
- Frontend:
Let’s take Google — the frontend of the Google homepage is literally what you see and interact with. When you enter a search into Google, it’s all happening on the frontend. The frontend is usually connected to a backend* in any app or website.
Example usage:
For a site involving very fancy interactions with the user — “The front end is hard to build.”
“The frontend of this website isn’t responsive when I open it on my ipad — when I scroll, it jumps all over the place.”
2. Backend:
The backend works behind the scenes to make the right things happen when you engage with the application. The frontend* communicates with the backend to create meaningful interactions between the user and the interface. If you typed a search in Google (the front end) without a backend, the actual website wouldn’t do anything meaningful. The backend is what finds the search results.
Think of it like the front end receives the intent of what you want to do and then requests a system at the back to give the applicable information, which is the backend.
Example usage:
“I want an application that will analyze all of your Facebook wall posts. How long do you think this backend will take to build?”
“The website is not processing my payment request. It seems there is a backend issue”.
3. Form:
Forms are any place on the web or on an app where you enter information. For example, forms are where you enter your shipping information when you buy something or your username and email when you create an account. Form validation, as the name suggests, is the process of checking whether what you have entered is correct.
Example usage:
“The web form is broken. Nothing happens when I click the submit button.”
“I must be entering the wrong password. I keep getting a form validation error.”
4. Client:
In real life, a client is someone who pays for some services. Technically, when we say client, it’s what you are using to make a request in order to connect to a server*. So, if you are on your computer and you are typing a website address from your browser, the browser is the client — it’s what makes the request for the information.
Example usage:
“Smartphones brought web clients to everyone’s pockets — One of the reasons they’re a game-changer.”
“What’s the best email client?” — This translates to what do you use to send email. (mac’s email application or outlook, etc).
5. Server:
The server is a type of software on a machine that can respond to requests. Even though the word sounds really intimidating, that’s all it does. So, for example, when you type Google.com on your browser, the browser knows to make a request to _Google’_s server and _Google’_s server knows how to respond to such a request, which is to give you the Google homepage.
One thing to note here: Since a server is software that knows how to respond to requests, any computer can be a server or a client or even both. You can write code so that you have a local server running on your computer and also have a browser installed making requests at the same time, which acts as the client. Isn’t that interesting?
What requests can you make? It can be anything from requesting the homepage when you type Google.com to requesting information when you google something. So, when I type Google.com, I expect the homepage of Google to show up. When I type some information in Google, I request search results to show up. Those are different types of requests which are being made to the Google server. A request is followed by a response, so you will usually see these words being used with each other.
Example usage:
“Can you imagine how many requests _Amazon’_s servers get on Cyber Monday?”
“The server is down.” — The most common one you will hear when the website isn’t giving you what you want :)
“The server can’t handle the traffic.” — Usually because a lot of people are making requests.
6. Database:
The database is where websites or apps store your information they want to retrieve later on. For instance, when you return to a website and you enter your information like your username and password, it has to be stored somewhere because you expect the user to enter it again. That store is the database — it’s a collection of data stored in a structured way which can be retrieved later.
There are many types of databases — Some you may have heard of like SQL, Postgres, and Mongo.
Example usage:
“The librarian looked into the database and told me the book is available.”
7. Cookies:
Most websites will store pieces of information on your browser called cookies that let the server know it’s you when you visit. If it weren’t for cookies, there would be no way of identifying you when you visit a site, also known as a ‘stateless transaction.’
You can try that — Go to your browser settings and clear the cookies. Then, visit a website you frequent a lot and they will ask you to login.
Example usage:
“I need to clear the cookies in my cache.”
“Can you try clearing your cookies and then refreshing?” — Sometimes when you see bugs on a page you may get that request from your engineers.
8. Session:
When you visit a website for the first time and create an account, a session is created. A session is simply a duration of time that a given website will recognize you, which varies depending on the site. So, for example, when you add something to a shopping cart online and you leave the website, you’ll still find it in your online basket when you come back, even if you haven’t created an account. It won’t be there forever though. If you come back in two months, you will probably find it empty because the session has expired. When a session is created, it gets an ID and that is sent to your browser which stores it as a cookie to identify it’s you.
Example usage:
“I am glad Instacart preserved my session and I still have all the items in my shopping cart.”
Hope you enjoyed this post and that it has helped make you more comfortable with the terms. The reason why you need to get comfortable with the language is because software is increasingly impacting every aspect of our lives and these terms will become more common. If you are working in technology, it’s even more important to know the language well — It helps not only with your communication with engineers but with gaining a deeper understanding of what’s going on.
In the next post, we will introduce some new terms and even reuse some of these as well. Please comment and let me know what topics you would like to see me cover in the future. And, as always, please like and share the article!
Thanks to Brooke, Graham and Erik for reading the drafts before publishing!