DEV Community: Mustapha El Idrissi

From AWS to a Single Server: 15 Engineering Lessons from Building an E-Commerce Platform

Mustapha El Idrissi — Wed, 28 Oct 2026 17:23:16 +0000

Building an e-commerce platform is about much more than creating product pages and a checkout button. Behind the user interface, there are architectural decisions, security concerns, data consistency challenges, and production problems that can make or break the entire system.

My team and I built an e-commerce website for a Paris-based startup. Throughout the project, we faced different engineering challenges, evaluated trade-offs, and learned lessons that went beyond writing code.

In this article, I'll walk through the main architectural and engineering decisions behind the project, from migrating infrastructure to securing authentication, modeling inventory, preventing inconsistent transactions, and diagnosing production outages.

1. The Journey: From AWS to a Single High-Resource Server

Our initial architecture was built on AWS.

The architecture used several managed services to handle different responsibilities.

After a while, we migrated to another Infrastructure-as-a-Service (IaaS) platform and ended up running most of our services on a single high-resource compute machine.

This change was an important architectural trade-off. Instead of distributing most of our services across multiple infrastructure components, we consolidated them onto a single machine.

The experience highlighted an important lesson: infrastructure decisions should be driven by actual requirements, operational constraints, and trade-offs rather than architectural trends alone.

A simpler deployment can reduce operational complexity, but consolidating services also introduces a larger single point of failure.

2. Why We Chose an API-First Architecture

One of our key decisions was to separate the frontend from the backend.

Server-Side Rendering vs. Client-Side Rendering

With Server-Side Rendering (SSR), the server generates HTML containing the data needed by the client. Depending on the technology, this might involve PHP templates, EJS, or another server-side rendering approach.

In a tightly coupled implementation, the frontend's rendering logic and backend application are closely connected. This can make changing the frontend technology or reusing the backend for other clients more difficult.

Client-Side Rendering (CSR), on the other hand, allows the frontend and backend to communicate through a defined API contract.

The frontend can use a framework such as React, while the backend exposes endpoints that communicate through a protocol such as REST.

We chose React for the frontend and an API-first approach because it gave us greater flexibility.

The backend could potentially serve different clients without requiring a complete redesign, including:

A web application built with another frontend framework
A mobile application
A frontend deployed independently on a Content Delivery Network (CDN)

The main benefit was separation of responsibilities. The frontend handled presentation, while the backend exposed the application's business capabilities through APIs.

Of course, CSR is not automatically better than SSR. Rendering strategy should depend on requirements such as SEO, performance, caching, and the user experience. In our case, frontend flexibility was a major consideration.

3. Authentication Architecture: JWTs, Cookies, and Sessions

Authentication was another important part of the project.

One security risk we considered was Cross-Site Scripting (XSS). An XSS vulnerability can allow an attacker to execute malicious JavaScript in a user's browser.

If sensitive authentication tokens are stored in JavaScript-accessible storage, such as localStorage, an attacker who successfully exploits an XSS vulnerability may be able to steal them.

Why HttpOnly Cookies?

We used HttpOnly cookies to prevent client-side JavaScript from directly reading authentication cookies.

The browser automatically includes eligible cookies in requests to the backend, subject to cookie settings and browser rules.

This reduces the risk of token theft through JavaScript, although it does not eliminate XSS or other authentication risks.

Why Use Sessions and JWTs Together?

We also used JWTs as a way to represent information associated with an authenticated user, such as their role.

For example, users might have roles such as:

client
editor
superadmin

Sessions and JWTs serve different purposes, and using both requires a clear reason and lifecycle design.

In our implementation, session rotation was our primary strategy for invalidating sessions after a suspected compromise. Rotating session identifiers forces affected clients to authenticate again when the old sessions are invalidated.

JWTs can also be rotated or revoked through appropriate mechanisms, but doing so introduces additional considerations.

The important lesson is that authentication architecture should be designed around the threat model and invalidation requirements, not simply around the popularity of a technology.

Role-Based Access Control (RBAC)

We used Role-Based Access Control (RBAC) to secure API endpoints.

RBAC made sense for our permission model because access could be granted according to a user's assigned role.

For applications requiring more granular authorization based on attributes such as ownership, resource properties, or environmental conditions, Attribute-Based Access Control (ABAC) could be a better fit.

The authorization model should match the complexity of the business requirements.

4. Modeling Inventory Across Multiple Stocks

One unexpected challenge involved inventory management.

Our client stored merchandise across multiple stock locations. Initially, we didn't have that information, so the application had been designed around a single stock location during checkout.

Fortunately, our database model was flexible enough to accommodate the new requirement.

We adapted the application so that a single product in an order could be fulfilled from one or multiple stock locations, using different quantities.

For example, if a customer ordered 10 units of a product, the application could allocate:

6 units from Stock A
4 units from Stock B

The checkout process had to handle these allocations without introducing discrepancies in inventory records.

This experience reinforced the importance of flexible data modeling.

Business requirements change. A good data model should make reasonable changes possible without requiring a complete redesign.

5. Modeling the Order Lifecycle as a State Machine

An order doesn't simply move from creation to completion in one step.

It passes through different stages, and the application needs to manage those transitions consistently.

Finite State Machines (FSMs) define the states an entity can occupy and the transitions permitted between them.

We used the concept of state machines to reason about the overall checkout process.

Thinking in terms of explicit states helps developers understand which operations are valid at each stage and which transitions should be rejected.

For example, an order should not be treated as successfully paid merely because it has been created.

Separating order states and transitions makes complex business processes easier to reason about, test, and maintain.

6. Securing Database Access Through SSH Tunnels

Many e-commerce deployments built around content management systems use web-based database administration tools such as phpMyAdmin.

These tools can be useful, but exposing a database administration interface publicly introduces another potential attack surface.

Attackers may attempt to guess credentials, exploit vulnerabilities in the administration software, or gain unauthorized access through misconfiguration.

Our Approach: SSH Tunneling

We restricted database network access so that only the authorized Linux server could connect directly to the database.

When we needed to access the database from our local development machines, we connected to the server through SSH and created a tunnel that forwarded traffic to the database.

Conceptually, the SSH server acted as a secure bridge between the development machine and the database.

This approach reduced direct exposure of the database and allowed us to administer it without making the database publicly accessible.

Network restrictions should still be combined with strong authentication, least-privilege database accounts, and appropriate SSH configuration.

The principle is straightforward: if a service doesn't need to be publicly accessible, don't expose it unnecessarily.

7. Hardening a Production Linux Server

Securing the server was another important part of running the application in production.

We applied several measures to reduce unnecessary exposure and improve the server's security posture.

We restricted inbound traffic to the ports required by the application:

Port 80: HTTP requests, redirected to HTTPS
Port 443: HTTPS traffic
Port 22: SSH administration

The SSH port was necessary for remote administration, but it still needed appropriate access restrictions.

Depending on the deployment, additional hardening measures may include SSH key authentication, disabling password-based SSH login, applying security updates, monitoring logs, and limiting administrative privileges.

