Forem: Mohamed Idris

🧠 The Backend Developer Fundamentals Guide

Mohamed Idris — Wed, 08 Apr 2026 11:22:54 +0000

Understand the engine before you drive the car.

This guide teaches you the concepts behind every framework. Learn this once, and Spring, Node, Laravel, Django — they'll all just be different flavors of the same thing.

How The Internet Actually Works
Request & Response — The Heart of Everything
What a Server Actually Does
How Data Flows Through a System
Memory, Threads & Processes
Databases — Where Data Lives
APIs — How Systems Talk to Each Other
Authentication & Authorization
Caching — Making Things Fast
Security Basics
Architecture Patterns
Networking Essentials
Linux & The Command Line
Version Control (Git)
Testing
DevOps Basics
The Learning Order (Roadmap)

1. How The Internet Actually Works

Before you write a single line of backend code, you need to understand how the internet works. It's simpler than you think.

DNS — The Phone Book of the Internet

When you type google.com in your browser, your computer doesn't know what that means. Computers only understand numbers (IP addresses like 142.250.80.46). So your computer asks a DNS server (Domain Name System): "Hey, what's the IP address for google.com?"

Think of it like this: you know your friend's name, but you need their phone number to call them. DNS is the contact list.

The flow:
You type google.com → Your computer asks DNS → DNS says "that's 142.250.80.46" → Your computer connects to that IP address.

TCP/IP — The Delivery System

Once your computer knows the IP address, it needs to send and receive data. That's where TCP/IP comes in.

IP (Internet Protocol): This is like the address on a package. It tells data where to go.
TCP (Transmission Control Protocol): This makes sure the data arrives completely and in order. It's like a delivery service that makes you sign for the package — it confirms everything arrived.

Why this matters for backend: Every single thing your server does involves TCP/IP. When a user opens your app, their phone creates a TCP connection to your server. Understanding this helps you debug network issues later.

Ports — Doors Into Your Server

Your server is like a building, and ports are the doors. Different services use different doors:

Port 80 → Regular web traffic (HTTP)
Port 443 → Secure web traffic (HTTPS)
Port 5432 → PostgreSQL database
Port 3306 → MySQL database
Port 27017 → MongoDB

When someone visits your website, they're knocking on port 80 or 443 of your server.

HTTP/HTTPS — The Language of the Web

HTTP (HyperText Transfer Protocol) is the language browsers and servers speak. HTTPS is the same thing but encrypted (the "S" stands for Secure).

Every time you load a webpage, your browser sends an HTTP request, and the server sends back an HTTP response. That's literally all web development is at its core — requests and responses.

2. Request & Response — The Heart of Everything

This is the single most important concept in backend development. Everything else is built on top of this.

What is a Request?

A request is a message from a client (browser, mobile app, another server) asking your server to do something. Every request has:

Method (Verb): What action do you want?
- GET → "Give me some data" (like loading a page)
- POST → "Here's some new data, save it" (like submitting a form)
- PUT → "Update this existing data completely"
- PATCH → "Update just part of this data"
- DELETE → "Remove this data"
URL (Path): What resource do you want?
- /users → the users resource
- /users/42 → user number 42 specifically
- /users/42/orders → orders belonging to user 42
Headers: Extra info about the request (like metadata)
- Content-Type: application/json → "I'm sending JSON data"
- Authorization: Bearer abc123 → "Here's my login token"
- Accept: application/json → "Please respond with JSON"
Body: The actual data (only for POST, PUT, PATCH)

  {
    "name": "Ahmed",
    "email": "ahmed@example.com"
  }

What is a Response?

The response is your server's answer. Every response has:

Status Code: A number that tells the client what happened
- 200 → "OK, here's what you asked for"
- 201 → "Created — I made the new thing you wanted"
- 400 → "Bad Request — you sent me something wrong"
- 401 → "Unauthorized — who are you? Log in first"
- 403 → "Forbidden — I know who you are, but you can't do this"
- 404 → "Not Found — that thing doesn't exist"
- 500 → "Internal Server Error — I broke, it's my fault"
Headers: Extra info about the response
Body: The actual data being sent back

  {
    "id": 42,
    "name": "Ahmed",
    "email": "ahmed@example.com"
  }

The Full Picture

User clicks "Sign Up" button
        ↓
Browser sends POST request to /api/users
  with body: { name: "Ahmed", email: "ahmed@example.com", password: "..." }
        ↓
Server receives the request
        ↓
Server validates the data (is the email real? is the password strong enough?)
        ↓
Server hashes the password (never store plain passwords!)
        ↓
Server saves the user to the database
        ↓
Server sends back a response: 201 Created
  with body: { id: 42, name: "Ahmed", message: "Account created!" }
        ↓
Browser shows "Welcome, Ahmed!"

This flow is identical in every framework. Express, Spring, Django, Laravel — they all do this exact thing. The only difference is the syntax.

3. What a Server Actually Does

A server is just a computer that's always on, always connected to the internet, and always listening for requests.

The Server's Job, Step by Step

Listen — The server sits and waits on a specific port (usually 80 or 443), doing nothing until someone sends a request.
Receive — A request arrives. The server reads the method, URL, headers, and body.
Route — The server figures out which piece of code should handle this request. "Oh, they want GET /users/42? Let me call the getUserById function."
Process — The actual business logic happens here: validate data, talk to the database, calculate things, call other services.
Respond — The server builds a response with a status code and data, then sends it back.
Go back to step 1 — The server goes back to listening for the next request.

Middleware — The Assembly Line

In most frameworks, before your request reaches the actual handler, it passes through a chain of middleware. Think of it like a factory assembly line:

Request arrives
    ↓
[Logging Middleware] — "Let me record that this request happened"
    ↓
[Auth Middleware] — "Let me check if this user is logged in"
    ↓
[Validation Middleware] — "Let me check if the data is correct"
    ↓
[Your Actual Handler] — "OK, now I'll do the real work"
    ↓
Response goes back

Every framework has middleware. Express calls it middleware. Django calls it middleware. Spring calls it filters/interceptors. Laravel calls it middleware. Same concept, different names.

4. How Data Flows Through a System

When you build a real app, data moves through multiple layers. Understanding this flow is what separates someone who just copies code from someone who actually understands what's happening.

The Typical Layers

CLIENT (Browser/App)
    ↕ HTTP Request/Response
CONTROLLER / ROUTE HANDLER
    → Receives the request, extracts data from it
    → Calls the right service
    ↕
SERVICE / BUSINESS LOGIC
    → The "brain" — decides what to do
    → Applies rules: "Users under 18 can't buy this"
    → Coordinates between different pieces
    ↕
REPOSITORY / DATA ACCESS
    → Talks to the database
    → Translates between your code's objects and database rows
    ↕
DATABASE
    → Stores data permanently

Why Layers Matter

Imagine you're building a food delivery app. A user places an order:

Controller receives: POST /orders with { restaurantId: 5, items: [...] }
Service checks: Is the restaurant open? Does the user have enough balance? Is there a driver available?
Repository saves the order to the database, updates the user's balance, notifies the restaurant
Response goes back: 201 Created with the order details

If you dump all of this into one file, it becomes an unreadable mess. Layers keep things organized and reusable. Every professional codebase uses layers, regardless of the framework.

5. Memory, Threads & Processes

This is where most tutorials skip and where most junior devs get confused. But it's essential.

Memory — Your Program's Workspace

When your server starts, the operating system gives it a chunk of RAM (memory). Think of RAM like a desk — it's where your program puts things it's currently working with.

Stack Memory: Fast, organized, automatic. Used for simple variables and function calls. When a function finishes, its stack memory is automatically cleaned up.
Heap Memory: Bigger, messier, manual (or garbage-collected). Used for objects, arrays, and anything complex. Stays around until your code (or the garbage collector) removes it.

Why this matters: If your server creates tons of objects and never cleans them up, you get a memory leak. Your server slowly uses more and more RAM until it crashes. This is a real-world problem you'll face.

Processes — Independent Workers

A process is a running program. When you start your server, that's one process. Each process gets its own memory — processes don't share memory with each other.

If your server crashes, the process dies. That's why in production we use tools that automatically restart crashed processes.

Threads — Workers Inside a Worker

A thread is like a worker inside a process. One process can have multiple threads, and they all share the same memory.

Think of a restaurant:

The process is the restaurant itself
The threads are the waiters
The memory is the kitchen and the order board

Multiple waiters (threads) can serve different tables (requests) at the same time, and they all share the same kitchen (memory).

Blocking vs Non-Blocking

This is a critical concept:

Blocking: When your code does something slow (like reading a file or querying a database) and the thread just sits and waits. Nothing else can happen on that thread until it's done. Like a waiter standing at the kitchen window waiting for one dish instead of taking other orders.
Non-Blocking (Async): The thread says "I'll come back for this later" and goes to handle other requests. When the slow operation finishes, it picks up where it left off. Like a waiter who takes another table's order while the kitchen cooks.

Node.js is single-threaded but non-blocking (one waiter who never stops moving). Java/Spring is multi-threaded (multiple waiters, each can wait). Both approaches work; they have different tradeoffs.

Concurrency vs Parallelism

Concurrency: Handling multiple tasks by switching between them quickly (one CPU core, many tasks). Like one person cooking three dishes by switching between them.
Parallelism: Actually doing multiple tasks at the exact same time (multiple CPU cores). Like three people each cooking one dish.

You don't need to master this immediately, but keep it in mind — as your app grows, these concepts will determine if your server can handle 100 users or 100,000.

6. Databases — Where Data Lives

Memory is temporary — when your server restarts, everything in RAM is gone. Databases store data permanently (on disk).

Relational Databases (SQL)

These store data in tables (like spreadsheets). Examples: PostgreSQL, MySQL, SQLite.

USERS TABLE:
| id | name   | email              | created_at |
|----|--------|--------------------|------------|
| 1  | Ahmed  | ahmed@example.com  | 2025-01-15 |
| 2  | Sara   | sara@example.com   | 2025-02-20 |

ORDERS TABLE:
| id | user_id | product     | amount |
|----|---------|-------------|--------|
| 1  | 1       | Laptop      | 999    |
| 2  | 1       | Mouse       | 25     |
| 3  | 2       | Keyboard    | 75     |

