Environment variables serve as a basis for software configuration management, providing a flexible way to manage application settings over different environments. These variables can encapsulate crucial information such as API keys, database credentials and other runtime configurations.

Developers can decouple sensitive information from their codebase by leveraging environment variables. Leveraging environment variables facilitates smoother deployment and ensures a higher level of security.

However, while environment variables offer numerous benefits, they also present challenges when accessed excessively and inconsistently.

Over-reliance on environment variables (primarily through direct access via process.env for NodeJS-based applications) can cause code coupling. Code coupling is when application logics are tightly bound to specific configuration values, making code maintenance and testing more complex.

How environment variables are overused?

While environment variables are necessary for managing configurations and crucial information, they can be misused or overused in a few ways:

• Dependency on external configurations: Relying heavily on environment variables can make your application less portable and more difficult to configure. For instance, if your application requires many environment variables to run correctly, these configurations will be difficult to maintain across different environments.
• Elusive application logic: When too much application logic is built within environment variables, code can become challenging to understand and maintain. Excessive use of environment variables can lead to more opaque code that is often difficult to debug and modify.
• Reduced readability: Overuse of process.env can make the code harder to read, especially if there are numerous references to environment variables scattered throughout the codebase. It's essential to balance using environment variables for configuration and keeping the codebase clean and understandable.

Another way it could be misused is by misapplying the convenience of calling ‘process.env’ in NodeJS.

If you need to write environment-specific code, you can check the value of NODE_ENV with process.env.NODE_ENV. Be aware that checking the value of any environment variable incurs a performance penalty, and so should be done sparingly. — expressjs.com

We can mitigate this misuse by creating a centralized configuration module/class that readily includes the needed environment variables. This is better compared to calling ‘process.env’ numerously.

MONGO_DB_URI=...
MONGO_DB_APPNAME=...
REDIS_URI=...
PSQL_DB_URI=...
MAIL_SERVICE_KEY=...

The centralized configuration module

//config.ts
import dotenv from "dotenv";
dotenv.config();
const config = {
 mongodb: {
  URI: process.env.MONGO_DB_URI || "mongodb://localhost:27017",
  APPNAME: process.env.MONGO_DB_URI || "...",
 },
 redis: {
   URI: process.env.REDIS_URI,
 }
 smtp: {
   ...
 }
}

This can be imported and accessed by other files within the project instead of having ‘process.env’ everywhere. This can also avoid misspelling the variable names.

Conclusion

In conclusion, environment variables are crucial for configuring and customizing applications across different environments. In Node.js, they are accessed conveniently through the process.env object.

It is crucial to handle environment variables securely, avoid exposing sensitive information, and maintain code readability and maintainability. By leveraging environment variables effectively, developers can build flexible and scalable applications.

Happy Coding 👩‍💻

Imagine you are browsing through an online store, scrolling through pages of products, only to realize there are hundreds if not thousands more items to explore. This could become overwhelming for a user, overloading and crashing the server from a developer's stance.

Presumably, the server is providing all the items in the database. Assuming the number of items is 10,000, that will be a million repetitions to 100 users.

Pagination

The ideal solution will be to provide a limited number of items and allow users to explore the dataset based on a few metadata, offering a structured approach to data retrieval. Pagination involves breaking large datasets into manageable chunks or pages. This method enhances a seamless navigation experience while optimizing resources and performance for the client and server.

Pagination, also known as paging, is the process of dividing a document into discrete pages, either electronic pages or printed pages. — Wikipedia

That is not everything about pagination. The description above is figuratively defining page-based pagination — a method of paging datasets —. As we assumed earlier, the number of items we have is 10,000. We could structure our items into pages. If we supply 25 items per page, then the number of pages available is 400. For some application that infrequently adds new items, this is reliable. But in the real-time system, where pages may not be reliable, we will have to consider other methods for pagination.

Pagination Metadata

These are often the valid query parameters attached to a request.

https://api.mymail.com/v0/users/:id/mails?page=20&size=50&category=important

Metadata:
page=20, size=50, category=important

These queries are used to explore the API; for instance, incrementing or decrementing the page value helps navigate from page to page.

Types of Pagination Methods

In the field of API pagination, there are several common types of pagination methods, each having its own use cases. Let us explore some of these types:

1. Offset-Based Pagination: This involves specifying the number of items to skip before retrieving results. This method is straightforward but has its trade-offs. For example, if a user is at page 3 with ten items per page, the API will skip the first 20 items — 2 pages * 10 items — and return the following 10 items. For large datasets, the server will process and skip a potentially large number of records, making this type of pagination inefficient.

2. Page-Based Pagination

Page-based pagination is identical to Offset-based pagination, except it uses pages instead of offsets. Users can specify the page they want to view, and the API will return a fixed number of items. The server can allow a set of sizes, for example, 10 for mobile devices and 20 for desktops.

// Model: a mongoose model
const size = 20; //
const skip = (page - 1) * size;
const [totalPage, pages] = await Promise.all([
  Model.countDocuments(),
  Model.find({isDeleted: false})
   .sort({_id: "desc"}) // MongoDB object ID are sortable
   .skip(skip)
   .limit(size)
]);

When items are added or removed between requests, this method can cause inconsistencies.

3. Key/Cursor-Based Pagination

This type of pagination method is commonly used for real-time or dynamic data. It relies on unique identifiers (keys/cursors) to paginate through results. Instead of using offsets or page numbers, the API returns results based on a specific key (e.g., ID, timestamp) provided by the user.

const cursor = ... // timestamp or ID
const size = 20;

let filter;

if (!cursor || !validateCursor(cursor)) {
  filter = {};
}
else {
  filter = {_id : {"$gt": cursor}};
}

const result = await Model.find(filter)
  .sort({_id: "desc"})
  .limit(size)

const metadata = {
 prevCursor: cursor,
 nextCursor: null,
 //...
};

if (result.length > 0) {
 metadata.nextCursor = result.at(-1)._id;
}

4. Combination Pagination

Combination pagination combines multiple pagination strategies to provide an efficient solution. For instance, combining offset-based pagination with key-based pagination can offer users both page-based and key-based pagination.

5. Range-Based Pagination

Range-based pagination involves defining a range of items to retrieve. Such could be within a specific date range or numerical range.

Range-based pagination is often combined with other paging methods to form a combination pagination.

const from = new Date("02-29-2020");
const to = new Date();

const result = Model.find({
  "createdAt": {
    "$gt": from,
    "$lt": to,
  }
  ...
})
// we can also support page-size pagination here
// .skip(skip).limit(size)

Conclusion

API pagination is essential in effectively managing and presenting large datasets. By breaking down data into manageable pages, pagination improves the navigation experience and reduces server load. In conclusion, API pagination plays a vital role in enhancing the usability and efficiency of large datasets.

By understanding the different pagination techniques and their use cases, developers can implement the most suitable method for their applications, ultimately delivering a seamless and efficient user experience.

Happy Coding 👩‍💻

TLDR; no, you shouldn’t. But why?
I recently (at the time of this writing) saw a tweet from a respected developer, Captain-EO. He had an excellent opinion on how many tutorials will teach the “how to” and not whether you “should” or “shouldn’t” do something. However, a few developers disagreed and have no issue regarding storing sensitive tokens in local storage.

In this article, I’ll project the risk of storing session tokens in localStorage. First, let’s create a simple authentication system.

The sandbox

The packages required:

npm init -y
npm install jsonwebtoken express cookie-parser

const express = require("express");
const cookieParser = require("cookie-parser");
const uuid4 = require("uuid").uuid4;

const app = express();

const users = [];

// configurations

app.use(express.urlencoded({ extended: false }));
app.use(express.json());
app.use(cookieParser("cookie_parser_secret"));

// registration endpoint

app.post("/api/auth/register", (req, res) => {
  const { username, password } = req.body;
  const id = uuid4();

  const existingUser = users.find((value) => {
    value.username === username;
  });

  if (existingUser) {
    return res.sendStatus(409);
  }

  users.push({ id, username, password });

  res.sendStatus(201);
});

// login endpoint

app.post("/api/auth/login", (req, res) => {
  const { username, password } = req.body;

  const valid = users.find(
    (value) => value.username === username && value.password === password
  );

  if (!valid) {
    return res.sendStatus(401);
  }

  res.sendStatus(200);
});

app.listen(3000);

The code above implements a simple registration and login route. When a user provides the correct credentials, this user is now privileged to access their content on that platform.