The goal of server hardening is to minimize the number of unnecessary entry points and reduce the impact of potential attacks.

8. Why We Used an ORM and Database Migrations

An Object-Relational Mapper (ORM) helped us manage the relationship between our JavaScript application and the underlying relational database.

In our case, the ORM provided two particularly useful capabilities:

A way to map database structures and records to application objects
A mechanism for managing database schema migrations

Why Migrations Matter

Production databases evolve alongside applications.

We may need to add a column, modify a table, introduce a relationship, or change how information is represented.

Without a structured migration process, schema changes can become difficult to track and reproduce. Poorly planned changes can also introduce data consistency problems or make rollbacks difficult.

Migrations provide a history of schema changes and a repeatable way to apply them across environments.

An ORM also allows developers to perform database queries programmatically rather than manually constructing every SQL statement.

However, ORMs don't eliminate the need to understand SQL, database constraints, indexes, transactions, or query performance.

For a production e-commerce application, these fundamentals remain essential.

9. The Cost of Neglecting Regression Testing

Testing was one of the things we initially neglected.

Eventually, we learned why that was a mistake.

When fixing one bug, we sometimes introduced another problem in a part of the application that had previously worked correctly.

This is exactly the kind of problem regression testing is designed to detect.

Regression testing involves running existing tests after code changes to verify that previously working functionality continues to behave as expected.

For an e-commerce application, regression tests can cover critical workflows such as:

Adding products to a cart
Calculating order totals
Applying inventory changes
Processing checkout operations
Handling payment responses
Sending order-related emails

Not every test needs to be an end-to-end test. Unit tests and integration tests can catch many problems earlier and more efficiently.

The lesson we learned was simple: a feature isn't truly finished if we can't confidently verify that it works after the next change.

10. Designing a Hybrid Image Storage Strategy

Product images can be added, modified, and removed throughout the lifetime of an e-commerce application.

Frontend build assets are different. They are generated during deployment and are often good candidates for CDN delivery.

Product images, however, are dynamic assets that benefit from an explicit storage strategy.

We wanted to avoid relying entirely on an external object storage service while also avoiding a design that depended exclusively on local files.

Content-Addressable Storage

We implemented a hybrid approach in which uploaded file contents were hashed.

Content-addressable storage uses a content-derived identifier to identify a file. This can help determine whether two files contain the same data and can support consistent file management.

We stored copies both locally and remotely.

The local copy was updated when a file with the corresponding identifier was uploaded, while the remote copy was managed through a wrapper abstraction.

This abstraction helped keep the rest of the application independent of the details of the remote storage provider.

The broader lesson is that storage implementations should be replaceable where practical, particularly when external services are involved.

11. Designing a Fallback Strategy for External Storage

Using external storage introduces a dependency on another service.

If that service becomes unavailable, image delivery can be affected.

We therefore implemented a fallback mechanism for product images.

The application attempted to fetch images from the external storage endpoints first.

If an image couldn't be retrieved, it could fall back to the corresponding image in a publicly accessible directory on our own server.

This gave us an alternative delivery path if the external storage service experienced a problem.

Fallback strategies need careful implementation: missing files, permissions, caching, and actual provider outages should be distinguished appropriately.

The important principle is to identify critical external dependencies and decide what the application should do when they fail.

12. Checkout Consistency, Transactions, and Race Conditions

One of the most important challenges in the project was maintaining data consistency during checkout.

A checkout operation can involve several database writes. For example, the application may need to create an order, insert its line items, record payment-related information, and update inventory.

What happens if some operations succeed but another fails?

Without appropriate safeguards, the database could be left in a partially updated state.

Database Transactions

We used database transactions to group related operations into a unit of work.

If all the required operations succeed, the transaction can be committed. If a failure occurs before the transaction commits, it can be rolled back.

Transactions helped us avoid partial writes across the database operations included in the transaction.

However, transactions alone don't automatically solve every concurrency problem or guarantee consistency across external services. Those require additional design decisions.

Inventory Updates and Database Triggers

We also used database triggers to automatically reduce product quantities in the relevant stock locations after payment confirmation.

This helped automate inventory updates, but it also made the correctness of the payment-confirmation flow especially important.

In production systems, payment events should be processed with appropriate idempotency and concurrency safeguards so that duplicate notifications don't cause repeated inventory deductions.

Race Conditions

Race conditions were among the trickiest issues to identify.

We encountered one involving emails.

Asynchronous execution can create situations where operations run in an unexpected order or where multiple operations interfere with one another.

These problems can be difficult to reproduce because they may depend on timing.

The experience taught us to pay close attention to asynchronous workflows, especially when they involve payment processing, inventory updates, notifications, or other side effects.

Integrating Payment Gateways and Delivery Platforms

Another architectural challenge involved integrating external payment gateways and delivery platforms.

Different providers often return different data structures.

Instead of creating entirely separate database tables for every service, we generalized the common fields and stored provider-specific fields in a JSON column.

This approach allowed us to support different providers without making the database schema unnecessarily rigid.

The trade-off is that JSON-based fields require careful validation and can make querying provider-specific information more complex.

The goal was to keep the common data model consistent while preserving the flexibility needed for external integrations.

13. Diagnosing Production Outages Caused by Memory Pressure

One of the more surprising problems we encountered occurred when the Linux server became completely unresponsive, sometimes even preventing SSH access.

After investigating the problem, we discovered that the machine had no swap space configured.

What Is Swap?

Swap is disk space that the operating system can use to hold memory pages when physical RAM is under pressure.

When RAM becomes exhausted, swap can sometimes provide additional breathing room. However, disk storage is much slower than RAM, and heavy swapping can significantly degrade performance.

Without swap, a system under severe memory pressure may become unstable or invoke the operating system's out-of-memory mechanisms.

Adding swap can help in some situations, but it isn't a substitute for sufficient RAM or proper resource management.

The experience reinforced an important operational lesson: understanding the server's memory behavior is just as important as understanding the application's code.

Monitoring RAM usage, investigating memory leaks, and configuring sensible resource limits can help prevent similar incidents.

14. Why We Put Nginx in Front of Express

We needed a reliable entry point for incoming HTTP and HTTPS requests without exposing the Express application directly to the internet.

We therefore placed Nginx in front of Express.

Nginx handled incoming connections, served static assets where appropriate, terminated HTTPS, and forwarded application requests to Express.

This separation provided several benefits:

A dedicated entry point for incoming traffic
Centralized TLS configuration
Reverse proxying to the application server
An appropriate place to configure request limits and other connection-level policies

The architecture also allowed Express to focus on application logic rather than handling every aspect of public-facing traffic itself.

15. Separating Production and Testing Environments

We maintained separate testing and production environments.

This allowed us to test API endpoints and external integrations using sandbox API keys before deploying changes to the live application.

Keeping environments separate also helps prevent accidental interactions with production data and services during development.

A useful separation strategy includes distinct credentials, environment-specific configuration, and controlled deployment procedures.

The objective is to catch problems before they reach real customers.

Final Thoughts

Building this e-commerce platform taught us that software engineering involves much more than implementing features.