The user_id in ORDERS relates to the id in USERS. That's why they're called "relational." You can ask: "Give me all orders for user Ahmed" by joining the tables.

SQL (Structured Query Language) is how you talk to these databases:

-- Get all users
SELECT * FROM users;

-- Get a specific user
SELECT * FROM users WHERE id = 1;

-- Add a new user
INSERT INTO users (name, email) VALUES ('Ali', 'ali@example.com');

-- Update a user
UPDATE users SET name = 'Ahmed Ali' WHERE id = 1;

-- Delete a user
DELETE FROM users WHERE id = 1;

-- Get all orders for a user (JOIN)
SELECT users.name, orders.product, orders.amount
FROM users
JOIN orders ON users.id = orders.user_id
WHERE users.id = 1;

Learn SQL. It's not optional. Every backend framework uses SQL under the hood, even when they hide it behind an ORM.

Key SQL Concepts You Must Know

Primary Key: The unique ID for each row (usually id).
Foreign Key: A column that references another table's primary key (like user_id).
Index: A shortcut that makes searching faster. Like a book's index — instead of reading every page, you jump straight to the right one.
Transactions: A way to group multiple operations. Either ALL of them succeed, or NONE of them do. Think of transferring money: subtract from account A AND add to account B. You can't do just one.
Normalization: Organizing data to avoid repetition. Instead of writing "Ahmed, ahmed@email.com" on every order, you just reference user_id = 1.
Migrations: Version control for your database structure. When you need to add a new column, you write a migration file. This way, everyone on the team can update their database.

NoSQL Databases

These don't use tables. Instead, they use different structures:

Document DBs (MongoDB): Store data as JSON-like documents. Good for flexible or nested data.

  {
    "_id": "abc123",
    "name": "Ahmed",
    "email": "ahmed@example.com",
    "orders": [
      { "product": "Laptop", "amount": 999 },
      { "product": "Mouse", "amount": 25 }
    ]
  }

Key-Value (Redis): Super simple. A key and a value. Blazing fast. Used for caching.

  "session:user42" → "{ loggedIn: true, name: 'Ahmed' }"

When to use what? Start with PostgreSQL. It handles 95% of use cases. Use Redis for caching. Use MongoDB only if your data truly doesn't fit into tables. Don't overcomplicate your first projects.

7. APIs — How Systems Talk to Each Other

An API (Application Programming Interface) is a set of rules that lets different software talk to each other. Your backend's main job is to expose an API that frontends (or other services) can use.

REST — The Most Common API Style

REST isn't a technology — it's a set of conventions for designing APIs using HTTP:

Action	Method	URL	What it does
List all users	GET	/api/users	Returns an array of users
Get one user	GET	/api/users/42	Returns user with id 42
Create a user	POST	/api/users	Creates a new user
Update a user	PUT	/api/users/42	Replaces user 42's data
Delete a user	DELETE	/api/users/42	Removes user 42

REST is just a pattern. It works the same in Express, Django, Spring, Laravel — everywhere.

JSON — The Universal Data Format

JSON (JavaScript Object Notation) is how APIs send data. Even non-JavaScript APIs use it:

{
  "id": 42,
  "name": "Ahmed",
  "isActive": true,
  "tags": ["developer", "student"],
  "address": {
    "city": "Alexandria",
    "country": "Egypt"
  }
}

API Design Best Practices

Use nouns for URLs, not verbs: /users not /getUsers
Use plural names: /users not /user
Use HTTP methods for actions (GET, POST, etc.) instead of putting the action in the URL
Return proper status codes: don't return 200 OK when something failed
Use pagination for lists: /users?page=2&limit=20
Be consistent: if one endpoint uses camelCase, all should

GraphQL — The Alternative

REST makes you hit multiple endpoints to get related data. GraphQL lets you ask for exactly what you want in one request:

query {
  user(id: 42) {
    name
    email
    orders {
      product
      amount
    }
  }
}

Learn REST first. It's the standard. GraphQL is nice to know later.

8. Authentication & Authorization

These are two different things and mixing them up is a classic mistake.

Authentication (AuthN): "Who are you?" → Proving your identity (logging in)
Authorization (AuthZ): "What are you allowed to do?" → Checking permissions

How Login Works (The Real Flow)

1. User sends POST /login with { email, password }
2. Server finds the user in the database
3. Server checks: does the hashed password match?
4. If yes → Server creates a TOKEN (a signed string)
5. Server sends the token back to the client
6. Client stores the token (usually in memory or a cookie)
7. On every future request, client sends the token in the Authorization header
8. Server reads the token, verifies it's valid and not expired
9. Server now knows who this user is

Passwords — Never Store Plain Text