HTTP is stateless, meaning there is no way to know whether the user has that privilege. To resolve this, a token is generated and given to the client. The client must provide this token for every request to the other endpoint. On receiving this token, the server asserts if the token is invalid or valid, rejecting it if so. For a valid token, most are usually decoded. This decoded data often contains data such as the username, email, role, and database identifier. let us do that.

// update login route handler
const jwt = require("jsonwebtoken");

app.post("/api/auth/login", (req, res) => {
 const { username, password } = req.body;

 const user = users.find(
  value => value.username === username && value.password === password,
 );

 if (!user) {
  return res.sendStatus(401);
 }

 const token = jwt.sign(
  {
   username: user.username,
   id: user.id,
  },
  "jwtprivatekey",
  {expiresIn: "1h"}
 );

 return res.json({
  message: "Logged in successfully",
  token,
 });
});

The server creates the token and sends it to the client alongside a success message.

For the client, on receiving the token, there’s a need to store the token in a safe place.

?

The obvious way to retain the token will be to store it in Local storage. Local storage is a web storage solution web browsers provide to store data persistently on the logged-in user device.

Developers often misuse this feature. Local storage should be used to store configuration data and user preferences. For example, if a user prefers dark mode over light mode, I can save this preference in Local storage, so the next time the user visits my site, they can see the site in dark mode without toggling a button.

When it's about sensitive data or tokens with privileges, saving it in Local storage makes it exposed and vulnerable.
Here are some risks associated with storing sensitive information in Local Storage:

1. No Encryption: Local Storage does not provide built-in encryption for stored data. If sensitive information is stored in plain text, it could be easily read if an attacker gains access to a user device or if there is a security vulnerability.
2. Cross-Site Scripting: If your web application is vulnerable to XSS attacks, an attacker could inject malicious scripts into your pages, giving them access to Local Storage data. This could lead to the theft of sensitive information stored in Local Storage.

Why should I use Cookie?

Although this solution has caveats, it is safer compared to local storage.

Unlike Local Storage, Cookies are automatically sent along with a request by the browser. When we save a session token in local storage, we fetch this token and attach it with a request. In the case of a cookie, the backend is responsible for setting the cookie.

Client-side JavaScript can access the data stored in local storage with just a single line of code:

Object.entries(localStorage);

This means when your site is vulnerable to XSS (Cross-Site Scripting) attack, your user token can be stolen. For cookies, setting the httpOnly flag to true denies any client-side code from accessing a cookie.

//...
const token = jwt.sign(
  {
   username: user.username,
   id: user.id,
  },
  "jwtprivatekey",
  {expiresIn: "1h"}
 );
const cookieOption = {};
res.cookie("auth_session", token, cookieOption);
return res.status(200).json({...});

When a request is sent from a user’s browser, we’ll check the cookie for our session token. We can handle this by creating a middleware that restricts unauthorized access.

const isLoggedInMiddleware = (req, res, next) => {
  try {
    const token = req.cookies.auth_session; // must match the name used when we set the token
    const decoded = verifyAndDecodeToken(token);
    req.user = {...decoded};
  } catch (err) {
    return res.status(401).json({message: "You're unauthorized, please login"});
  }
  next(null);
}

Regarding cookies, setting them is not enough; there are a few attributes that we can configure to enhance security. These options include:

• HttpOnly: This option restricts it from being accessed through client-side scripts such as JavaScript. It helps mitigate the risk of XSS attacks, where an attacker injects malicious scripts into a web application to steal cookies or perform actions on behalf of the user.
• SameSite: This attribute controls how cookies are sent with cross-origin requests. It helps mitigate the risk of CSRF attacks, where an attacker tricks the user’s browser into making unintended requests to a target website. When set to Strict, the cookie is only sent to requests from the same site. In Lax mode, cookies are sent along with top-level navigation GET requests and cross-origin POST requests that trigger a top-level navigation.
• Secure: When the Secure attribute is set, the browser only sends it over HTTPS connections, ensuring it is encrypted during transmission. This helps protect sensitive information from being intercepted by attackers sniffing network traffic.
• MaxAge: This attribute limits the lifespan of cookies by setting an expiration time.

While these attributes do not eliminate these vulnerabilities, they help mitigate them.

Cookies disadvantages

CSRF Attacks

One of the vulnerabilities regarding cookies is the Cross-Site Request Forgery (CSRF) attack. It typically involves embedding malicious codes or links in a trusted website that the user visits. When the user visits the website, their browser automatically sends requests to the vulnerable application, leading to unintended actions being performed on behalf of the user.