The project required us to think about infrastructure, security, database design, application architecture, asynchronous execution, and production reliability.

Some of our most valuable lessons came from unexpected requirements and problems that appeared only after the application was running.

If I had to summarize the main takeaways, they would be:

Choose architecture based on requirements. More infrastructure doesn't automatically mean a better solution.
Keep system boundaries clear. An API-first design can make the frontend and backend easier to evolve independently.
Treat security as a system-wide concern. Authentication, authorization, network restrictions, and server hardening all matter.
Design for changing business requirements. Flexible data models can make unexpected changes easier to accommodate.
Protect data consistency. Transactions, concurrency control, and carefully designed workflows are essential for checkout.
Invest in regression testing. Fixing one bug shouldn't introduce another.
Plan for failures. External services, limited resources, and asynchronous operations can all behave in unexpected ways.
Learn from production. Some of the most important engineering lessons only become visible when a system is operating under real conditions.

The best architecture isn't necessarily the most complex one. It's the one that meets the requirements, makes trade-offs explicit, and remains maintainable as the product evolves.

I'd love to hear from other developers: What's the most important lesson you've learned from building or maintaining a production e-commerce system?

Floating-Point Numbers

Mustapha El Idrissi — Tue, 24 Feb 2026 18:58:43 +0000

(This Blog post is part of a collaborative work between Me and Youssef El Idrissi, Consult his devTo page for more information: https://dev.to/0xw3ston)

The Backstory...

Long ago Computer Engineers found themselves in a tricky pickle, they had no way to work with Numbers that are not "full-Integers" (aka Numbers that have fractions in them).

They came up with something called "Fixed-Point Numbers":

Fixed-Point Numbers

The DOT in pink is called a radix point, it's what separates the integer value from the decimal value.

Fixed-Point is about:

giving the integer side X bits in order to represent it in binary
giving the fraction side Y bits in order to represent it in binary

Here are a few examples
(In our examples we assign 4-bits for the fraction part, 4-bits for the integer part)

Examples 1 and 2 are normal since the 8 bits cover the value(s)
however, in Examples 3 and 4 you can clearly see some issues arise when it comes on how to account for negative numbers and for accuracy.

For this reason there was another standard defined, "Floating-Point Numbers":

Floating-Point Numbers

What makes Floating-Point Numbers so elegant is the direct inspiration they have drawn from Scientific notation writing. it is a formal standard (IEEE 754)

In High School, it was taught to short-write either super big or super miniscule numbers like so.

135600000 = 1,356 * 10^8
and
0,00005997758 = 5,997758 * 10^-5

with a paper and pen (it's generally) okay to write numbers both ways (as they are, or in scientific notation)
But with computers how data is stored is very critical and requires bit-level accuracy to not get the wrong results.

Single-Precision Floating Point

32-bit representation

There's multiple variations of Floating-Point Numbers, one of them is a the 32-bit representation.

Usually in all of the Floating-Point variations we find three main components:

Mantissa: This part represents the part of our number that cannot be further encoded
Exponent: That part represents the exponent by which we multiply the Mantissa to get the original number back.
Sign: this is a one bit flag that tells us if the number is negative or positive.

Encoding

To encode a number from base-10 to base-2:

We take the integer side and turn it into binary
We take the fraction/decimal side and turn it into binary
We then slide the radix point until we get a 1 on the left side
And lastly we apply the "Bias" which we will explain later.

Encoding

Integer to Binary Conversion

We do the following Calculation to turn the integer into binary

Value (Integer)	bit
124 mod 2	0
62 mod 2	0
31 mod 2	1
15 mod 2	1
7 mod 2	1
3 mod 2	1
1 mod 2	1

1111100

Fraction/Decimal to Binary Conversion

We do the following Calculation to turn the decimal into binary

Value (Fraction)	bit
0.25568 . 2 = 0.51136	0
0.51136 . 2 = 1.02272	1
0.02272 . 2 = 0.04544	0
0.04544 . 2 = 0.09088	0
0.0988 . 2 = 0.18176	0
0.18176 . 2 = 0.36352	0
0.3652 . 2 = 0.72704	0
0.72704 . 2 = 1.45408	1
0.45408 . 2 = 0.90816	0
0.90816 . 2 = 1.81632	1
0.81632 . 2 = 1.63264	1
0.63264 . 2 = 1.26528	1
0.26528 . 2 = 0.53056	0
0.53056 . 2 = 1.06112	1
...	...

.01000001011101...

So once we are done we are left with 1111100.01000001011101

We have to normalize that to get the scientific notation for this number, we would slide the radix point to the left (or the right, depending on where the left upmost "1" exists) until there is exactly one single "1" on the left side of the radix point, like so
1111100.01000001011101100 = 1.11110001000001011101100 x 2^6

Then comes the Adding Bias step, first what's a Bias ?

Bias: Bias is a fixed value added to the real exponent so the exponent can be stored as an unsigned integer. Instead of storing negative exponents directly, we store: Stored Exponent = Real exponent + Bias

for example Single-precision Floating-point uses a bias of 127

So in this case The bias is 6 + 127 which is 133 and in binary 133 = 10000101

So we're left with:

Sign: 0 (positive number)
Exponent: 10000101
Mantissa: 111100....

In normalized IEEE 754 numbers, the leading 1 (highlighted in red in the diagram below) before the radix point is implicit and therefore not stored. This is known as the hidden bit optimization.

Decoding

Decoding is fairly simple

Extract the Exponent
Remove the Bias from the exponent to get the real exponent (which is 6 in this case)
Extract the Mantissa
Reconstruct the equation mantissa x 2^exponent

which later on gives us

This way we managed to Decode the Floating Point.

Other Precision

Half-Precision Floating-Point

Used mostly in AI and Graphics

Double-Precision Floating-Point

Mostly used in Scientific Computer such as Physics Simulations, Engineering calculations & Numerical methods.

Quad-Precision Floating-Point

Used in High-Precision scientific simulations & Financial systems where the error rate should be minimized aggressively, it is present in Astrophysics, Climate modeling, Computational number theory etc..

Octuple-Precision Floating-Point

Used in Cryptography research, symbolic mathematics, experimental physics and extremely sensitive numerical algorithms

From the Market Stalls of Morocco to Building Tech Solutions for Europe

Mustapha El Idrissi — Thu, 24 Apr 2025 18:48:35 +0000

I was born in Errachidia and raised in Nador, two small towns in Morocco, in a family deeply rooted in B2B distribution ; food, meat, and agricultural products through our family business, 2MP DIP Errachidia.

Summers were my earliest training ground. While other kids took vacations, I was at the local markets with my father and uncles, observing the rhythm of commerce and learning the subtle art of negotiation.

At my uncle’s office , a real-world classroom ,I developed an instinct for positioning products, understanding customer psychology, and thinking in strategies long before I opened my first marketing textbook.

From the Market to the Classroom

These formative experiences shaped my academic direction. I pursued a BTS in Technico-Commercial, followed by a professional bachelor's program in Management of Sales Forces, seeking to reinforce practical knowledge with formal training.

But in 2019, everything changed.

I discovered the world of digital marketing. I became fascinated by how websites rank, how algorithms behave, and how people interact with digital content. What started as curiosity quickly became a passion, and that passion pointed me towards technology.

Diving into Tech

I took a bold leap.

Determined to dive deeper, I joined a vocational program in Full-Stack Web Development at the Institute Specialized Technology Applied. Later, I advanced my skills through the ALX Software Engineering Program, specializing in Back-end Development. This rigorous training empowered me to build scalable digital solutions from scratch.

However, there was one major challenge: in Nador, tech jobs were limited.

Instead of waiting for opportunities, I decided to create them.

Building a Bridge to Europe

Drawing on my creative connections, particularly within the music and audiovisual arts community at Rif Records Studio, I found an unexpected bridge to the European market.

Alongside fellow software engineer Youssef El Idrissi, I co-founded the #./Techlab.MA Community: a remote collective of five multidisciplinary freelancers dedicated to delivering real-world tech solutions to startups and small businesses.

With my strong background in business, I naturally stepped into the role of Business Lead:

Managing client relations
Negotiating contracts
Building sustainable partnerships
Collaborating with our community in production

Real Clients, Real Impact

We’ve successfully collaborated with companies across Europe and Morocco, including:

Sanhaji Production and Ness Production in Belgium
lemiel.shop in France
22 Codes in Fes
Dima TV Press and Opal Multiservices in Morocco

These weren’t just freelance gigs. Each project was proof that talent, resilience, and results can come from anywhere , even a small town like Nador.

Looking Ahead: A New Chapter in Germany

Today, I’m actively preparing to pursue a Duales Studium in Wirtschaftsinformatik in Germany,a country where innovation meets precision and where theory is deeply connected to real-world practice.

Germany’s dual education system aligns perfectly with my story: I’ve always learned by doing, from markets to codebases. Wirtschaftsinformatik allows me to blend my business roots with technical skills to help companies deliver smarter, faster, and more user-centered solutions.

My goal is to become a bridge between business and development teams, making sure that customer needs, tech possibilities, and strategic priorities stay aligned.

This path offers the ideal convergence of my practical business experience and technical expertise, while immersing me in the heart of Europe’s innovation ecosystem.

For me, this isn’t just a career move, it’s a mission.

I aim to stand at the intersection of business and technology to build impactful, sustainable, and inclusive solutions. The goal is not just to succeed, but to open doors for others like me, self-taught, self-driven, and ready to make a difference.
In the long term, I see myself growing into the role of a Product Owner, then eventually a Chief Product Officer (CPO) or Chief Technology Officer (CTO) in a forward-thinking tech company ,guiding strategy, innovation, and cross-functional collaboration at the highest level.

Let’s Connect

I’m currently open to collaborations, mentorships, and career opportunities across the tech industry from startups to established companies, across all disciplines.

I’m especially interested in connecting with those working in Germany and also people works in :

#businessinformatics
#softwaredevelopment

Whether you’re a professional, student, founder, or mentor—if you’re passionate about tech and innovation, let’s connect and build the future together .

Real-Time Communication in Web

Mustapha El Idrissi — Thu, 06 Feb 2025 08:27:36 +0000

(This Blog post is part of a collaborative work between Me and Youssef El Idrissi, Consult his devTo page for more information: https://dev.to/0xw3ston)

What is Real-Time Communication ?

Real-Time Communication refers to the instant exchange of data between systems, often characterized by low latency, where responses are nearly immediate. This type of communication is critical in applications like messaging, live streaming, gaming, financial trading, and collaborative tools where updates need to be reflected immediately for a seamless user experience.

Some use cases for using RT Comm. Mechanisms:

Video and Audio Streaming: RTC is essential for low-latency, real-time media streaming in applications like video conferencing, virtual events, and online broadcasting where any delay can disrupt the user experience.
Live Updates and Notifications: RTC is used to push real-time notifications and alerts to users, such as updates in social media feeds, new messages, stock price changes, or sports scores, allowing users to stay up-to-date without needing to reload the page.
Instant Messaging and Chat: RTC allows for real-time text, audio, or video messaging, which is essential for communication apps and customer support platforms. Users can see messages immediately without refreshing the app.

What ways/methods exist to achieve that ?

There are 4 common ways to implement live data updates:

Short Polling: It involves sending HTTP GET Requests every X seconds (most commonly 5 seconds) in order to fetch if there are any updates from the backend server

Long Polling: This one only sends the backend one single HTTP Request, which the backend tries to delay as much as possible for incase an Update occurs to let the user be notified of it.

SSE (Server-Sent Events): This method is Unidirectional (from Backend to Frontend), which means the Client cannot send data to the server (not using SSE's anyways).

WebSockets: this is the best choice in terms of Bidirectional communication (it allows both the client and backend to communicate with eachother), it is the most common way of implementing real time communication.

There are other ways such as WebRTC for video streaming but we won't cover that in this post.

SSH Tunneling

Mustapha El Idrissi — Sat, 31 Aug 2024 17:11:05 +0000

(This Blog post is part of a collaborative work between Me and Youssef El Idrissi, Consult his devTo page for more information: https://dev.to/0xw3ston)

What is SSH Tunneling

SSH tunneling, also known as SSH port forwarding, is a method of securely routing network traffic from one network to another through an encrypted SSH (Secure Shell) connection. This technique allows you to forward traffic for various types of network services through the SSH connection, effectively bypassing firewalls or securing communications over an untrusted network, such as the internet.
There are 3 types of SSH Tunneling: Local, Remote and Dynamic

Local Port Forwarding

This forwards traffic from a specific port on the local machine to a port on a remote machine through the SSH server. It's commonly used to access services behind a firewall or NAT that aren't directly accessible from the client machine.

Example: You have a MySQL server that is running a remote machine but you don't want to directly expose its port publicly, we can use a MySQL Client Tool (such as MySQL-Workbench) through a Local SSH Tunnel to access the DB without ever exposing said database publicly.
command to execute: ssh -L [local_port]:[remote_host]:[remote_port] [user]@[ssh_server]
example: ssh -L 3008:remote.example.com:3306 user@ssh-server.com

Remote Port Forwarding

This forwards traffic from a specific port on the SSH server to a port on a machine accessible to the client. It's used to expose a local service to the internet or a remote network.

Example: You have an Apache web server that you want to be exposed only to a single remote machine (or network) to maybe automate tests or something of the sort.
command to execute: ssh -R [remote_port]:[local_host]:[local_port] [user]@[ssh_server]
example: ssh -R 8080:localhost:80 user@ssh-server.com

Dynamic Port Forwarding

This turns the SSH client into a SOCKS proxy server, allowing it to dynamically forward traffic through the SSH server. It's useful for routing traffic from multiple applications through the SSH connection.

Example: There are geographical restrictions on some website you want to visit, therefor we use the Remote machine to act as a SOCKS Proxy and essentially forward requests to the Internet on our behalf (in this case it's HTTP Requests)
command to execute: ssh -D [local_port] [user]@[ssh_server]
example: ssh -D 1080 user@ssh-server.com

What happens when you type google.com in your browser and press Enter

Mustapha El Idrissi — Sat, 20 Jul 2024 20:18:21 +0000

The Hidden Processus of a Website Request: From URL to You

We navigate websites every day, effortlessly hopping from page to page. But have you ever paused to ponder the incredible journey your request takes, from typing "google.com" to seeing the search bar appear on your screen? It's a whirlwind adventure through a complex network of technologies, all working in perfect harmony at lightning speed.
This article unveils that very journey, shining a light on the often-overlooked processes that power our online experiences. Whether you're a seasoned developer or simply curious about the inner workings of the internet, get ready to explore the fascinating world behind the URL.
Here's a roadmap of our tour:

The Quest Begins - From Address Bar to DNS
- 1.1. Consulting the Address Book: The Role of DNS
- 1.2. Unraveling the Hierarchy: The DNS Structure
- 1.3. DNS Records: Mapping Names to Addresses
Navigating the Network Highway: TCP/IP Takes Over
- 2.1. Layered Approach: Breaking Down Data Delivery
- 2.2. Unpacking the Layers: A Journey through the TCP/IP Stack
- 2.3. Data On the Move: A Simplified Journey
Standing Guard: Firewall Security Check
- 3.1. Firewall: Protecting the Network's Periphery
- 3.2. Firewall Arsenal: Tools of the Trade
- 3.3. Network Guardians: Safeguarding Data Integrity
Securing the Channel: HTTPS/SSL to the Rescue
- 4.1. HTTPS: Encryption as the Cornerstone
- 4.2. SSL/TLS: The Encryption Powerhouse
- 4.3. Certificates: Establishing Trust in a Digital World
- 4.4. The HTTPS/SSL Handshake: Establishing a Secure Connection
Sharing the Load: Enter the Load Balancer
- 5.1. Distributing the Workload: The Essence of Load Balancing
- 5.2. Load Balancing Algorithms: Deciding the Destination
- 5.3. Health Checks and Failover: Ensuring Uninterrupted Service
Welcome to the Server: The Web Server's Domain
- 6.1. Serving the Web: The Core Function
- 6.2. Serving Static vs. Dynamic Content
- 6.3. Reverse Proxy: The Multi-Purpose Intermediary
Behind the Curtain: The Application Server
- 7.1. Business Logic Powerhouse
- 7.2. Common Application Server Technologies
The Journey Back: Returning the Treasure to Your Browser
- 8.1. Packing for Delivery: From Server to Network
- 8.2. Traversing the Network: Retracing the Path
- 8.3. Passing Through Security: The Firewall's Second Inspection
- 8.4. Last Mile Delivery: Arriving at Your Doorstep
The Grand Finale: Rendering the Website
- 9.1. From Code to Content: Parsing and Rendering
- 9.2. From Code to Canvas: The Magic of Browser Rendering
A Kid-Friendly Exploration With Grown-Up Details (Ordering pizza online analogy)
Conclusion

Let's embark on this thrilling expedition, unveiling the magic that unfolds with every web browser window we open!

1. The Quest Begins - From Address Bar to DNS

The adventure starts with a simple action - you type "google.com" into your browser and hit enter. This human-friendly address is akin to a nickname, but your computer, a language-fluent number-cruncher, requires its IP address - a unique set of digits that pinpoint its location on the vast internet. This is where DNS steps in - the internet's own address book.

1.1. Consulting the Address Book: The Role of DNS

DNS, or the Domain Name System, acts as the interpreter, transforming those human-readable domain names (like "google.com") into their corresponding IP addresses. Imagine trying to find your friend's house with only their phone number. Without DNS, navigating the internet would feel like a frantic guessing game.

1.2. Unraveling the Hierarchy: The DNS Structure

DNS isn't a simple directory, but rather a globally distributed hierarchical system, designed for lightning-fast speed and efficiency. Think of it as a pyramid, each level serving a crucial role in pinpointing the right address:

Root Servers: Positioned at the top, these act as the internet's master directory. They guide your request to the appropriate Top-Level Domain (TLD) server, like the one overseeing ".com."
TLD Servers: These manage specific TLDs like ".com," ".org," ".net," or even country codes like ".uk." The ".com" server then directs you to the authoritative DNS server responsible for "google.com."
Authoritative DNS Server: This server holds the key! It stores the actual IP address associated with "google.com." Your DNS quest culminates here, with this crucial piece of information in hand.

1.3. DNS Records: Mapping Names to Addresses

The authoritative DNS server holds different records linked to a domain name:

A Record: The most essential! It directly connects the domain name to its IPv4 address - the numerical identifier computers use to communicate.
AAAA Record: This provides the IPv6 address - a newer, expansive addressing system designed to handle the booming number of internet devices.
CNAME Record: Creates aliases, allowing you to reach the same website using various names like "www.google.com" or "google.com."
MX Record: Identifies mail servers, ensuring emails destined for yourname@example.com reach the right inbox.

This invisible process seamlessly translates domain names into IP addresses, setting the stage for the next chapter of the journey.

(Ready for the network highways? Let's dive into Chapter 2!)

2. Navigating the Network Highway: TCP/IP Takes Over

Equipped with Google's IP address, your request sets out on a journey through the vast, interconnected network of computers - the internet. Picture this not as a straight line but as a complex expedition with numerous stops, utilizing intricate protocols to ensure your message arrives safely and in perfect order. Enter TCP/IP - the internet's universal language and trustworthy guide.

2.1. Layered Approach: Breaking Down Data Delivery

TCP/IP (Transmission Control Protocol/Internet Protocol) is not one gigantic entity but rather a set of meticulously organized protocols forming layers. Each layer focuses on specific tasks, allowing data transmission across diverse network environments with unmatched flexibility and efficiency.

2.2. Unpacking the Layers: A Journey through the TCP/IP Stack

Imagine your data packed into a series of carefully labelled envelopes, each ready for delivery. Let's explore how these envelopes traverse the layers:

Link Layer: This is the starting point! It manages the direct connections between devices on a local network using protocols like Ethernet (for wired connections) and Wi-Fi (for wireless connections). This layer ensures your data moves smoothly from your computer to your router - the gateway to the broader internet.
Internet Layer: Here's where logical addresses and routing come into play. The star of the show: The Internet Protocol (IP), responsible for assigning unique addresses to every device on the internet. IP ensures that your data packets (like meticulously addressed letters) arrive at their intended destination, even after journeying through countless routers and networks.
Transport Layer: While IP handles the delivery, it doesn't guarantee order or protect against loss - particularly during internet traffic jams! This is where reliable delivery and order are established.
- Two main players in this layer are TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). TCP, like a conscientious courier, prioritizes reliable delivery for sensitive data like web pages and emails. This ensures all packets arrive in the correct order and are correctly reassembled. UDP, however, prioritizes speed over guaranteed delivery. Like a live news broadcast where the occasional blip is expected, it's ideal for real-time applications like video streaming or online gaming.
Application Layer: This layer directly interacts with your applications, such as web browsers and email clients. For browsing, Hypertext Transfer Protocol (HTTP) is the go-to protocol. It dictates how your browser communicates with web servers, requesting and receiving the content you see on websites.

2.3. Data on the Move: A Simplified Journey

Visualize your request being meticulously divided into multiple envelopes (data packets). Each packet is labeled with source and destination IP addresses and sets off on its exciting adventure across the internet, potentially traveling through routers, fiber optic cables, or even bouncing between satellites, all guided by the IP addressing system. Along the way, routers function like traffic directors, analyzing packet headers and selecting the most efficient path to ensure your request reaches Google's servers. Finally, these packets are meticulously reassembled, ready for processing.

(Our journey takes a detour towards security! Let's see how the Firewall safeguards our data in Chapter 3.)

3. Standing Guard: Firewall Security Check

Before your request reaches Google, it encounters a vital checkpoint: The Firewall. This digital bouncer scrutinizes incoming and outgoing network traffic, strictly enforcing rules to decide which connections should be allowed and blocked. The Firewall serves as a critical layer of protection against unauthorized access and malicious attacks.

3.1. Firewall: Protecting the Network's Periphery

Picture a castle with a surrounding moat and drawbridge - The Firewall acts like a similar barrier for your network, meticulously guarding against unwelcome visitors (malicious data) seeking to infiltrate and wreak havoc. The Firewall diligently examines each incoming packet's header information for any signs of harmful intent.

3.2. Firewall Arsenal: Tools of the Trade

Firewalls use several strategies to identify and neutralize threats:

Packet Filtering: Like a border control officer, the Firewall carefully analyzes specific attributes of each data packet, including source and destination IP addresses, port numbers (identifying specific services on a device), and the protocol type being used. If a packet meets pre-defined security criteria, it passes; otherwise, it's blocked.
Stateful Inspection: Advanced Firewalls remember ongoing conversations (connections) by maintaining a record of acceptable traffic patterns. Incoming packets that don't fit within these established connections are deemed suspicious and are promptly blocked.
Application Layer Filtering: Sophisticated Firewalls take things a step further by analyzing the actual data contained within packets - this is like checking a letter's contents for suspicious material. They can detect and prevent common hacking techniques like SQL injection attacks or other malicious activity.

3.3. Network Guardians: Safeguarding Data Integrity

Working tirelessly behind the scenes, Firewalls are essential for online security. They provide a safety net for your network and your personal information, ensuring data integrity and confidentiality by protecting it from a constantly evolving landscape of cyber threats, from simple packet filtering to advanced intrusion detection.

(Now that we've successfully passed the Firewall's security check, it's time for another layer of protection! Let's see how HTTPS keeps our data safe in transit in Chapter 4.)

4. Securing the Channel: HTTPS/SSL to the Rescue

Having bypassed the Firewall's scrutiny, your request continues its journey. But security now becomes even more paramount, especially when sensitive data like passwords or credit card numbers are involved. Enter the dynamic duo - HTTPS and SSL/TLS - they create a secure tunnel to protect your data from unwanted eyes.

4.1. HTTPS: Encryption as the Cornerstone

Imagine sending a postcard with your credit card details - anyone could intercept it and easily read it. HTTPS (Hypertext Transfer Protocol Secure) prevents this by encrypting your communication with the website, converting it into a code that eavesdroppers can't decipher.

4.2. SSL/TLS: The Encryption Powerhouse

HTTPS relies on SSL/TLS (Secure Sockets Layer/Transport Layer Security) protocols to establish this secure encrypted connection between your browser and the website's server. Imagine a secret code language understood only by you and the recipient! These protocols utilize strong encryption algorithms to scramble your data into gibberish for any unauthorized parties, even if it is intercepted.

4.3. Certificates: Establishing Trust in a Digital World

To ensure this secure communication, websites employ SSL/TLS certificates - think of them as digital passports issued by trustworthy authorities known as Certificate Authorities (CAs). These certificates verify a website's authenticity and provide the necessary keys for unlocking encrypted communication.

4.4. The HTTPS/SSL Handshake: Establishing a Secure Connection

Before any encrypted exchange can take place, a secure handshake occurs between your browser and the server:

Client Hello: Your browser initiates the process by sending a "Client Hello" message, informing the server of the SSL/TLS versions and encryption methods it understands.
Server Hello: The server responds with a similar "Server Hello" message, confirming its capabilities and selecting specific algorithms for the session.
Certificate Exchange: The server presents its SSL/TLS certificate, acting as its digital ID card. Your browser meticulously analyzes the certificate, checking its validity, expiration date, and confirmation of its issuance by a recognized CA.
Key Exchange: Once the certificate is verified, a secure key exchange takes place. The server creates temporary "session keys" - secret codes for this particular conversation - and encrypts them using its private key. Your browser, holding the server's public key from the certificate, decrypts the session keys and retrieves them.
Encrypted Communication: Now, both sides can communicate securely! Your browser and the server utilize the shared session keys to encrypt all exchanged data, making eavesdropping impossible.

This sophisticated handshake, entirely invisible to you, serves as the cornerstone of secure online transactions, protecting your passwords, payment information, and personal details.

(Our communication is now secure! But how does the server manage the tremendous influx of requests? Let's explore the role of Load Balancers in Chapter 5!)

5. Sharing the Load: Enter the Load Balancer

Imagine millions of users across the globe simultaneously attempting to access Google. To handle this massive influx and ensure a seamless and speedy experience for everyone, a critical player emerges: The Load Balancer.

5.1. Distributing the Workload: The Essence of Load Balancing

Picture a busy airport with multiple runways and an air traffic controller diligently directing incoming planes for smooth operations. Similarly, a Load Balancer distributes incoming traffic among a farm of servers, preventing any individual server from being overwhelmed. This effectively optimizes resource utilization, enhances performance, and keeps Google up and running even during peak traffic times.

5.2. Load Balancing Algorithms: Deciding the Destination

Load Balancers use various algorithms to decide which server should receive a request, each with its strengths for specific scenarios:

Round Robin: This simple strategy assigns requests to servers in a sequential fashion, guaranteeing an even distribution of workload over time. Imagine customers queuing up at a checkout line, with each cashier taking turns.
Least Connections: This dynamic algorithm prioritizes current server load, directing traffic to the server with the fewest active connections, optimizing resource usage.
IP Hashing: This method generates a unique hash key based on the client's IP address, consistently directing requests from the same client to the same server. This is particularly useful for websites that store user-specific data, maintaining consistency for each individual user.

5.3. Health Checks and Failover: Ensuring Uninterrupted Service

Load Balancers don't just distribute traffic; they vigilantly monitor the health of each server:

Health Checks: Periodically, they send test requests (heartbeats) to servers and analyze the responses.
Failover: If a server fails a health check (due to crashing, becoming too slow, etc.), the Load Balancer immediately removes it from the active pool and automatically redirects traffic to the remaining healthy servers. This ensures that users experience no disruptions, keeping the website online even in the face of temporary issues.

(Now that our request has navigated the traffic flow, let's see where it lands - The Web Server! Head to Chapter 6!)

6. Welcome to the Server: The Web Server's Domain

After traversing the network labyrinth, your request finally arrives at its destination: The Web Server. This powerful machine stores all the components that constitute a website - HTML files, images, videos, and more - and meticulously prepares the requested information for delivery back to your browser.

6.1. Serving the Web: The Core Function

Imagine a well-organized library with a dedicated librarian. When you request a specific book, the librarian fetches it from the vast collection and hands it to you. The Web Server operates similarly - it receives your request, retrieves the necessary data from its storage, and prepares it for transmission. Its primary responsibility is to manage HTTP (or HTTPS) communication - the language browsers and servers use to talk.

6.2. Serving Static vs. Dynamic Content

Web Servers can deliver content in two main forms:

Static Content: This refers to unchanging files readily available on the server's disk. Picture a printed flyer - everyone receives the same information. Examples include images, videos, CSS files (defining the webpage's visual style), and HTML files structuring the website's layout. Serving static content is straightforward - the server simply locates and delivers the requested file.
Dynamic Content: This is where websites come alive! Dynamic content is generated on the fly, personalized based on the user or specific requests. Imagine ordering a custom pizza from a chef! When you interact with features requiring user-specific data, such as logging in, submitting a form, or making a purchase, the web server calls upon specialized software called Application Servers. These powerhouses, often housed on separate hardware, handle complex logic, database interactions, and calculations to personalize the content just for you.

6.3. Reverse Proxy: The Multi-Purpose Intermediary

Modern web servers frequently operate as Reverse Proxies - acting as gatekeepers to an exclusive event, managing and filtering all incoming requests.

Security: Reverse Proxies conceal the web server's true location from the public, protecting it from direct attacks.
Caching: They strategically store frequently accessed data like images or style sheets closer to users, accelerating delivery and minimizing server workload. Picture placing copies of popular books in different library branches for easy access!
Load Balancing: Similar to a dedicated traffic director, they distribute requests among multiple backend servers, preventing any single server from being overwhelmed, enhancing overall performance.

(The web server is bustling, but what about dynamic content and user interactions? Enter the mighty Application Server, which we explore in Chapter 7!)

7. Behind the Curtain: The Application Server

While the Web Server primarily handles static content and HTTP communication, the Application Server is where the true magic of interactive websites unfolds. Imagine a vibrant kitchen with chefs preparing delicious custom-made dishes based on your orders - that's the Application Server in action!

7.1. Business Logic Powerhouse

Application Servers are the brains behind sophisticated web applications. They are responsible for handling the behind-the-scenes logic, database interactions, and processes that make websites dynamic and responsive to your actions.

Processing Business Logic: They execute the rules governing how the application behaves. For example, when you book a flight online, the Application Server verifies your details, checks availability based on complex fare rules, processes your payment, and issues your confirmation, all following carefully defined logic.
Data Persistence: They manage how the application interacts with databases and other storage mechanisms. This involves storing your profile information, tracking your shopping cart items, remembering your preferences, and retrieving all necessary data for a personalized experience.
Session Management: Web applications need to "remember" your interactions for a seamless user experience. The Application Server handles these "sessions", tracking logged-in users, preserving data between page transitions (like items in your online shopping cart), and personalizing your journey.

7.2. Common Application Server Technologies

Various application server technologies are available, catering to specific programming languages and requirements:

Java EE Application Servers: Robust platforms designed for large-scale Java applications commonly used in enterprises. They employ technologies like JavaServer Pages (JSP), Java Servlets, and Enterprise JavaBeans (EJBs).
PHP Application Servers: Servers specifically optimized for executing PHP code, a popular language for web development. They improve performance through caching and enhance security.
Node.js: A JavaScript-based environment, Node.js has gained popularity for creating fast, real-time web applications. Its efficient handling of concurrent connections makes it ideal for chat apps, collaborative tools, and data-intensive applications.

(The request is processed! It's now time for its return journey. Let's see how the response makes its way back to your screen in Chapter 8.)

8. The Journey Back: Returning the Treasure to Your Browser

After the server diligently processes your request, generates the required content, possibly consulting databases and applications, it's time to deliver the results - the treasure! The carefully crafted response, containing the webpage, images, or data, embarks on its return journey to your eagerly awaiting browser.

8.1. Packing for Delivery: From Server to Network

Just like your initial request, the response is packaged for travel across the internet. The Web Server meticulously bundles the information into HTTP (or HTTPS) response packets, prepared to retrace the path back to your device.

8.2. Traversing the Network: Retracing the Path

These data-filled packets start their journey homeward, guided by the same trusty IP protocol that delivered your original request. They traverse routers and networks, following the most efficient routes chosen by these intelligent traffic directors.

8.3. Passing Through Security: The Firewall's Second Inspection

As they near your network, the response packets encounter your vigilant Firewall once again, this time performing outbound inspection. Just as before, the Firewall meticulously scrutinizes packet headers, verifying that the incoming data aligns with an established connection initiated by your device. Once cleared, the packets enter your local network, drawing ever closer to their final destination - your browser.

8.4. Last Mile Delivery: Arriving at Your Doorstep

Finally, after an epic adventure across the vast digital landscape, the response packets arrive at your computer. Your operating system, acting as the gatekeeper, receives the packets, recognizing they belong to your browser and swiftly delivers them.

(Our data has safely returned! But the journey isn't complete yet. It's time for the grand finale, where raw data is transformed into the visual masterpiece we recognize as a website! Let's go to Chapter 9.)

9. The Grand Finale: Rendering the Website

Our voyage through networks and servers reaches its climax here - the final stage unfolds entirely within your web browser. The raw data, delivered as a stream of bits and bytes, undergoes a remarkable transformation, rendering the interactive, visually-rich webpage that we experience.

9.1. From Code to Content: Parsing and Rendering

Imagine your browser as a skilled artisan carefully assembling raw materials to create a breathtaking masterpiece.

HTML Parsing: The browser receives the HTTP response, often a mixture of HTML, CSS, and JavaScript code. The HTML parser - a crucial component of the browser engine - deciphers this markup, identifying elements like headings, paragraphs, images, and links. It meticulously arranges these elements into a structured, hierarchical representation known as the Document Object Model (DOM). Picture the DOM as the scaffolding that will eventually support a beautiful building.
CSS Styling: Next, the browser parses the accompanying CSS (Cascading Style Sheets), the language dictating the website's visual style. Like an interior designer, it applies these style rules to the DOM elements, defining colors, fonts, layout, and the overall visual presentation.
JavaScript Execution: For interactive elements and dynamic behavior, the browser engages its JavaScript engine. Imagine bringing the website to life! JavaScript code, either embedded within the page or linked externally, enables features like animations, dynamic updates, responses to user interactions, and even fetching data from servers without needing a full page reload.
Layout and Painting: With the DOM structured, styles applied, and JavaScript executed, the browser arranges the content. It meticulously calculates the position and size of each element based on the viewport dimensions (your screen size) and the defined styles. Finally, like an artist grabbing their brush, the browser paints the visual components - text, images, colors - onto the screen, following the carefully crafted blueprint defined by the code.

9.2. From Code to Canvas: The Magic of Browser Rendering

This multi-stage process - parsing, styling, executing, layout, and painting - unfolds at lightning speed, entirely invisible to the user. Today's browsers are exceptionally sophisticated. They seamlessly integrate multiple functionalities - interpreters, rendering engines, JavaScript virtual machines, and security managers - all while prioritizing performance for a smooth, visually appealing, and captivating experience for every website you visit.

(Our journey draws to a close, but the magic of the internet continues. Let's recap our adventure with a relatable example! Onto Chapter 10.)

10. A Kid-Friendly Exploration With Grown-Up Details

We've traversed complex networks and dissected server functions - let's simplify things! Imagine ordering pizza online - a relatable analogy, even for a 7-year-old, can highlight the key stages of our website journey.

(Imagine you're craving pizza!) 🍕

Step 1: Finding the Pizza Place (DNS)

You want Pizza Hut, but your phone needs its address. This is where DNS comes in - it translates "pizzahut.com" into an IP address - the numerical code your phone understands, like a phonebook translating names into phone numbers.

Kid-Friendly: It's like looking up your friend's phone number to call them.
Technical: The DNS hierarchy begins with root servers, then progresses to TLD servers overseeing domains like ".com," ultimately reaching the authoritative DNS server storing the website's IP address.

Step 2: On the Road (TCP/IP)

Knowing the pizza place's address, your phone uses TCP/IP - the internet's delivery service - to send your order.

Kid-Friendly: Your order is meticulously packed into a delivery truck and sent to Pizza Hut.
Technical: TCP/IP breaks data down into packets, loads them for delivery, and ensures they arrive complete and in the correct order through its layered structure (Link, Internet, Transport, Application).

Step 3: The Security Check (Firewall)

At Pizza Hut, a security guard checks incoming orders - the Firewall.

Kid-Friendly: The guard checks if your order looks okay and isn't trying to sneak in anything unwanted!
Technical: Firewalls analyze incoming and outgoing traffic based on pre-set rules, filtering malicious requests and allowing legitimate traffic.

Step 4: The Pizza Chef (Web Server)

Inside, the Web Server - the pizza chef - receives your order and begins preparing!

Kid-Friendly: The chef sees your order and starts making your pizza!
Technical: Web servers receive HTTP requests and process them, retrieving static content or collaborating with application servers for dynamic content.

Step 5: Pizza’s On Its Way (Response)

Pizza is ready! The Web Server packs it for delivery, sending it back through TCP/IP.

Kid-Friendly: The delivery truck is back, bringing your delicious pizza!
Technical: The Web Server prepares an HTTP response containing the requested information, packs it into data packets, and hands it off to TCP/IP for delivery.

Step 6: Enjoy Your Pizza! (Website Loads)

You get the delivery, unpack it, and savor your delicious meal!

Kid-Friendly: You finally get to enjoy the pizza you ordered!
Technical: Your browser receives the data packets and renders the website based on the code (HTML, CSS, Javascript), displaying the final visually-appealing page on your screen.

Every website you visit, each link you click, triggers a journey like this - all unfolding in the blink of an eye!

Conclusion: A World Beneath the Surface

From a simple keystroke to the dazzling array of information and interactivity at our fingertips, we've revealed the remarkable journey behind every website visit. It stands as a testament to human ingenuity - a sophisticated symphony of technologies working in perfect harmony, often within mere milliseconds, to deliver the seamless online experiences we have come to expect.

The next time you type in a URL, remember the world beneath the surface - a bustling network infrastructure diligently working behind the scenes. DNS servers tirelessly translate names into addresses, TCP/IP packets speed across continents, Firewalls stand guard, and powerful servers meticulously process requests. This intricate dance, invisible to most, showcases the beauty of interconnected systems - a digital choreography orchestrating the flow of information in our increasingly digital world.

Understanding this journey, even on a high level, enhances our appreciation for the incredible technology we interact with every day. It serves as a reminder that beneath the sleek interfaces and instant gratification, lies a world of complex processes and innovative engineering, constantly evolving to power our expanding digital lives.

DEV Community: Mustapha El Idrissi

From AWS to a Single Server: 15 Engineering Lessons from Building an E-Commerce Platform

1. The Journey: From AWS to a Single High-Resource Server

2. Why We Chose an API-First Architecture

Server-Side Rendering vs. Client-Side Rendering

3. Authentication Architecture: JWTs, Cookies, and Sessions

Why HttpOnly Cookies?

Why Use Sessions and JWTs Together?

Role-Based Access Control (RBAC)

4. Modeling Inventory Across Multiple Stocks

5. Modeling the Order Lifecycle as a State Machine

6. Securing Database Access Through SSH Tunnels

Our Approach: SSH Tunneling

7. Hardening a Production Linux Server

8. Why We Used an ORM and Database Migrations

Why Migrations Matter

9. The Cost of Neglecting Regression Testing

10. Designing a Hybrid Image Storage Strategy

Content-Addressable Storage

11. Designing a Fallback Strategy for External Storage

12. Checkout Consistency, Transactions, and Race Conditions

Database Transactions

Inventory Updates and Database Triggers

Race Conditions

Integrating Payment Gateways and Delivery Platforms

13. Diagnosing Production Outages Caused by Memory Pressure

What Is Swap?

14. Why We Put Nginx in Front of Express

15. Separating Production and Testing Environments

Final Thoughts

Floating-Point Numbers

The Backstory...

Fixed-Point Numbers

Floating-Point Numbers

Single-Precision Floating Point

Encoding

Integer to Binary Conversion

Fraction/Decimal to Binary Conversion

Decoding

Other Precision

Half-Precision Floating-Point

Double-Precision Floating-Point

Quad-Precision Floating-Point

Octuple-Precision Floating-Point

From the Market Stalls of Morocco to Building Tech Solutions for Europe

From the Market to the Classroom

Diving into Tech

Building a Bridge to Europe

Real Clients, Real Impact

Looking Ahead: A New Chapter in Germany

Let’s Connect

Real-Time Communication in Web

What is Real-Time Communication ?

Some use cases for using RT Comm. Mechanisms:

What ways/methods exist to achieve that ?

SSH Tunneling

What is SSH Tunneling

Local Port Forwarding

Remote Port Forwarding

Dynamic Port Forwarding

What happens when you type google.com in your browser and press Enter

The Hidden Processus of a Website Request: From URL to You

Table of Contents

1. The Quest Begins - From Address Bar to DNS

2. Navigating the Network Highway: TCP/IP Takes Over

3. Standing Guard: Firewall Security Check

4. Securing the Channel: HTTPS/SSL to the Rescue

5. Sharing the Load: Enter the Load Balancer

6. Welcome to the Server: The Web Server's Domain

7. Behind the Curtain: The Application Server

8. The Journey Back: Returning the Treasure to Your Browser

9. The Grand Finale: Rendering the Website

10. A Kid-Friendly Exploration With Grown-Up Details

Conclusion: A World Beneath the Surface