When a user creates a password, you hash it (turn it into a scrambled string that can't be reversed):

Password: "mypassword123"
Hashed:   "$2b$10$N9qo8uLOickgx2ZMRZoMye..."

When they log in, you hash what they typed and compare it to the stored hash. You never know their actual password. This means if your database gets stolen, the attacker can't read passwords.

Use bcrypt or argon2. Every language has a library for this.

JWT (JSON Web Tokens)

A JWT is a token that contains information about the user, signed with a secret key:

Header.Payload.Signature

The payload might be: { userId: 42, role: "admin", exp: 1234567890 }

The server can verify this token without checking the database every time. The signature proves it wasn't tampered with.

Sessions vs Tokens

Sessions: Server stores login state in memory or a database. The client gets a session ID cookie. Server-side state.
Tokens (JWT): Client holds the token. Server is stateless — it just verifies the signature. No server-side state needed.

Both are valid. Tokens are more popular for APIs; sessions are more traditional for web apps.

OAuth 2.0 — "Login with Google/GitHub"

OAuth lets users log into your app using their Google/GitHub/etc. account. You don't handle their password at all. The basic flow: your app redirects to Google → user logs in there → Google sends a code back to your app → your app exchanges that code for user info.

9. Caching — Making Things Fast

Caching means storing frequently used data in a fast place so you don't have to recalculate or re-fetch it every time.

Where Caching Happens

Browser Cache: The browser stores static files (images, CSS, JS) so it doesn't download them again.
CDN Cache: A Content Delivery Network stores your files on servers worldwide, so a user in Egypt gets served from a nearby server instead of one in the US.
Application Cache (Redis/Memcached): Your server stores frequently accessed data in memory. Way faster than hitting the database.
Database Cache: The database itself caches frequent queries.

Example: Why Caching Matters

Without cache:

User requests GET /popular-products
→ Server runs a complex database query (200ms)
→ This happens for EVERY user, EVERY time
→ 1000 users/second = 1000 database queries/second = 💀

With cache:

First request: GET /popular-products
→ Server runs the query (200ms)
→ Server stores the result in Redis with a 5-minute expiration
→ Returns result

Next 999 requests in 5 minutes:
→ Server checks Redis first (1ms)
→ Data is there! Returns it instantly
→ Database rests peacefully

Cache Invalidation

The hardest problem in caching: when do you update the cache? If you cache product prices and then change a price, users might see stale data. Strategies include time-based expiration (cache for 5 minutes), event-based invalidation (clear cache when data changes), and cache-aside (check cache first, fall back to database).

10. Security Basics

If you build a backend, you're responsible for protecting user data. Here are the most important threats:

SQL Injection

The attacker puts SQL code inside your input fields:

Login form: email = "admin@site.com" password = "' OR 1=1 --"

If you build SQL strings by concatenating user input, this can expose your entire database. Never do this. Always use parameterized queries or your framework's ORM.

Cross-Site Scripting (XSS)

The attacker injects JavaScript into your site that runs in other users' browsers. For example, putting <script>steal(cookies)</script> in a comment field. Always sanitize user input and escape HTML.

Cross-Site Request Forgery (CSRF)

The attacker tricks a logged-in user into making a request they didn't intend. Like clicking a link that secretly transfers money. Use CSRF tokens — every framework has built-in protection.

Rate Limiting

Without rate limiting, someone can send millions of requests to your server (DDoS), or try millions of passwords (brute force). Limit how many requests one IP can make per minute.

HTTPS Everywhere

Always use HTTPS. Never HTTP. HTTPS encrypts data between the client and server so nobody in the middle can read it. Free certificates from Let's Encrypt make this a no-brainer.

The OWASP Top 10

OWASP maintains a list of the top 10 web security risks. Read it, understand it, and check your apps against it. This is a checklist every professional developer uses.

11. Architecture Patterns

As your app grows, how you organize your code matters more and more.

Monolith

Everything in one big application. One codebase, one deployment. Start here. It's simpler, easier to debug, and perfect for learning and small-to-medium apps.

Microservices

Breaking your app into small, independent services that communicate over the network. The Users service, Orders service, and Payments service are separate apps. Don't do this until you have a reason to. It adds massive complexity. Companies like Netflix and Amazon use it because they have thousands of developers — not because it's always better.

MVC (Model-View-Controller)

The most common pattern inside any backend:

Model: Represents your data (the User class, the Order class)
View: What the user sees (HTML pages, or JSON responses for APIs)
Controller: Handles requests, calls the right models, returns the right views

Almost every framework is built around MVC. Rails, Laravel, Django, Spring MVC — they're all variations of this.

Event-Driven Architecture

Instead of services calling each other directly, they publish events to a message queue (like RabbitMQ or Kafka). Other services listen and react.

Example: When someone places an order, the Order Service publishes an "OrderPlaced" event. The Email Service hears it and sends a confirmation. The Inventory Service hears it and updates stock. They don't know about each other — they just react to events.

This is an advanced pattern. Learn it conceptually now; implement it when you need it.

12. Networking Essentials

The OSI Model (Simplified)

You don't need to memorize all 7 layers. Just know the ones that matter for backend:

Application Layer (HTTP, HTTPS, WebSocket): Where your code lives. You deal with requests and responses.
Transport Layer (TCP, UDP): TCP guarantees delivery. UDP is faster but doesn't guarantee (used for video calls, gaming).
Network Layer (IP): Routing data between machines using IP addresses.

WebSockets

HTTP is one-way: client asks, server responds. But what about live chat, real-time notifications, or live scores? That's where WebSockets come in.

A WebSocket is a persistent connection between client and server. Both can send messages at any time, without the client having to ask first. Think of HTTP as sending letters and WebSockets as a phone call — the line stays open.

Load Balancing

When one server can't handle all the traffic, you add more servers and put a load balancer in front of them. The load balancer distributes incoming requests across your servers. It's like having multiple checkout lines at a supermarket.

Common strategies: round-robin (take turns), least connections (send to the least busy server), or IP hash (same user always goes to the same server).

13. Linux & The Command Line

Most servers run Linux. You don't need to be a Linux expert, but you need to be comfortable in the terminal.

Essential Commands

# Navigation
pwd                  # Where am I?
ls                   # What's in this folder?
cd /path/to/folder   # Go to a folder
cd ..                # Go up one level

# Files
cat file.txt         # Show file contents
nano file.txt        # Edit a file
cp file.txt copy.txt # Copy a file
mv old.txt new.txt   # Rename/move
rm file.txt          # Delete a file (careful!)

# Searching
grep "error" log.txt # Find lines containing "error"
find . -name "*.js"  # Find all .js files

# Processes
ps aux               # Show running processes
top                  # Live process monitor
kill 1234            # Kill process with ID 1234

# Networking
curl http://example.com  # Make an HTTP request
ping google.com          # Check if a server is reachable

# Permissions
chmod 755 script.sh  # Make a script executable

Package Managers

Ubuntu/Debian: apt install package-name
macOS: brew install package-name

SSH — Remote Server Access

SSH (Secure Shell) lets you control a remote server from your terminal:

ssh user@123.45.67.89

You'll use this constantly in your career to manage production servers.

14. Version Control (Git)

Git tracks changes to your code. It's not optional — it's required for every developer job.

Core Concepts

Repository (Repo): Your project folder, tracked by Git
Commit: A snapshot of your code at a point in time, with a message explaining what changed
Branch: A parallel version of your code. Work on features without affecting the main code
Merge: Combining two branches together
Pull Request (PR): A proposal to merge your changes, reviewed by teammates

Essential Commands

git init                    # Start tracking a project
git add .                   # Stage all changes
git commit -m "Add login"   # Save a snapshot
git branch feature-x        # Create a new branch
git checkout feature-x      # Switch to that branch
git merge feature-x         # Merge feature-x into current branch
git push origin main        # Upload to GitHub
git pull origin main        # Download latest changes
git log --oneline           # See commit history
git status                  # See what's changed

Branching Strategy

The most common: main is production-ready. Create a branch for each feature. Merge back to main via pull request after review. Never commit directly to main.

15. Testing

Writing code that verifies your other code works correctly.

Types of Tests

Unit Tests: Test a single function in isolation. "Does my calculateTax(100) return 15?"
Integration Tests: Test multiple pieces working together. "Does my API endpoint actually save to the database and return the right response?"
End-to-End (E2E) Tests: Test the whole system from the user's perspective. "Can a user sign up, log in, and place an order?"

The Testing Pyramid

Write many unit tests (fast, cheap), some integration tests (medium), and few E2E tests (slow, expensive). Most of your bugs will be caught by unit tests.

Why Testing Matters

Without tests, every change you make could break something else without you knowing. With tests, you change code confidently. Tests are your safety net. Every serious company requires them.

16. DevOps Basics

DevOps is the bridge between writing code and running code in production.

Docker — Portable Environments

Docker packages your app and all its dependencies into a container. "It works on my machine" becomes "it works everywhere."

A Dockerfile is a recipe for building your container:

FROM node:20
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["node", "server.js"]

Now anyone can run your app with: docker build -t myapp . && docker run myapp

CI/CD — Automated Testing & Deployment

CI (Continuous Integration): Every time you push code, automated tests run. If they fail, you know before the code reaches production.

CD (Continuous Deployment): If tests pass, the code automatically gets deployed to production. No manual steps.

Tools: GitHub Actions, GitLab CI, Jenkins. GitHub Actions is the easiest to start with.

Cloud Basics

Your server needs to live somewhere. The big three cloud providers are AWS (Amazon), GCP (Google), and Azure (Microsoft). For starting out, simpler platforms like Railway, Render, or Fly.io let you deploy without cloud complexity.

17. The Learning Order (Roadmap)

Here's the order that makes sense. Don't jump ahead.

Phase 1: The Foundation (Weeks 1–6)

Pick ONE language (JavaScript/Node.js or Python — both are great)
Learn programming basics: variables, functions, loops, arrays, objects, classes
Understand how the internet works: HTTP, DNS, TCP/IP
Learn the command line basics
Learn Git basics

Phase 2: Databases & APIs (Weeks 7–12)

Learn SQL (PostgreSQL recommended)
Build a simple REST API with your language (Express for Node.js, Flask/FastAPI for Python)
Connect your API to a database
Learn about request/response, routing, middleware
Build a CRUD app (Create, Read, Update, Delete) — like a todo list or blog

Phase 3: Real-World Skills (Weeks 13–20)

Add authentication (JWT, password hashing)
Learn about validation and error handling
Add caching (Redis)
Learn basic security (SQL injection, XSS, CSRF)
Write unit tests
Build a bigger project (e-commerce API, social media API)

Phase 4: Production & Scale (Weeks 21–28)

Learn Docker
Deploy your app to the cloud
Set up CI/CD with GitHub Actions
Learn about logging and monitoring
Understand basic architecture patterns (MVC, microservices concepts)
Study system design basics

Phase 5: Level Up (Ongoing)

Learn a second framework to prove your concepts transfer
Study message queues (RabbitMQ/Kafka)
Learn GraphQL
Dive deeper into system design
Contribute to open source
Read other people's code

🎯 The Big Takeaway

Frameworks change every few years. JavaScript frameworks are born and die faster than you can learn them. But the concepts in this guide? They've been the same for decades and will stay the same for decades more.

HTTP hasn't changed. Databases still use SQL. Servers still handle request→process→response. Auth still uses tokens or sessions. Caching still makes things fast.

When you understand these fundamentals, picking up a new framework takes days, not months. You look at Spring and think "Oh, this is just their way of doing routing and middleware." You look at Django and think "This is just MVC with a different name."

You're not learning a framework. You're learning how computers talk to each other. The framework is just the language you write it in.

"The person who understands WHY will always lead the person who only knows HOW."

Good luck on your journey. You've already made the right decision by starting with the fundamentals. 🚀

credits: claude

You Don't Need a Mobile App. A Bot Might Be Enough

Mohamed Idris — Tue, 07 Apr 2026 19:14:04 +0000

You build websites. You're comfortable with APIs, databases, and deployments. But here's a thought — not everyone wants to visit a website.

Some users want the app to come to them. Open Telegram, tap a button, done. No downloads, no signups, no "allow notifications" popup.

That's where bots fit in.

The gap between websites and apps

You build a website for your idea. It works great on desktop. Maybe okay on mobile. But your target audience — say, kids or busy parents — won't bookmark it. They won't come back every day. They need a nudge.

A mobile app would solve this, but I'm not familiar with mobile development, and there are two platforms to deal with. App store reviews. Updates. It's a whole different world.

A bot? You can build one in a weekend on Discord or Telegram with the same stack you already know — TypeScript, Node.js, and a database.

What I built

I recently built NumNinjas — a math practice bot for kids aged 10-12. The idea is simple: 3 math questions every day, sent straight to Telegram.

Here's what it does:

Kids open the bot, take a quick quiz, and get placed in a level
Every day at 2:30 PM they get 3 personalized questions (adaptive difficulty)
Questions use real-life scenarios — shopping, cooking, sports, not boring textbook stuff
5 ninja belt levels, points, streaks, and weekly leaderboards
Parents get a weekly progress report every Sunday
Available in Arabic and English

The bot handles the daily engagement. The website handles everything else — public leaderboards, player profiles, and an admin panel for managing questions.

Demo video: https://youtu.be/6CjTg_NaghM

The tech stack

Nothing exotic:

Bot: TypeScript + Grammy (Telegram framework) + node-cron for scheduled jobs
Website: Next.js 15 (App Router, Server Components)
Database: Prisma 7 + MySQL
Shared logic: pnpm monorepo — bot and website share the same database package
Deployment: Railway (bot) + Hostinger (website) + Cloudflare (CDN)

Both apps deploy from the same GitHub repo. Push to main, both auto-deploy.

Why a bot instead of just a website?

Three reasons:

Zero friction. Telegram is already on the phone. No download, no signup. Open the bot, tap start, you're solving math in 30 seconds.
Push, don't pull. The bot sends questions to the user at 2:30 PM. The user doesn't need to remember to visit a website. The app comes to them.
It's just an API. If you can build a REST API, you can build a bot. Grammy (or discord.js for Discord) gives you a clean way to handle commands, buttons, and callbacks. It's event-driven — think Express routes but for chat messages.

If you want to try

Building a bot is easier than you think. Start with:

A simple command handler (/start, /help)
An inline keyboard (buttons the user taps)
A database to store user state

That's it. You can add complexity later — scheduled messages, adaptive algorithms, leaderboards. But the core is just: receive message → process → reply.

If you're a web developer looking for a side project that's not "another todo app," try building a bot. Your users will thank you.

Try NumNinjas:

🤖 Bot: https://t.me/NumNinjasBot?start=go
🌐 Website: https://numninjas.com

Some lessons of work culture

Mohamed Idris — Wed, 01 Apr 2026 12:28:19 +0000

There's a layer underneath the actual work — the culture layer.
It quietly shapes how you spend your days, how you get paid,
and whether people see you as reliable or just available.

You pick it up as you go, and here are some of them.

1. You are the client's teammate, not their vendor

This one took me a moment to really internalize.

In a dedicated team setup, you're embedded inside the client's world. You're not sending deliverables from the outside — you're sitting (virtually) at their table, in their Jira, joining their standups, and sometimes getting pulled into their internal drama.

That means how you communicate matters a lot. No matter what's happening behind the scenes on your end, you show up polished and professional. The client doesn't need to feel your internal chaos. They just need to feel like you've got it.

And in some cases — when you're meeting the client's own clients — you represent the agency, not your home company. That's a different hat, and you wear it clean. You don't introduce yourself as an outsider. You're just part of the team.

2. Ticket updates are a form of respect

This one seems small but it's actually huge.

Every ticket you touch deserves a comment. Not an essay — just a clear, honest update on where things stand. Especially if a task is running longer than expected, or you've hit a blocker, or you're waiting on someone else.

It keeps everyone aligned without anyone having to ask. And asking "what's the status?" is low-key one of the most annoying things in collaborative work. A well-placed comment saves a whole Slack thread, a status meeting, and someone's afternoon.

Think of it this way: your ticket trail is a real-time changelog of your workday. Keep it readable.

3. Time logging is not optional — and it protects you

Time logging felt like admin overhead at first. Then I realized: this is actually how you get paid correctly, and how disputes never happen.

When your logged hours match the client's records exactly, there's nothing to argue about. When they don't, things get messy — and you're the one who has to untangle it, usually at the worst possible moment.

Log daily. Screenshot on Fridays and at the end of the month. It's a five-minute habit that saves hours of stress later. Future you will be quietly grateful.

4. No tickets ≠ free time. It's a signal to act.

One of the clearest lessons from this kind of work: if you don't have anything to do, say something immediately.

Don't wait. Don't assume the backlog will magically refill. Tell your PM or TL right away. In the meantime, look at old tickets, read through upcoming sprint items, think about edge cases you haven't tested, or review code you wrote two weeks ago with fresh eyes.

There's usually always something. And if there genuinely isn't — that's a process too. There's a ticket for idle time, your manager needs to know, and it gets logged properly. It's not embarrassing. It's just how an honest system works.

5. Holiday bonuses and overtime exist — but you have to speak up first

Want to work a national holiday for double pay? Totally possible. But you need to let the team know well in advance — not the morning of.

Same with overtime. If a client asks you to push extra hours, don't just do it and hope it shows up correctly in your paycheck. Communicate it first. Get it approved. That way the rate gets negotiated properly with the client, and you actually see it reflected in what you earn.

The system works for you when you engage with it early. Stay quiet and you're basically leaving money on the table.

6. Vacation notice is longer than you think

Two weeks notice for most of the year. Four weeks during the busy summer months and around Christmas.

That sounds like a lot until you consider that a client team is built around your availability. Sprint planning, ticket assignment, standups — your absence has a ripple effect. Giving plenty of notice isn't bureaucracy for the sake of it. It's just keeping things fair for everyone involved, including you.

Book early, tell people early, come back rested.

7. Sick days have a process too — follow it immediately

Nobody plans to get sick. But when it happens, the instinct to "just rest and deal with it tomorrow" can cause more hassle than it's worth.

The right move: inform your PM on the client's side first, then email HR as soon as possible. Not later. Not when you feel better. Right away.

Why? Because other people are rearranging their day around your absence. And your sick leave needs to be processed correctly so your paycheck isn't affected. Both of those things depend on timely communication.

8. Knowing when to ask for help is a skill

Working embedded in a client team can sometimes feel isolating — you're technically part of two organizations but not fully home in either one. It's easy to sit on a problem too long because you're not sure who to ask.

What I learned: when in doubt, ask your direct manager or department lead. Not a week later. Not after you've already gone in circles. Just ask.

Good teams have a clear escalation path for a reason. Use it. Being resourceful is great, but spinning your wheels alone isn't.

The bigger picture

Working in a dedicated team taught me that being a good developer isn't just about writing clean code.

It's about communicating clearly, logging honestly, showing up reliably, and understanding that you're part of something bigger than a single ticket. The "soft stuff" is actually load-bearing. Strip it away and even great code doesn't hold up the way it should.

If you're moving into this kind of role — or already in one — I hope something here clicked for you.

Credits: Scandiweb

Why Chrome Draws a Dark Line on Your CSS Scalloped Edge (and How to Fix It)

Mohamed Idris — Sat, 21 Mar 2026 23:10:01 +0000

You've built a scalloped (wavy) edge using a repeating radial-gradient on a pseudo-element. It looks perfect in Firefox. You open Chrome, and there's a faint dark line running along the entire edge.

This is a Chrome sub-pixel rendering bug, and it comes down to one thing: what transparent actually means in CSS.

The Setup

A typical scalloped edge uses a repeating radial gradient to punch semi-circular cutouts into a solid strip:

.element::after {
  content: '';
  position: absolute;
  width: 14px;
  height: 100%;

  background: radial-gradient(
    ellipse 10px 8px at 0 50%,
    transparent 99%,
    #1a3a2a 100%
  );
  background-size: 14px 20px;
  background-repeat: repeat-y;
}

The center of each ellipse is transparent (the cutout), the outside is your solid color. The 99% → 100% creates a near-hard stop with just enough room for anti-aliasing.

Why Chrome Shows a Line

transparent in CSS is rgba(0, 0, 0, 0) — transparent black.

When Chrome interpolates between transparent and your color at that gradient boundary, it mixes through black. Even though the transition space is tiny, Chrome renders a visible sub-pixel line of the intermediate color:

transparent = rgba(0, 0, 0, 0)   ← black at zero alpha
your color  = rgba(26, 58, 42, 1)

Chrome blends through that black → dark line artifact

Firefox handles this boundary more gracefully — no visible artifact.

What Didn't Work: color-mix()

The intuitive fix is to replace transparent with a zero-opacity version of your actual color so Chrome blends between the same hue:

background: radial-gradient(
  ellipse 10px 8px at 0 50%,
  color-mix(in srgb, #1a3a2a 0%, transparent) 99%,
  #1a3a2a 100%
);

In theory, this eliminates the black-channel bleed. In practice, the line persisted — Chrome's sub-pixel rendering still produced a visible artifact at the gradient boundary.

What Works: CSS Masks

The fix is to separate color from shape. Instead of using the gradient for both, make the background a flat solid color and move the shape into a mask-image.

Option 1: Gradient Mask

The quickest change — move the same gradient from background to mask-image:

.element::after {
  content: '';
  position: absolute;
  width: 14px;
  height: 100%;

  /* Flat color — nothing to interpolate */
  background: #1a3a2a;

  /* Shape defined by mask alpha channel only */
  mask-image: radial-gradient(
    ellipse 10px 8px at 0 50%,
    transparent 99%,
    #000 100%
  );
  mask-size: 14px 20px;
  mask-repeat: repeat-y;
}

CSS masks only read the alpha channel. The gradient transitions from alpha 0 to alpha 1 — a pure opacity operation with no color data for Chrome to mix through. No color mixing → no dark line.

Option 2: SVG Mask (More Control)

If you need precise control over scallop shape — like elongated bumps or specific aspect ratios — an inline SVG mask gives you that:

.element::after {
  content: '';
  position: absolute;
  width: 20px;
  height: 100%;

  background-color: inherit;

  mask-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'
    width='20' height='28'%3E%3Cdefs%3E%3Cmask id='m'%3E%3Crect width='20'
    height='28' fill='white'/%3E%3Cellipse cx='0' cy='14' rx='10' ry='12'
    fill='black'/%3E%3C/mask%3E%3C/defs%3E%3Crect width='20' height='28'
    mask='url(%23m)' fill='white'/%3E%3C/svg%3E");
  mask-size: 20px 28px;
  mask-repeat: repeat-y;
}

Here's the decoded SVG for clarity:

<svg xmlns="http://www.w3.org/2000/svg" width="20" height="28">
  <defs>
    <mask id="m">
      <rect width="20" height="28" fill="white"/>
      <ellipse cx="0" cy="14" rx="10" ry="12" fill="black"/>
    </mask>
  </defs>
  <rect width="20" height="28" mask="url(#m)" fill="white"/>
</svg>

White areas are visible, the black ellipse is cut out. You can tweak rx and ry independently to control scallop width and height, or swap in a <path> for non-circular shapes. Both approaches fix the Chrome line for the same reason: flat background color + mask handles shape through alpha only.

Summary

Approach	Result in Chrome
`transparent` keyword in gradient	Dark line (blends through black)
`color-mix()` to 0% opacity	Still a line (sub-pixel rendering)
`mask-image` (gradient or SVG) with solid background	Clean

If you have a radial-gradient scalloped edge showing a line in Chrome, move the shape to mask-image and set background to your solid color. Use a gradient mask for a quick fix, or an SVG mask when you need precise control over the scallop shape. Either way, masks eliminate color interpolation entirely — which is the root cause.

How I Fixed My Masonry Layout on Mobile Using window.matchMedia

Mohamed Idris — Sat, 21 Mar 2026 06:47:25 +0000

Have you ever built a nice two-column layout, only to realize it looks broken on mobile?

That happened to me. Here's what went wrong and how I fixed it — step by step.

The Problem

I had a Kudos page — a wall of feedback cards from colleagues. On desktop, I wanted a masonry layout (two columns, cards stacked like bricks). On mobile, just a simple list — one card per row.

My first approach: split the cards into two arrays (even/odd) and render them as two columns.

const columns = [
  kudos.filter((_, i) => i % 2 === 0), // left column
  kudos.filter((_, i) => i % 2 === 1), // right column
];

This gives a nice masonry effect:

Desktop (md+)
┌─────────┐  ┌─────────┐
│ Card 0  │  │ Card 1  │
│         │  └─────────┘
└─────────┘  ┌─────────┐
┌─────────┐  │ Card 3  │
│ Card 2  │  │         │
└─────────┘  │         │
             └─────────┘

Reading order: 0 → 1 → 2 → 3. Correct!

But on mobile, these two column divs stack vertically. So you get:

Mobile (broken)
┌─────────┐
│ Card 0  │  ← left column first
├─────────┤
│ Card 2  │
├─────────┤
│ Card 4  │
├─────────┤
│ Card 1  │  ← then right column
├─────────┤
│ Card 3  │
└─────────┘

Cards are out of order. Not great.

Attempt 1: Render Everything Twice

My first fix was to render two versions — one for mobile, one for desktop — and toggle with CSS:

{/* Mobile: simple list */}
<div className="flex flex-col gap-5 md:hidden">
  {kudos.map(kudo => <KudoCard kudo={kudo} />)}
</div>

{/* Desktop: masonry */}
<div className="hidden md:flex gap-5">
  {columns.map(col => (
    <div className="flex-1 flex flex-col gap-5">
      {col.map(kudo => <KudoCard kudo={kudo} />)}
    </div>
  ))}
</div>

This works visually! But there's a problem:

Every card exists twice in the DOM. One copy is hidden, but it's still there. That's wasted memory and DOM nodes for no reason.

Attempt 2: CSS Columns

CSS has a built-in masonry-like feature: columns.

<div className="columns-1 md:columns-2 gap-5">
  {kudos.map(kudo => (
    <div className="break-inside-avoid">
      <KudoCard kudo={kudo} />
    </div>
  ))}
</div>

Single render, responsive, clean. But...

CSS columns fills top to bottom per column, not left to right:

CSS columns reading order
┌─────────┐  ┌─────────┐
│ Card 0  │  │ Card 3  │
├─────────┤  ├─────────┤
│ Card 1  │  │ Card 4  │
├─────────┤  ├─────────┤
│ Card 2  │  │ Card 5  │
└─────────┘  └─────────┘

You read 0, 1, 2... then jump to 3, 4, 5. The reading order is broken on desktop. Back to square one.

The Fix: `window.matchMedia`

The solution: use JavaScript to detect the screen size and render only one layout at a time.

What is `window.matchMedia`?

It's like CSS @media queries, but in JavaScript.

const result = window.matchMedia('(min-width: 768px)');

result.matches;  // true or false right now
result.addEventListener('change', callback);  // fires when it changes

That's it. You give it a media query string, and it tells you:

Does it match right now? → .matches
Tell me when it changes → .addEventListener('change', ...)

Using it in React

const MD_BREAKPOINT = '(min-width: 768px)';

function Kudos() {
  const [isMd, setIsMd] = useState(
    () => window.matchMedia(MD_BREAKPOINT).matches,
  );

  useEffect(() => {
    const mql = window.matchMedia(MD_BREAKPOINT);
    const onChange = (e) => setIsMd(e.matches);
    mql.addEventListener('change', onChange);
    return () => mql.removeEventListener('change', onChange);
  }, []);

  return isMd ? <MasonryLayout /> : <SimpleList />;
}

Here's what happens:

On mount — check if the screen is >= 768px
Set up a listener — when the user resizes across 768px, update state
Clean up — remove the listener when the component unmounts
Render one layout — masonry or simple list, never both

The variable name `mql`

You'll see mql a lot in code. It stands for Media Query List — that's the type of object matchMedia() returns. It's a common shorthand, like e for event or el for element.

The Final Code

const MD_BREAKPOINT = '(min-width: 768px)';
const reversed = [...kudos].reverse();
const columns = [
  reversed.filter((_, i) => i % 2 === 0),
  reversed.filter((_, i) => i % 2 === 1),
];

function Kudos() {
  const [isMd, setIsMd] = useState(
    () => window.matchMedia(MD_BREAKPOINT).matches,
  );

  useEffect(() => {
    const mql = window.matchMedia(MD_BREAKPOINT);
    const onChange = (e) => setIsMd(e.matches);
    mql.addEventListener('change', onChange);
    return () => mql.removeEventListener('change', onChange);
  }, []);

  return (
    <>
      {isMd ? (
        <div className="flex gap-5">
          {columns.map((col, i) => (
            <div key={i} className="flex-1 flex flex-col gap-5">
              {col.map((kudo) => (
                <KudoCard key={kudo.id} kudo={kudo} />
              ))}
            </div>
          ))}
        </div>
      ) : (
        <div className="flex flex-col gap-5">
          {reversed.map((kudo) => (
            <KudoCard key={kudo.id} kudo={kudo} />
          ))}
        </div>
      )}
    </>
  );
}

Notice that reversed and columns are outside the component. Since kudos is static data that never changes, there's no reason to recompute these on every render.

Quick Comparison

Approach	Correct Order	Single DOM	Masonry
CSS `flex-col` / `flex-row`	Mobile breaks	Yes	Yes
Render twice + hide	Yes	No (2x nodes)	Yes
CSS `columns`	Desktop breaks	Yes	Yes
`matchMedia`	Yes	Yes	Yes

Key Takeaways

CSS columns fills top-to-bottom, not left-to-right. Great for text, tricky for ordered content.
Rendering twice and hiding with CSS works but doubles your DOM nodes.
window.matchMedia lets you use media queries in JS — render different layouts without duplication.
Hoist static computations outside your component. If the data never changes, don't recompute it on every render.

CSS Masonry Layout in 2 Minutes (No JS Needed)

Mohamed Idris — Thu, 19 Mar 2026 18:54:44 +0000

You have cards with different content lengths. CSS Grid makes them all the same height per row, leaving ugly empty space. Here's how to fix that with pure CSS.

The Problem: Grid = Equal Row Heights

With CSS Grid, cards in the same row are forced to the same height:

CSS Grid:
┌──────────────┐  ┌──────────────┐
│ Short card   │  │ Tall card    │
│              │  │ with lots of │
│  (wasted     │  │ content that │
│   space!)    │  │ fills the    │
│              │  │ whole card   │
└──────────────┘  └──────────────┘
┌──────────────┐  ┌──────────────┐
│ Medium card  │  │ Tiny         │
│ with some    │  │              │
│ content      │  │  (wasted     │
│              │  │   space!)    │
└──────────────┘  └──────────────┘

The short card stretches to match its tall neighbor. Wasted space everywhere.

Copy this into an HTML file and see it yourself:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>The Problem</title>
  <style>
    body { font-family: system-ui, sans-serif; padding: 2rem; background: #f5f5f5; }

    .grid {
      display: grid;
      grid-template-columns: repeat(2, 1fr);
      gap: 1rem;
    }

    .card {
      padding: 1.5rem;
      background: white;
      border-radius: 0.75rem;
      border: 1px solid #e5e5e5;
    }
  </style>
</head>
<body>
  <h1>The Problem: CSS Grid</h1>
  <p style="margin-bottom: 1rem; color: #666;">Notice how short cards stretch to match tall ones in the same row.</p>

  <div class="grid">
    <div class="card">
      <h3>Short card</h3>
      <p>Just a few words.</p>
    </div>
    <div class="card">
      <h3>Tall card</h3>
      <p>This card has way more content. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus lacinia odio vitae vestibulum. Cras vehicula risus quis vulputate arcu.</p>
    </div>
    <div class="card">
      <h3>Medium card</h3>
      <p>Some content here, not too much.</p>
    </div>
    <div class="card">
      <h3>Tiny card</h3>
      <p>Hi.</p>
    </div>
  </div>
</body>
</html>

The Fix: CSS Columns

Replace the grid with two CSS properties and each card takes only the height it needs:

CSS Columns:
┌──────────────┐  ┌──────────────┐
│ Short card   │  │ Tall card    │
└──────────────┘  │ with lots of │
┌──────────────┐  │ content that │
│ Medium card  │  │ fills the    │
│ with some    │  │ whole card   │
│ content      │  └──────────────┘
└──────────────┘  ┌──────────────┐
┌──────────────┐  │ Tiny         │
│ Another one  │  └──────────────┘
└──────────────┘

No wasted space! Each card = its own height.

Here's the code:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>CSS Masonry</title>
  <style>
    body { font-family: system-ui, sans-serif; padding: 2rem; background: #f5f5f5; }

    .masonry {
      columns: 2;           /* split into 2 columns */
      gap: 1rem;
    }

    .card {
      break-inside: avoid;  /* don't split a card across columns */
      margin-bottom: 1rem;
      padding: 1.5rem;
      background: white;
      border-radius: 0.75rem;
      border: 1px solid #e5e5e5;
    }

    @media (max-width: 640px) {
      .masonry { columns: 1; }
    }
  </style>
</head>
<body>
  <h1>The Fix: CSS Columns</h1>
  <p style="margin-bottom: 1rem; color: #666;">Each card takes only the height it needs. No stretching.</p>

  <div class="masonry">
    <div class="card">
      <h3>Short card</h3>
      <p>Just a few words.</p>
    </div>
    <div class="card">
      <h3>Tall card</h3>
      <p>This card has way more content. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus lacinia odio vitae vestibulum. Cras vehicula risus quis vulputate arcu.</p>
    </div>
    <div class="card">
      <h3>Medium card</h3>
      <p>Some content here, not too much.</p>
    </div>
    <div class="card">
      <h3>Tiny card</h3>
      <p>Hi.</p>
    </div>
    <div class="card">
      <h3>Another tall one</h3>
      <p>More content to show the layout handles varying heights gracefully. Cards flow top-to-bottom in each column, like reading a newspaper.</p>
    </div>
    <div class="card">
      <h3>Last one</h3>
      <p>Done!</p>
    </div>
  </div>
</body>
</html>

That's it. columns: 2 + break-inside: avoid. Done.

But Wait: Expandable Cards Break It

If your cards have a "Read more" button that expands content, CSS columns rebalance all cards when one changes height. Everything shifts around:

BEFORE clicking "Read more":        AFTER clicking "Read more":
┌──────────────┐ ┌──────────────┐   ┌──────────────┐ ┌──────────────┐
│ Card 1       │ │ Card 3       │   │ Card 1       │ │ Card 4       │
│ [Read more]  │ └──────────────┘   │ now expanded  │ │ [Read more]  │
└──────────────┘ ┌──────────────┐   │ with all the  │ └──────────────┘
┌──────────────┐ │ Card 4       │   │ full text     │ ┌──────────────┐
│ Card 2       │ │ [Read more]  │   │ showing...    │ │ Card 5       │
└──────────────┘ └──────────────┘   │ [Show less]   │ └──────────────┘
┌──────────────┐ ┌──────────────┐   └──────────────┘
│ Card 3  ←─── jumped from      │   ┌──────────────┐
└──────────────┘  right column!     │ Card 2       │
                                    └──────────────┘
                                    ← Cards 2-5 all moved!

Try it yourself:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>The Reflow Bug</title>
  <style>
    body { font-family: system-ui, sans-serif; padding: 2rem; background: #f5f5f5; }

    .masonry {
      columns: 2;
      gap: 1rem;
    }

    .card {
      break-inside: avoid;
      margin-bottom: 1rem;
      padding: 1.5rem;
      background: white;
      border-radius: 0.75rem;
      border: 1px solid #e5e5e5;
    }

    .card-text {
      display: -webkit-box;
      -webkit-box-orient: vertical;
      overflow: hidden;
    }

    .card-text.clamped {
      -webkit-line-clamp: 2;
    }

    button {
      margin-top: 0.5rem;
      background: none;
      border: none;
      color: #3b82f6;
      cursor: pointer;
      font-size: 0.875rem;
    }
  </style>
</head>
<body>
  <h1>The Bug: Cards Shift on Expand</h1>
  <p style="margin-bottom: 1rem; color: #666;">Click "Read more" and watch ALL cards jump around.</p>

  <div class="masonry">
    <div class="card">
      <h3>Card 1</h3>
      <p class="card-text clamped">This card has a lot of text that gets clamped. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus lacinia odio vitae vestibulum vestibulum. Cras vehicula risus.</p>
      <button onclick="this.previousElementSibling.classList.toggle('clamped')">Read more</button>
    </div>
    <div class="card">
      <h3>Card 2</h3>
      <p>Short card. Watch me jump when you expand Card 1!</p>
    </div>
    <div class="card">
      <h3>Card 3</h3>
      <p>I'll move too.</p>
    </div>
    <div class="card">
      <h3>Card 4</h3>
      <p class="card-text clamped">Another long card. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus lacinia odio vitae vestibulum vestibulum.</p>
      <button onclick="this.previousElementSibling.classList.toggle('clamped')">Read more</button>
    </div>
    <div class="card">
      <h3>Card 5</h3>
      <p>Yet another card that will shift.</p>
    </div>
  </div>
</body>
</html>

Annoying, right? Here's the fix.

The Real Fix: Split Into Separate Columns

Instead of letting CSS decide which card goes where, you split them into independent columns. Now expanding a card only affects its own column:

BEFORE clicking "Read more":        AFTER clicking "Read more":

  Column 1        Column 2           Column 1        Column 2
┌──────────────┐ ┌──────────────┐   ┌──────────────┐ ┌──────────────┐
│ Card 1       │ │ Card 2       │   │ Card 1       │ │ Card 2       │
│ [Read more]  │ │ [Read more]  │   │ now expanded  │ │ [Read more]  │
└──────────────┘ └──────────────┘   │ with all the  │ └──────────────┘
┌──────────────┐ ┌──────────────┐   │ full text     │ ┌──────────────┐
│ Card 3       │ │ Card 4       │   │ showing...    │ │ Card 4       │
└──────────────┘ └──────────────┘   │ [Show less]   │ └──────────────┘
┌──────────────┐                    └──────────────┘
│ Card 5       │                    ┌──────────────┐
└──────────────┘                    │ Card 3       │  ← only Card 3
                                    └──────────────┘    moved down
                                    ┌──────────────┐
                                    │ Card 5       │  Column 2 is
                                    └──────────────┘  untouched!

Each column is its own flex container. They don't know about each other.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Stable Masonry</title>
  <style>
    body { font-family: system-ui, sans-serif; padding: 2rem; background: #f5f5f5; }

    .masonry {
      display: flex;
      gap: 1rem;
    }

    .column {
      flex: 1;
      display: flex;
      flex-direction: column;
      gap: 1rem;
    }

    .card {
      padding: 1.5rem;
      background: white;
      border-radius: 0.75rem;
      border: 1px solid #e5e5e5;
    }

    .card-text {
      display: -webkit-box;
      -webkit-box-orient: vertical;
      overflow: hidden;
    }

    .card-text.clamped {
      -webkit-line-clamp: 2;
    }

    button {
      margin-top: 0.5rem;
      background: none;
      border: none;
      color: #3b82f6;
      cursor: pointer;
      font-size: 0.875rem;
    }

    @media (max-width: 640px) {
      .masonry { flex-direction: column; }
    }
  </style>
</head>
<body>
  <h1>The Fix: Independent Columns</h1>
  <p style="margin-bottom: 1rem; color: #666;">Click "Read more" — only the same column moves. The other stays put.</p>

  <div class="masonry">
    <!-- Column 1: items 1, 3, 5 -->
    <div class="column">
      <div class="card">
        <h3>Card 1</h3>
        <p class="card-text clamped">This card has a lot of text. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus lacinia odio vitae vestibulum vestibulum. Cras vehicula risus.</p>
        <button onclick="this.previousElementSibling.classList.toggle('clamped')">Read more</button>
      </div>
      <div class="card">
        <h3>Card 3</h3>
        <p>I stay still when Card 2 expands!</p>
      </div>
      <div class="card">
        <h3>Card 5</h3>
        <p>Me too.</p>
      </div>
    </div>
    <!-- Column 2: items 2, 4 -->
    <div class="column">
      <div class="card">
        <h3>Card 2</h3>
        <p class="card-text clamped">Another long card. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus lacinia odio vitae vestibulum vestibulum.</p>
        <button onclick="this.previousElementSibling.classList.toggle('clamped')">Read more</button>
      </div>
      <div class="card">
        <h3>Card 4</h3>
        <p>Short and stable.</p>
      </div>
    </div>
  </div>
</body>
</html>

How it works: odd items (1, 3, 5) go in column 1, even items (2, 4) go in column 2. Each column is a separate flex container, so they don't affect each other.

Quick Reference

Need masonry?
│
├── Cards have fixed content?
│   └── ✅ Use CSS columns + break-inside: avoid
│
├── Cards expand/collapse?
│   └── ✅ Split into separate flex columns
│
└── All cards same height?
    └── ✅ Just use CSS Grid (no masonry needed)

Three examples you can copy-paste and try right now. That's the whole trick — no libraries needed!

Why BEM Nesting Breaks in Tailwind v4

Mohamed Idris — Wed, 18 Mar 2026 12:48:03 +0000

So today I spent sometime debugging why some CSS styles weren't applying. Turns out, Tailwind v4 quietly broke something on was working Tailwind v3.

What happened

I had CSS like this:

.dropdown {
  background: white;

  &--open {
    background: blue;
  }

  &__icon {
    width: 16px;
  }
}

In Tailwind v3, this worked perfectly. It would compile to:

.dropdown { background: white; }
.dropdown--open { background: blue; }
.dropdown__icon { width: 16px; }

But in Tailwind v4? Nothing. No error. No warning. It just silently does nothing.

Meanwhile, this still works fine:

.dropdown {
  &:hover { background: gray; }
  & .child { color: red; }
}

Wait, what? &:hover works but &--open doesn't? Why??

The reason

It comes down to native CSS nesting vs SASS nesting.

Native CSS (what browsers understand) supports & only for:

Pseudo-classes: &:hover, &:focus, &::before
Combinators: & .child, & > .child, & + .sibling
Chaining: &.another-class

SASS added an extra feature on top: using & to concatenate strings. So &--open inside .dropdown would glue them together into .dropdown--open. That's not real CSS — that's a SASS trick.

Tailwind v3 used postcss-nested under the hood, which copied the SASS behavior. So BEM nesting worked.

Tailwind v4 switched to Lightning CSS, which follows the real CSS nesting spec. No more string concatenation. BEM nesting just silently fails.

The fix

Simple. Just write the full class name:

/* Before (broken in v4) */
.dropdown {
  &--open {
    background: blue;
  }
  &__icon {
    width: 16px;
  }
}

/* After (works everywhere) */
.dropdown--open {
  background: blue;
}

.dropdown__icon {
  width: 16px;
}

You can still use nesting for the stuff native CSS supports:

.dropdown {
  &:hover {
    background: gray;
  }

  & .dropdown__icon {
    width: 16px;
  }
}

TL;DR

Syntax	Tailwind v3	Tailwind v4	Why
`&:hover`	works	works	Native CSS nesting
`& .child`	works	works	Native CSS nesting
`&--modifier`	works	broken	SASS feature, not native CSS
`&__element`	works	broken	SASS feature, not native CSS

Tailwind v4 uses Lightning CSS which follows the native CSS spec. BEM string concatenation with & is a SASS-only feature that native CSS doesn't support.

If you're migrating to Tailwind v4 and styles are silently disappearing, check for BEM nesting first.

How to Create the Perfect OG Image (With AI + A Simple Screenshot)

Mohamed Idris — Sun, 15 Mar 2026 14:56:50 +0000

What is an OG Image?

OG (Open Graph) image is the preview image that shows up when you share a link on social media, Slack, Discord, or any platform that unfurls URLs.

You've seen it hundreds of times — that card with an image, title, and description that appears when someone drops a link in a chat.

It's set with a simple meta tag in your HTML:

<meta property="og:image" content="/og-image.png" />

Why Should You Care?

Links with OG images get significantly more clicks
It makes your site look professional and intentional
Without one, platforms show a blank card or a random page element

The Easiest Way to Create One

You don't need Figma or Photoshop. Ask any AI (ChatGPT, Claude, etc.) to:

"Create an HTML file for an OG image with my name, title, and website URL. Use a dark background, 1200x630 dimensions."

You'll get a simple HTML file with a styled card. Open it in your browser, and screenshot it.

Here's a minimal example:

<!doctype html>
<html>
  <head>
    <style>
      body {
        margin: 0;
        display: flex;
        align-items: center;
        justify-content: center;
        height: 100vh;
        background: #111;
      }
      .card {
        width: 1200px;
        height: 630px;
        background: #1a1a2e;
        display: flex;
        flex-direction: column;
        align-items: center;
        justify-content: center;
        gap: 20px;
        font-family: system-ui, sans-serif;
      }
      .name { font-size: 56px; color: #fff; }
      .title { font-size: 28px; color: #888; }
    </style>
  </head>
  <body>
    <div class="card">
      <div class="name">Your Name</div>
      <div class="title">Your Title</div>
    </div>
  </body>
</html>

Taking a Pixel-Perfect Screenshot

Here's the trick — you can't just screenshot the browser window. You need exactly 1200x630 pixels.

Steps (Chrome):

Open the HTML file in Chrome
Open DevTools (F12)
Click the device toolbar icon (or Ctrl+Shift+M)
Set the dimensions to 1200 x 630

Now here's the part most people miss:

In the device toolbar, click the three dots menu (⋮)
Select "Add device pixel ratio"
Set it to 1.0

Without this step, if your display runs at 2x scaling (most modern laptops), your screenshot will be 2400x1260 instead of 1200x630.

Click the three dots menu (⋮) again → "Capture screenshot"

Done. You now have a pixel-perfect 1200x630 OG image.

Adding It to Your Site

Drop the image in your public folder (for Vite/Next.js) or root directory, then add these meta tags to your <head>:

<meta property="og:image" content="/og-image.png" />
<meta property="og:title" content="Your Name - Your Title" />
<meta property="og:description" content="A short description." />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:image" content="/og-image.png" />

Test It

After deploying, paste your URL into these tools to verify:

That's it. A 5-minute task that makes every shared link to your site look polished.

How to Move a Git Branch to a Different Parent

Mohamed Idris — Fri, 13 Mar 2026 11:55:53 +0000

You branched off feature-A, did your work, then realized your branch should have been based on main instead. Now your branch carries all of feature-A's commits along with yours.

Here's how to fix it in 4 steps.

The Problem

main ---- A ---- B
                  \
                   feature-A ---- C ---- D
                                          \
                                           your-branch ---- E  <-- your commit

You only want commit E, but your branch includes C and D from feature-A.

The Fix

1. Find your commit hash

git log --oneline your-branch --not main

This lists all commits on your branch that aren't in main. Identify yours — in this case, E.

2. Create a clean branch from main

git checkout main
git pull origin main
git checkout -b your-branch-clean

3. Cherry-pick your commit

git cherry-pick <commit-hash>

This applies only your commit on top of main.

4. Replace the old branch

git branch -D your-branch
git branch -m your-branch-clean your-branch
git push origin your-branch --force-with-lease

Result

main ---- A ---- B
                  \
                   your-branch ---- E

Clean branch, no extra baggage.

Why cherry-pick over rebase?

When your branch has merge commits and commits from another feature branch mixed in, git rebase can get messy — conflicts from commits that aren't even yours. Cherry-pick lets you grab exactly what you need and skip everything else.

Quick reminder

Use --force-with-lease instead of --force — it won't overwrite the remote if someone else pushed to your branch.
If you have multiple commits to move, cherry-pick accepts a range: git cherry-pick A^..B.

Business-Aware Development: What Every Developer Should Know Beyond Code

Mohamed Idris — Mon, 02 Mar 2026 15:10:10 +0000

As developers, we tend to live inside the code. But successful project delivery depends on much more — understanding quality signals, data flows between systems, and the architectural decisions that shape how a business runs online.

This post distills the key lessons from Scandiweb's Business-Aware Development course into a practical reference. Whether you work in eCommerce or not, these concepts apply anywhere software meets business.

Part 1: Manual QA — Thinking Like a Tester

What is a bug?

Anything that prevents the client from operating their business as intended. It can be a broken checkout button or a subtle typo that damages brand trust. Both matter.

The 6 bug types

1. Content — Text/content deviations from what's expected.

Spelling errors, untranslated text, placeholder content ("Lorem ipsum"), dead links, missing pages
Reporting: Describe the exact position on the page. Leave zero room for confusion.

2. Visual — Inconsistencies between the live site and approved designs.

Wrong fonts, colors, spacing, margins; missing hover states; content overflow; misaligned elements
Reporting: Include the URL, link to the design, and provide a side-by-side comparison. For responsive issues, include the screen resolution.

3. Cross-Browser — Works in one browser, breaks in another.

Reporting: Always include browser name and version. Without it, reproducing is nearly impossible.

4. Cross-Device — Same browser, different device, different result.

Reporting: Specify the exact device. Standard testing covers iPhones, Android phones, and tablets.

5. Functional — Behavior that doesn't work as intended or at all.

Filters not filtering, price mismatches, failed signups that show success, infinite checkout loaders
Reporting: A good title is 90% of the success. Always include steps to reproduce, actual result, and expected result.

6. Performance — Operations taking too long. General rule: nothing should exceed 2-3 seconds.

Check: page load (incognito, cleared cache), search speed, filter responsiveness, image sizes (~25-30KB per listing image), add-to-cart, checkout, login
Reporting: Include the URL, steps taken, and measured time.

Reporting rules

One issue per ticket — never group multiple bugs together
Browser version — only required for cross-browser bugs; put "ANY" for everything else
Priority — usually set by the PM, but use common sense (payments = always top priority)
Intermittent bugs — clearly flag if a bug doesn't reproduce consistently

You don't always need full specs

Use common sense. Check standard flows (search, filter, cart, checkout, login), verify essential pages exist (About Us, T&C, Shipping), and flag obvious inconsistencies. QA should be part of task definition before development, not just after.

Part 2: Data Flows & ERP Integration

Key concepts

SKU (Stock Keeping Unit) — A product's unique public identifier (e.g., NIKE-AIR-MAX-90-BLK-US10). It's the common language between warehouse, website, support, and ERP. When systems need to agree on "which product," they match on SKU.

ERP (Enterprise Resource Planning) — The backbone system that existed before the online store. It manages what eCommerce doesn't:

Warehouse management (trucks arrive, products scanned, stock updated)
Point of Sale (physical store registers)
Order processing & fulfillment
Accounting, tax reporting, business intelligence
Customer support & after-sales

The ERP is the "ugly but essential" internal system. The storefront is the "pretty face." Both need to sync.

Common order statuses:

Status	Meaning
Pending	Awaiting payment confirmation
Processing	Payment confirmed, being prepared
On Hold	Paused (stock issue, fraud review, etc.)
Shipped	Handed to carrier
Delivered	Customer received it
Cancelled	Cancelled before shipment
Refunded	Money returned
Closed	Complete, no open disputes

Why developers should care

If systems don't sync: customers buy out-of-stock items, the website shows stale prices, and 10,000 daily orders can't be manually copy-pasted into the ERP. "ERP integration" is really just data exchange — specific pieces of data traveling between two databases.

The ETL pattern: Extract, Transform, Load

Extract — Get data out of the source system in a usable format (CSV, XML, JSON, API).

SKU,              Qty, StoreID
NIKE-AIR-90-BLK,   20, 50
NIKE-AIR-90-BLK,   90, 80
NIKE-AIR-90-BLK,  -34, 03

(Negative quantity = backorders — people paid for items not yet in stock.)

Transform — Shape data to fit the destination. Example: the site doesn't need per-store stock, so sum it up: 20 + 90 + (-34) = 76 available units.

Load — Insert into the target system. Trigger reindexing, invalidate caches, confirm it took effect.

What flows where

Direction	Data
ERP to eCommerce	Product catalog, pricing, stock, store info
eCommerce to ERP	Orders, customer data

Practical takeaways

Ask "where does this data live?" before building any feature
SKU is your universal key across all systems
Think in data flows, not "integrations" — what data, which direction, how often?
Understand the business impact — a stock sync delay means overselling; a price sync failure means revenue loss
Request only what you need — don't import full database dumps
Delta over full sync — once basics work, sync only what changed

Part 3: From SSR to CSR — The Magento to ScandiPWA Shift

Server-Side Rendering (the old way)

Traditional Magento: user requests a URL, the server builds a complete HTML page (fetching data, merging with templates and CSS), sends it to the browser. Every click = full page rebuild.

The server does everything. The browser just displays.

Client-Side Rendering with ScandiPWA (the new way)

ScandiPWA flips this. The browser becomes the rendering engine:

First load — Browser downloads the entire app (layouts, styles, fonts). It's an empty store — no product data yet.
Data requests — The app asks the server for specific data via GraphQL: "give me the 6 best sellers," not "give me the whole homepage."
Rendering — React takes the data, injects it into components, renders locally.
Navigation — No full reloads. The app already has the layout; it just swaps in new data.

The architecture at a glance

Component	Role
React (ScandiPWA)	The app — all UI, components, styles, routing
GraphQL	The only data pipe between frontend and backend
Service Worker	Local proxy — caching, offline mode, decides server vs. cache
Varnish	Server-side cache for GraphQL responses (~20ms)
Redux	Client-side global state

SSR vs CSR compared

	SSR (Traditional)	CSR (ScandiPWA)
What's sent	Full HTML pages	Small JSON data
Who renders	Server	Browser
Page transitions	Full reload	Instant, app-like
Offline support	None	Service Worker cache
First load	Fast (one page)	Slower (full app shell)
Subsequent loads	Same speed	Much faster
Response size	Large	Up to 10x smaller

What happens to Magento extensions?

The old Magento frontend is gone. Extensions don't "just work" in ScandiPWA.

New extension — You build two packages:

Backend (PHP): admin grids, DB tables, business logic + GraphQL resolvers
Frontend (React): ScandiPWA extension with components, styles, GraphQL queries

Existing marketplace extension — Backend works, but needs:

GraphQL resolvers (many extensions already include them — check first)
A React "compatibility extension" on the frontend

Example (Stripe): Backend already handles payments. Frontend work = 3-4 input fields in checkout + success/error message. Minimal.

Backend-only extensions (reporting, analytics) need no frontend work at all.

Practical takeaways

GraphQL is the only bridge — if data isn't exposed via GraphQL, the frontend can't use it
Think in two packages — backend (PHP + GraphQL) and frontend (React), developed separately
Varnish still matters — tag your data with X-Tag headers for proper cache invalidation
Service Worker = local intelligence — key to debugging "why isn't my data updating?"
Assess extension impact first — "does it have GraphQL?" determines the scope of work
The frontend is an application, not a template — you're building a React app that consumes an API

Final Thought

Writing code is one part of the job. Understanding why the business needs it, how quality is measured, where data lives, and what changes when architecture evolves — that's what makes you effective on a real project.

This post is based on learnings from Scandiweb's Business-Aware Development course. All credit for the original course content goes to Scandiweb.

The 4 Rules of Client Communication Nobody Taught You

Mohamed Idris — Mon, 02 Mar 2026 14:51:58 +0000

Most communication advice boils down to "be professional" or "be nice." That's not useful. What clients actually need is to feel that the situation is under control.

After years of working in client-facing roles, I've distilled this into four rules. Every message, every call, every comment — if it follows these four things, the experience holds. If even one is missing, trust starts to erode, even when the work itself is solid.

1. Own the Next Step

The person reading your message should never have to wonder: "So... who's doing what now?"

Ownership means someone visibly holds the ball. Not "the team," not "the process" — a person.

This works:

"I'm looking into this and will update you by end of day."

This doesn't:

"Waiting for QA."

"This is not on us."

...silence...

The test is simple: after reading your message, does the other person know who owns the next step? If not, ownership is missing.

2. Make It Simpler, Not Longer

Clarity doesn't mean dumbing things down. It means structuring information so the reader can orient fast.

A good message follows this shape:

What happened
What it means
What happens next

This works:

"We identified the issue — it affects the checkout flow. We're deploying a fix this afternoon."

This doesn't:

Three paragraphs of technical context, a "just for context..." section, and no clear takeaway.

The test: do you feel more oriented after reading this, or do you need to re-read it to figure out "so what?" If it needs a second read, clarity is missing.

3. Lower the Temperature

When a client is frustrated, your job is to absorb the pressure — not match it.

This works:

"Thanks for flagging this. I see the issue — here's what I'm doing."

This doesn't:

"As I mentioned before..."

"This was already explained in the last call."

"That's not really a problem because..."

Even when you're factually correct, defensive language escalates. The test: would this message calm a frustrated person, or make them more frustrated?

4. Always End with a Next Step

Every interaction should move the situation forward. Even if you don't have a solution yet, there must be a direction.

This works:

"I'll confirm this with the team and come back to you by Friday."

This doesn't:

An explanation that just... ends.

"Let me know" (with no ownership on your side).

The test: is it obvious what happens next and who does it? If not, the interaction is incomplete.

What This Looks Like in Practice

Here's a real scenario. A client writes:

"The priority has been increased to critical. Launch is planned for the 26th. Please share an update by tomorrow."

A good response (30 minutes later):

"Noted! Will update you tomorrow first thing."

The follow-up (next day):

"The issue was caused by the script relying on DOMContentLoaded, which had already fired when the script was injected. I've replaced this with an immediately executed function that sets the value directly. Please review and let me know if you face any other issues."

Why this works:

Ownership — PM responds fast, dev explains and fixes
Clarity — cause, impact, and resolution in three lines
Calm tone — no panic despite "critical" priority
Next step — fix is delivered, review is requested

Now here's what a bad version looks like. Client writes:

"Any news on the ticket?"

Response:

"We are checking the best approach and will then provide an estimate. Please let me know what you think."

The tone is fine. But the client had to chase. There's no timeline, no clear owner, and the ball gets passed back with "let me know what you think." That's an open loop — and open loops erode trust.

One More Example Worth Studying

A client raises a billing concern:

"I see some items that seem repetitive from the December invoice. Could you clarify?"

Good response:

"Thanks for letting me know! I'm looking into the January invoice now and will double-check why the full audit appears again compared to December. I'll review the scope billed in both months and confirm whether this was a follow-up item or an error on our side. I'll come back to you by tomorrow."

This is textbook. The concern is acknowledged. The investigation is scoped. The timeline is set. The client has nothing left to worry about.

The Uncomfortable Truth

You can do excellent work and still leave a client feeling uneasy — if your communication doesn't hold up.

Hospitality isn't about being perfect. It's about consistently doing four things:

Ownership is visible — someone clearly holds the ball
The message reduces complexity — the reader feels more oriented, not less
Tone lowers tension — pressure is absorbed, not reflected
The next step is always clear — every interaction moves forward

If one of these is missing, the experience degrades. Even if the code ships on time.

This started as a guideline for PMs, QAs, and developers. Turns out it applies to nearly every professional interaction where someone is counting on you.

Originally inspired by an internal hospitality guideline at Scandiweb.

How to Use React Query with React Router Loaders (Pre-fetch & Cache Data)

Mohamed Idris — Thu, 26 Feb 2026 12:11:05 +0000

The Problem

When you navigate to a page, there's usually a delay while data is being fetched. The user sees a loading spinner, and the content pops in after the request finishes. Not great.

What if the data was already there when the page loads?

That's exactly what combining React Query with React Router loaders gives you.

The Idea in Plain English

Loader runs before the component mounts (React Router calls it on navigation).
Inside the loader, we ask React Query: "Do you already have this data cached?"
- Yes → Use it instantly. No network request.
- No → Fetch it now, wait for it, then cache it.
When the component finally mounts, it calls useQuery with the same query. Since the data is already cached, it renders immediately — no loading state.

The key method is queryClient.ensureQueryData(queryOptions). Think of it as: "Make sure this data exists — get it from cache or fetch it."

Step-by-Step Example: A Simple Pokémon Page

Let's build a page that shows Pokémon details. When you navigate to /pokemon/pikachu, the data is already loaded.

1. Set Up the Query

// pages/Pokemon.jsx
import { useQuery } from '@tanstack/react-query';
import { useLoaderData } from 'react-router-dom';
import axios from 'axios';

// A function that returns the query config (key + fetch function).
// We reuse this in BOTH the loader and the component.
const pokemonQuery = (name) => {
  return {
    queryKey: ['pokemon', name],
    queryFn: async () => {
      const response = await axios.get(
        `https://pokeapi.co/api/v2/pokemon/${name}`
      );
      return response.data;
    },
  };
};

2. Create the Loader

// The loader receives queryClient from the router setup (see step 4).
// It runs BEFORE the component mounts.
export const loader = (queryClient) => {
  return async ({ params }) => {
    const { name } = params;

    // ensureQueryData checks the cache first:
    //   - cached? → returns it instantly
    //   - not cached? → fetches, caches, and returns it
    await queryClient.ensureQueryData(pokemonQuery(name));

    // We only return the param — the actual data lives in React Query's cache
    return { name };
  };
};

3. Build the Component

const Pokemon = () => {
  // Get the param that the loader returned
  const { name } = useLoaderData();

  // useQuery uses the SAME query config as the loader.
  // Since ensureQueryData already cached it, this renders instantly.
  const { data: pokemon } = useQuery(pokemonQuery(name));

  return (
    <div>
      <h1>{pokemon.name}</h1>
      <img src={pokemon.sprites.front_default} alt={pokemon.name} />
      <p>Height: {pokemon.height}</p>
      <p>Weight: {pokemon.weight}</p>
    </div>
  );
};

export default Pokemon;

4. Wire It Up in the Router

// App.jsx
import {
  createBrowserRouter,
  RouterProvider,
} from 'react-router-dom';
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';

import Pokemon, { loader as pokemonLoader } from './pages/Pokemon';

const queryClient = new QueryClient();

const router = createBrowserRouter([
  {
    path: '/pokemon/:name',
    element: <Pokemon />,
    // Pass queryClient into the loader
    loader: pokemonLoader(queryClient),
  },
]);

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <RouterProvider router={router} />
    </QueryClientProvider>
  );
}

export default App;

How It All Flows

User clicks link to /pokemon/pikachu
        │
        ▼
Router calls loader BEFORE mounting the component
        │
        ▼
loader calls: await queryClient.ensureQueryData(pokemonQuery("pikachu"))
        │
        ├── Cache HIT?  → Returns cached data instantly (no fetch)
        │
        └── Cache MISS? → Fetches from API, caches result, then returns
        │
        ▼
Component mounts → useQuery(pokemonQuery("pikachu"))
        │
        ▼
Data is already in cache → Renders IMMEDIATELY (no loading spinner)

Why Not Just Use `useQuery` Alone?

You totally can use useQuery by itself. But here's the difference:

Approach	What Happens
`useQuery` only	Component mounts → starts fetching → shows loading → shows data
`ensureQueryData` in loader + `useQuery`	Data fetched before mount → component renders with data instantly

The loader approach gives a smoother, faster UX — especially on page navigations.

The Key Takeaways

ensureQueryData = "If cached, use cache. If not, fetch and cache it."
Create a shared query config function (like pokemonQuery) and use it in both the loader and the component.
The loader pre-fills the cache so useQuery in the component finds the data immediately.
You return only the params from the loader — not the data itself. The data lives in React Query's cache.

That's it. Your pages now load instantly on navigation, and React Query handles caching, background refetching, and stale data for free.

Forem: Mohamed Idris

🧠 The Backend Developer Fundamentals Guide

Understand the engine before you drive the car.

Table of Contents

1. How The Internet Actually Works

DNS — The Phone Book of the Internet

TCP/IP — The Delivery System

Ports — Doors Into Your Server

HTTP/HTTPS — The Language of the Web

2. Request & Response — The Heart of Everything

What is a Request?

What is a Response?

The Full Picture

3. What a Server Actually Does

The Server's Job, Step by Step

Middleware — The Assembly Line

4. How Data Flows Through a System

The Typical Layers

Why Layers Matter

5. Memory, Threads & Processes

Memory — Your Program's Workspace

Processes — Independent Workers

Threads — Workers Inside a Worker

Blocking vs Non-Blocking

Concurrency vs Parallelism

6. Databases — Where Data Lives

Relational Databases (SQL)

Key SQL Concepts You Must Know

NoSQL Databases

7. APIs — How Systems Talk to Each Other

REST — The Most Common API Style

JSON — The Universal Data Format

API Design Best Practices

GraphQL — The Alternative

8. Authentication & Authorization

How Login Works (The Real Flow)

Passwords — Never Store Plain Text

JWT (JSON Web Tokens)

Sessions vs Tokens

OAuth 2.0 — "Login with Google/GitHub"

9. Caching — Making Things Fast

Where Caching Happens

Example: Why Caching Matters

Cache Invalidation

10. Security Basics

SQL Injection

Cross-Site Scripting (XSS)

Cross-Site Request Forgery (CSRF)

Rate Limiting

HTTPS Everywhere

The OWASP Top 10

11. Architecture Patterns

Monolith

Microservices

MVC (Model-View-Controller)

Event-Driven Architecture

12. Networking Essentials

The OSI Model (Simplified)

WebSockets

Load Balancing

13. Linux & The Command Line

Essential Commands

Package Managers

SSH — Remote Server Access

14. Version Control (Git)

Core Concepts

Essential Commands

Branching Strategy

15. Testing

Types of Tests

The Testing Pyramid

Why Testing Matters

16. DevOps Basics

Docker — Portable Environments

CI/CD — Automated Testing & Deployment

Cloud Basics

17. The Learning Order (Roadmap)

Phase 1: The Foundation (Weeks 1–6)

Phase 2: Databases & APIs (Weeks 7–12)

Phase 3: Real-World Skills (Weeks 13–20)

The Fix: `window.matchMedia`

What is `window.matchMedia`?

The variable name `mql`