This vulnerability all boils down to the fact that:

1. Cookies are automatically attached to a request regardless of the origin
2. You can send forms across domains/origin

<form id="my-trans" action="https://example.com/send-money" method="POST">
<input name="amount" value="10000000" />
</form>

<script>
  const form = document.getElementById("my-trans");
  form.submit();
</script>

We can prevent it by implementing measures such as:

1. CSRF Token: Include unique tokens with each request, typically by adding them in forms or headers, that only the server knows how to validate.
2. SameSite Cookies: Set the SameSite attribute on cookies to prevent them from being sent in cross-origin requests, thereby reducing the risk of CSRF attacks.
3. Origin Header: Validate the Origin or Referer header of incoming requests to ensure that they originate from trusted sources.

XSS Attack

XSS (Cross-Site Scripting) is a type of security vulnerability commonly found in web applications. It occurs when an attacker injects malicious scripts into web pages viewed by other users. These scripts can then execute within the context of the user’s browser, leading to various malicious activities such as session hijacking, defacement of websites, theft of sensitive information, and more.

While cookies can’t be read, XSS can still use the cookie on behalf of the user.

fetch("https://example.com/send-money",{
  method: "POST",
  body: JSON.stringify({amount: 300_000_000})
});

We can prevent it by implementing measures such as:

1. HttpOnly Cookies: Set the HTTPOnly flag on cookies to prevent them from being accessed by client-side scripts
2. Use Frameworks and Libraries: utilize secure web development frameworks and libraries that offer built-in protections against XSS attacks, such as AngularJS, React, and Vue.js.
3. Content Security Policy (CSP): Implement CSP headers to specify which external resources the browser should execute or load. This measure works by limiting the sources which scripts can be loaded from.

Cookies might have their issues, but they’re beneficial over local storage. The use of local storage shouldn’t be discouraged. Local Storage should be used to store insensitive data. It is best to store sensitive data as cookies. The front end shouldn’t deal with how sensitive data are kept.

In conclusion, while local storage may seem suitable for storing session tokens, its intrinsic security risks, such as lack of encryption and vulnerability to XSS attacks, make it wrong for handling sensitive information. On the other hand, cookies offer a more secure alternative, especially when configured with attributes like HttpOnly, SameSite, Secure, and MaxAge. By following established security best practices and leveraging the appropriate storage mechanism, developers can better defend user data and mitigate the risk of unauthorized access or exploitation.

Relying solely on email for authentication can be problematic from a user experience perspective. Users are denied the liberty to select what suits them best. Forced identifiers kill the freedom of personalized choice in the authentication process. In this article, I’ll cover how to handle multi-identifier authentication.

Prerequisites

• The implementations are written in TypeScript, but a basic understanding of programming is enough to follow this article.

What’s multi-identifier authentication?

Have you ever tried signing into a platform like X (formerly called Twitter) or Spotify? You would‘ve noticed the placeholder text reads “phone, email, or username”. This means you can provide any of these identifiers when signing in. That’s what I meant by “multi-identifier” authentication.

Multi-identifier authentication refers to the flexible use of another identifier like email, phone or username with the password to authenticate a user, rather than the restriction to use emails only. This is common for authentication, offering flexibility for those with complex usernames or multiple emails.

Although we’re attempting to enhance the authentication process from the backend of an application, it’s crucial to understand that the server side defines the variety of user identifiers a user can choose from.

Imagine a user schema like this:

const UserSchema = {
 username: String,
 email: String,
 phone: String,
 password: String,
 display_name: String,
}

We can’t use the field, display_name, as an identifier because it’s not unique. Users can’t expect to identify their account using their display name. The supported identifiers are username, email and phone, and that’s because they’re unique.

Importance

Multi-identifier authentication is valuable as users may own multiple, for example, email addresses. Uncertainly, trying both emails is an option, but remembering a username is often easier. With multi-identifier support, users can log in using a remembered username, helping enhance user experience.

Implementation

I’ll be implementing how the server side can handle multi-identifier authentication in Nodejs. I’ll use MongoDB and its popular ODM (Object-Document Mapper), Mongoose.

npm install express mongoose @types/express

The user model:

// user.model.ts
import mongoose from "mongoose";

const UserSchema = new mongoose.Schema({
 username: { type: String, unique: true },
 email: { type: String, unique: true },
 phone: { type: String, unique: true },
 display_name: { type: String },
}, { timestamps: true })

export default mongoose.model("user", UserSchema);

import express from "express";
import UserModel from "./user.model";

const app = express();

app.use(express.json());
app.use(express.urlencoded({extended: false});

app.post('/api/auth', authHandler);

async function authHandler(req: Request, res: Response) {
 const {userIdentifier, password} = req.body;
 try {
   const user = await UserModel.findOne({
    $or: [
     { username: userIdentifier.toLowerCase() },
     { email: userIdentifier.toLowerCase() },
     { phone: userIdentifier },
   ]});
   if (!user) {
     return res.sendStatus(400);
   }
   //... perform your password comparison & verification here!
   //...
 } catch (err) {
  console.error("Authentication error: ", err);
  return res.sendStatus(500);
 }
}

app.listen(3000);

In the context of a database query, the $or operator specifies a logical OR condition. It’s a way to find a document or record where at least one of the conditions is true.

In this example:

{
 $or: [
  { username: userIdentifier.toLowerCase() },
  { email: userIdentifier.toLowerCase() },
  { phone: userIdentifier },
 ]
}

This is specifying an OR condition for a query.

It’s saying to find a user record where

• The username field is equal to userIdentifier.toLowerCase().
• OR the email field is equal to userIdentifier.toLowerCase().
• OR the phone field is equal to userIdentifier.

The SQL alternative:

SELECT * FROM User
WHERE
  username = LOWER(:userIdentifier) OR
  email = LOWER(:userIdentifier) OR
  phone = :userIdentifier;

Conclusion

It’s necessary to deliver flexibility to users when possible. Allowing users to log into an account shouldn’t be restricted to emails alone. While some user might remember their email address, others might remember their username or phone number. Giving every user an option to pick from is another way to improve their experience with your application.

This article explains what I meant by “Multi-identifier” authentication, its importance and its implementation. An example was showcased using Node.js and MongoDB, including its SQL alternative.

Thanks for reading, and happy coding 🍻.

In the traditional request-response cycle, a server handles each task immediately upon receiving a request, leading to a real-time synchronous communication. Ideally, requests are anticipated to be fully processed within a short timeframe, although there can be a worst-case scenario, such as a minute, where tasks might take longer. When the response time becomes considerably lengthy, the client-side of an application tends to time out.

The problem

Certain requests, particularly those involving time-consuming tasks, pose challenges. Consider a scenario of processing a large ZIP file uploaded to your application. If these tasks are immediately processed by the request handler upon receiving it, and the processing of the ZIP file take around 10 minutes, the response time will be delayed for approximately 10 minutes. This can become a critical issue, especially when multiple users simultaneously upload ZIP file of a larger size. Such simultaneous requests can overload the system, leading to crashes.

Concerning the deletion of models in a database. although it might seem simple, scheduling it via a job queue is advantageous.

// a mongoose model
import Post from "../models/post.model";


async function deletePost(filter) {
  await Post.deleteOne(filter);
}

This allows you to control and prioritize tasks, ensuring that the operations are managed without affecting the immediate responsiveness of the system.

Job Queue

A job queue is a system used in software development to manage and organize tasks or jobs for processing. It significantly contributes to enhancing efficiency, and reliability by introducing a controlled and structured approach to jobs execution.

In the context of processing data, a job queue can be used to normalize the immediate processing of tasks across an application. When performing heavy tasks like file handling, data analysis etc. on a server, a job queue can efficiently reduce workloads. This will help schedule a processing task and return an acknowledgement to the client.

After scheduling the task for processing, a designated application or server, known as a worker, takes responsibility for processing the tasks. Once processed, the worker updates and dequeues the task from the job queue. This distributed approach enables the load to be distributed across various workers, preventing bottlenecks.

In practice, tools like BullMQ (for Node.js), Celery (for python) and other queuing systems provides an effective way to manage job queues, allowing you to schedule and execute tasks efficiently.

Here’s a simple example of BullMQ to schedule tasks. BullMQ uses Redis as its storage and messaging backend. So, you’ll require Redis to run this example.

npm install bullmq

Create a BullMQ queue.

import express from "express";
import {Queue} from "bullmq";
import User from "./models/user.model";
import mongoose from "mongoose";

// 10 minutes in milliseconds
const USER_DEL_DURATION = 10 * 60 * 1000;
// create an express app
const app = express();

// The queue
const UserQueue = new Queue("userDeletionQueue");

Implement DELETE /api/users/:id route handler.

//... continuation
app.delete("/api/users/:id",
async (req: express.Request, express.Response) => {
 const {id} = req.params;
 try {
  if (!mongoose.isValidObjectId(id)) return res.sendStatus(400);

  const user = await User.findById(id);
  if (!user || user.deleted) return res.sendStatus(404);

  user.deleted = true;

  // add a task to the queue
  const jobData = {
    message: `User <${id}> permanently deleted from DB`,
    userId: id,
  }
  UserQueue.add(
    "deleteUser", jobData,
    {delay: USER_DEL_DURATION}
  );

  return res.sendStatus(204);
 } catch (err) {
    res.sendStatus(500);
 }
})

A worker is a crucial component responsible for processing and executing tasks enqueued in the queue. This worker operates independently, continuously monitoring the designated job queue for pending or expired tasks.

We need a worker to process the task when it expires. The worker must run in another Node.js process.

import { Worker } from 'bullmq';
import User from "./models/user.model"

const worker = new Worker('userDeletionQueue', async job => {
  const {userId, message} = job.data;
  await User.deleteOne({_id: userId});
  console.log(message);
});

After a task has expired (the delay duration is up), it needs to be processed. That’s where a worker comes in. It processes the task, which is deleting a user from the database.

This way, the tasks have been offloaded from the server to another application (the worker process) which chronologically processes the tasks.

Conclusion

In summary, the implementation of BullMQ and its associated workers serves as a demonstration of how job queues manage and optimize time-consuming tasks within a software system. By showcasing the creation of a job queue, the handling of user deletion tasks with delayed processing, and the integral role of the worker process in offloading server responsibilities, this example brings to light the practical application of job queues in a real-world scenario.

We’ve all typed in a URL like www.google.com into our web browser. Then after, our web browser renders a web page for us. Our web browser follows a few procedures to get the web page from its host. However, we’ll uncover these procedures in this article.

In this article, we’ll dive into the steps to get the data our browser can render from the URL host. Via this article, we’ll cover

• DNS (Domain Name System) Request
• TCP (Transmission Control Protocol) / IP (Internet Protocol)
• Firewall
• HTTPS (Hypertext Transfer Protocol Secure) / SSL (Secure Sockets Layer)
• Load balancer
• Web Server
• Application Server
• Database

Our web browser gets the URL we type and needs to get the web page from it. However, our browser does not know the address where this data is kept.

In other to get this address. Our browser sends a request to a DNS server. This request is called a DNS Request.

DNS Request

This component involves sending a request from our browser to a DNS (Domain Name System) server. The DNS server process this request and translates the URL / domain name to its corresponding IP address. The DNS server is a repository for storing URLs and their IP addresses. It resolves the requests from our browser and sends a corresponding response. This response contains the URL’s IP address.

Our browser could connect to a DNS server because it has the address of a DNS server. It’ll be unable to send a request without the address of a DNS server.

After obtaining an IP address from the DNS server. Our web browser can create a connection using the IP address. Our browser has the IP address for the URL we’re visiting, which will be used to access the web server.

To establish successful communication between a web browser and a web server, it’s essential to use a communication protocol that ensures the accurate transmission of data between the two applications/devices. That’s where TCP/IP comes in.

TCP/IP

TCP (Transmission Control Protocol) is a type of communication protocol. It is used to transmit data over the internet and other computer networks. TCP provides a standardized set of procedures for how devices communicate with each other. It ensures data is sent correctly.

IP handles and directs packets between devices on the internet or network. It ensures packets are sent to the correct destination by assigning separate IP addresses to each device.

TCP is also responsible for breaking data into packets. It sends these packets over the internet and ensures they are received correctly by its recipient.

Our web browser will use the TCP interface to create a connection to the web server at the IP address. This connection between our web browser and the web server could be prevented by a Firewall, at least for now.

Firewall

According to Wikipedia,

a firewall is a network security system that monitors and controls incoming and outgoing network traffic based on predetermined security rules.

A firewall can prevent our web browser from accessing Google’s web server on a public or private network. It can also filter packets which are transferred between devices or applications. Firewalls can help prevent communicating with untrusted, malicious web servers. Especially servers tagged as dangerous (this could be by the network or system administrator).

HTTPS / SSL

HTTP (Hypertext Transfer Protocol) is an application layer protocol that functions as a request-response protocol in the client-server model. It’s used for distributing hypermedia information.

HTTPS (HTTP Secure) is widely used over the internet. It’s the secure version of HTTP. It uses encryption for secure communication over a network or internet.

The communication protocol of HTTPS is encrypted via Secure Sockets Layer (now known as Transport Layer Security, TLS).

Google’s web server supports SSL. Our web browser will create an SSL handshake with Google’s web server. With this SSL agreement, our web browser and Google’s web server can now communicate securely.

We’ve been citing web servers all this while. But what exactly is a web server?

Web Server

A web server is computer software and hardware that accepts requests via HTTP, its secure alternative, HTTPS or other protocols. A web server is used to serve dynamic or static content. Its main task is to process and deliver web pages to users. Examples include:

• NGINX (pronounced: EngineX)
• Apache HTTP Server
• Lighttpd (pronounced: Lighty)

However, Web servers are limited by the number of requests that can be driven. Google handles more than a million requests per minute. A single server can’t anchor these requests. The solution to this is having more than one server. How can these requests be shared across these servers? Through load balancing.

Load Balancer

A load balancer is a device that distributes a set of tasks over a set of servers. A load balancer distributes incoming requests among a collection of servers. It returns the response from the selected server to its appropriate client. A load balancer acts as a reverse proxy. A reverse proxy accepts a request from a client and forwards it to the server. Load balancing makes the procedure:

• Efficient by evenly distributing tasks across servers.
• Fast by optimizing response time.
• Scalable by effortlessly installing new servers.
• Maintainable by reducing workloads across servers.

Examples of a load balancer are:

• NGINX
• HAProxy
• Microsoft Azure Load Balancer
• Google Cloud Load Balancer

A load balancer sends our request to one of Google’s collection of web servers. We can get responses quicker because Google’s load balancer distributes requests effectively.

Application Server

This is a server that hosts applications or software through a communication protocol. It enables interaction between end-user clients and server-side application code to deliver dynamic content. Examples include:

• Java Application Server
• Node.js Application Server
• PHP Application Server

Application servers can manage the flow of data between components of the application.

We’ve been saying processing data and serving content. But where are they kept?

Database

A database is an organized collection of data. It allows users to retrieve, update and store information. A Database Management System (DBMS) is a software system that interacts with an application and a database to examine data. It allows users to manipulate, create and maintain databases.

Examples of a DBMS are:

• MySQL
• PostgreSQL
• MongoDB
• Microsoft SQL Server etc

The web page we’re accessing from Google is kept in a database. A DBMS maintains the database. Google’s web server can access the database from a DBMS. The data from the database can be processed and interpreted by Google’s web server. After processing the data, the web server sends a response. The load balancer receives the response and directs it to its intended client.

Conclusion

We now understand what happens when we type www.google.com into our web browser.

Briefly, When we type a URL into our web browser, our browser sends a DNS request to a DNS server. The DNS server returns an IP address if the URL is valid. IP addresses are unique to every device. They are like the address information of your house.

Our browser requires a connection with the server at the IP address. TCP/IP is used as it provides procedures for communicating efficiently. Our browser communicates with the server using HTTP, or its secure alternative, HTTPS. The IP address from the DNS response might point to a Load balancer. A load balancer shares request across a group of servers and returns a response to the intended client.

A web server itself is software and hardware that serves web content. This content can be static or dynamic. It interprets our HTTP request and generates an HTTP response which our browser will use to render a webpage for us.

If the server support secure communication, our browser will create an agreement. SSL is used to encrypt data sent to our server. This secures our communication protocol from malicious eavesdropping. HTTPS is the secure version of HTTP. It’s the protocol used for secure communication.

The whole response from the web server is kept in a database. A database is an organized collection of data. A Database Management System (DBMS) allows users to manipulate and maintain databases. A web server can access these data via the DBMS. After accessing and processing the data, the web server will generate a response and sends it back to the client. Remember, the load balancer directs the response to its intended client.

Finally, We’ve uncovered the procedures and understand “What happens when you type google.com in your browser and press Enter”.

I hope you learn from this article and understand how a web browser gets a web page for you.

Kindly leave a comment and upvote for this article. Happy Learning 👏

References to Wikipedia…