DEV Community: The Practical Developer

SQL Joins Explained: INNER, LEFT, RIGHT, and FULL, With Examples

The Practical Developer — Mon, 26 Oct 2026 16:23:24 +0000

Introduction

Most real data lives in more than one table. Users live in one table, orders in another, and the link between them is usually an ID, like user_id. A join combines rows from two tables based on that link, so you can ask questions like "show me each order, with the name of the person who placed it."

There are four joins you need first. They differ only in which rows they keep when there is no match.

The example tables

-- users
-- id | name
--  1 | Ali
--  2 | Sara
--  3 | Omar
-- orders
-- id | user_id | item
--  1 |       1 | Keyboard
--  2 |       1 | Mouse
--  3 |       2 | Monitor

Ali has two orders, Sara has one, Omar has none, and every order belongs to a user in this example.

INNER JOIN — only matching rows

An INNER JOIN keeps only rows that match in both tables. Omar disappears here, because he has no orders.

SELECT users.name, orders.item
FROM users
INNER JOIN orders ON users.id = orders.user_id;

Result:

name | item
Ali  | Keyboard
Ali  | Mouse
Sara | Monitor

Use INNER JOIN when you only care about rows that exist on both sides.

LEFT JOIN — all rows from the left table

A LEFT JOIN keeps every row from the first table (the left one), even if there is no match. Unmatched rows get NULL for the other table's columns.

SELECT users.name, orders.item
FROM users
LEFT JOIN orders ON users.id = orders.user_id;

Result:

name | item
Ali  | Keyboard
Ali  | Mouse
Sara | Monitor
Omar | NULL

Use LEFT JOIN when you want "every user, and their orders if they have any" — for example, a report that must include users with zero orders.

RIGHT JOIN — all rows from the right table

A RIGHT JOIN is the mirror image: it keeps every row from the second table (the right one), even if there is no match in the first.

SELECT users.name, orders.item
FROM users
RIGHT JOIN orders ON users.id = orders.user_id;

In this example, the result looks like the INNER JOIN result, because every order has a matching user. RIGHT JOIN matters when the right table has rows with no match on the left — for example, orders placed by a deleted user account.

In practice, many developers rewrite a RIGHT JOIN as a LEFT JOIN by swapping the table order, because it reads more naturally left to right. Both are correct.

FULL JOIN — all rows from both tables

A FULL JOIN keeps every row from both tables, filling NULL where there is no match on either side.

SELECT users.name, orders.item
FROM users
FULL JOIN orders ON users.id = orders.user_id;

Result:

name | item
Ali  | Keyboard
Ali  | Mouse
Sara | Monitor
Omar | NULL

If there were an order with no matching user, that row would also appear, with NULL for the name. Use FULL JOIN when you need a complete picture from both sides, including unmatched rows on either side.

Choosing the right join

Only matching rows: INNER JOIN
All left rows, matches if any: LEFT JOIN
All right rows, matches if any: RIGHT JOIN
All rows from both sides: FULL JOIN

The most common mistake is using INNER JOIN by default and silently losing rows that have no match. If your result looks smaller than expected, check whether a LEFT JOIN was what you actually meant.

Takeaway

A join is just a rule for which rows to keep. Start with INNER for matches only, reach for LEFT when the left table must stay complete, and use FULL when both sides must stay complete. With those four, you can answer most reporting questions in SQL.

Originally published at https://practicaldevblog.blogspot.com/2026/10/sql-joins-explained.html

Git Branching Explained: Work Without Breaking the Main Code

The Practical Developer — Mon, 26 Oct 2026 16:17:01 +0000

Introduction

A branch is a separate line of work in Git. The main branch, usually called main, holds the stable code. When you start a feature or a fix, you create a branch, work there, and merge it back only when it is ready. If the work goes wrong, the main code is untouched.

This is the workflow used by almost every team, and it is worth learning early, before you need it under pressure.

Create and switch branches

Check your current branch first, then create and switch in one step with the modern switch command, or the older checkout command if your Git version prefers it.

git status
git switch -c feature/login-form
# Older Git: git checkout -b feature/login-form

Name branches clearly: feature/login-form, fix/header-bug, docs/readme-update. A good branch name tells the next person what the branch is for, without opening it.

Work normally on the branch, then commit as usual:

git add .
git commit -m "Add login form layout"

Merge back to main

When the work is done, switch back to main, update it, and merge your branch in:

git switch main
git pull
git merge feature/login-form

If the merge is clean, Git combines the changes and you are done. Delete the branch after merging, so old branches do not pile up:

git branch -d feature/login-form

What happens with a conflict

A conflict happens when the same lines were changed in both branches, and Git cannot decide which version to keep. Git marks the conflicted file like this:

<<<<<<< HEAD
Welcome back, Sara!
=======
Welcome back, Ali!
>>>>>>> feature/login-form

Fix it by editing the file to the version you actually want, removing all the marker lines, then marking it resolved:

git add <file>
git commit

Conflicts look scary the first time, but they are normal. They are Git asking you to choose, not Git breaking your code. Always test after resolving a conflict, because a clean merge does not guarantee the combined code still works.

A simple daily workflow

Update main: git switch main then git pull
Create a branch for the task
Commit small, clear changes on that branch
Merge back to main, or open a pull request for review
Delete the merged branch

Takeaway

Branches are cheap, safe, and reversible. Work on a branch, keep main stable, merge when ready, and resolve conflicts by choosing the correct lines and testing afterwards. That one habit prevents most "I broke the project" moments.

Originally published at https://practicaldevblog.blogspot.com/2026/10/git-branching-explained.html

JavaScript Async/Await Explained: From Callbacks to Clean Code

The Practical Developer — Mon, 26 Oct 2026 16:16:01 +0000

Introduction

JavaScript often has to wait — for a network request, a file, or a timer. The old way to handle waiting was nested callbacks, which quickly became hard to read. Promises improved that. Async/await makes it read almost like normal, top-to-bottom code.

If you understand promises and one keyword pair, async and await, you can write most asynchronous JavaScript you will need day to day.

The basic pattern

A function marked async always returns a promise. Inside it, await pauses that function until a promise settles, without blocking the rest of the program.

async function getUser(userId) {
  const response = await fetch(
    `https://jsonplaceholder.typicode.com/users/${userId}`
  );
  const user = await response.json();
  return user;
}
getUser(1).then((user) => console.log(user.name));

Read it like normal code: fetch the user, wait for the JSON, return the user. The await lines are where the waiting happens, and they are easy to spot.

Handling errors with try/catch

Without error handling, a failed request becomes an unhandled promise rejection. Wrap awaited calls in try/catch, just like synchronous code.

async function getUserSafely(userId) {
  try {
    const response = await fetch(
      `https://jsonplaceholder.typicode.com/users/${userId}`
    );
    if (!response.ok) {
      throw new Error(`Request failed: ${response.status}`);
    }
    return await response.json();
  } catch (error) {
    console.error("Could not load user:", error.message);
    return null;
  }
}

Two habits matter here. First, check response.ok, because fetch only rejects on a network failure, not on a 404 or 500. Second, return a safe fallback, like null, so the caller can handle the missing data cleanly.

Sequential vs parallel

Awaiting in a loop runs tasks one after another. That is correct when one task depends on the previous one, but slow when the tasks are independent.

// Sequential: second request waits for the first
const user1 = await getUser(1);
const user2 = await getUser(2);
// Parallel: both start at once, then wait for both
const [userA, userB] = await Promise.all([getUser(1), getUser(2)]);

Use Promise.all when the tasks do not depend on each other. Note that if any promise in Promise.all rejects, the whole thing rejects, so handle errors for the group, not just for one item.

Common beginner mistakes

Forgetting await, then wondering why a variable holds a promise instead of data.
Using await inside a normal function instead of an async function.
Awaiting inside a loop when the tasks are independent — use Promise.all instead.
Forgetting error handling, so one failed request crashes the flow silently.

Takeaway

Mark the function async, await the promises you need, handle errors with try/catch, and use Promise.all for independent work. That covers most real async code, without callback nesting.

Originally published at https://practicaldevblog.blogspot.com/2026/10/javascript-async-await-explained.html

Build Your First REST API With Node.js and Express in 30 Minutes

The Practical Developer — Mon, 26 Oct 2026 15:51:02 +0000

Introduction

A REST API is a way for a frontend, a mobile app, or another service to ask your server for data, and to send data back. Node.js with Express is a good first choice for learning APIs because the setup is small and the concepts transfer to other backend frameworks.

In this post, you will build a tiny users API with two routes: one to list users, and one to add a user.

Step 1: Set up the project

Create a folder, then run:

npm init -y
npm install express

Add this to your package.json so you can run the server easily:

{
  "scripts": {
    "start": "node index.js"
  }
}

Step 2: Create the server

Create a file called index.js:

const express = require("express");
const app = express();

app.use(express.json());

let users = [
  { id: 1, name: "Ali" },
  { id: 2, name: "Sara" },
];

// GET /users — list all users
app.get("/users", (req, res) => {
  res.json(users);
});

// GET /users/:id — get one user
app.get("/users/:id", (req, res) => {
  const user = users.find((u) => u.id === Number(req.params.id));
  if (!user) {
    return res.status(404).json({ error: "User not found" });
  }
  res.json(user);
});

// POST /users — add a user
app.post("/users", (req, res) => {
  const { name } = req.body;
  if (!name) {
    return res.status(400).json({ error: "Name is required" });
  }
  const newUser = { id: users.length + 1, name };
  users.push(newUser);
  res.status(201).json(newUser);
});

app.listen(3000, () => {
  console.log("Server running on http://localhost:3000");
});

Run it with:

npm start

Then test it in a browser or with curl:

curl http://localhost:3000/users
curl -X POST http://localhost:3000/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Omar"}'

What each part does

express.json() lets Express read JSON sent in a POST request body. Without it, req.body will be empty.
app.get handles read requests. app.post handles create requests.
Status codes matter: 200 for success, 201 for created, 400 for a bad request, 404 for not found. They tell the client what happened without reading the message first.
Returning early, like return res.status(404)..., prevents the rest of the handler from running after an error.

Common beginner errors

Forgetting express.json(), then wondering why req.body is undefined.
Sending two responses in one handler, which causes a "headers already sent" error. Always return after sending an error response.
Using the same route twice with different logic. Express matches routes in order, so put specific routes before general ones when they overlap.
Storing data only in memory, as above. That is fine for learning, but data will disappear when the server restarts. A database comes next, once the API shape is clear.

Takeaway

You now have a working API pattern you can reuse: set up Express, add JSON handling, write GET and POST routes, use clear status codes, and validate input early. From here, the natural next steps are adding a database, validation, and authentication — each as its own small step, not all at once.

Originally published at https://practicaldevblog.blogspot.com/2026/10/build-your-first-rest-api-with-nodejs.html

Python List Comprehensions Explained With Real Examples

The Practical Developer — Mon, 26 Oct 2026 15:47:37 +0000

Introduction

A list comprehension is a short way to create a new list by transforming or filtering an existing one. It is not magic, and it is not always the best choice. Used well, it makes code shorter and easier to read. Used badly, it makes code hard to follow.

The basic pattern

The pattern is:

[expression for item in iterable]

For example, to square every number in a list:

numbers = [1, 2, 3, 4, 5]
squares = [n * n for n in numbers]
print(squares)
# Output: [1, 4, 9, 16, 25]

The normal loop version does the same thing in more lines:

numbers = [1, 2, 3, 4, 5]
squares = []
for n in numbers:
    squares.append(n * n)

Both are correct. The comprehension is shorter when the transformation is simple.

Adding a condition

You can filter with if at the end:

numbers = [1, 2, 3, 4, 5, 6]
even_numbers = [n for n in numbers if n % 2 == 0]
print(even_numbers)
# Output: [2, 4, 6]

You can also transform strings:

names = ["ali", "sara", "omar"]
capitalised = [name.capitalize() for name in names]
print(capitalised)
# Output: ['Ali', 'Sara', 'Omar']

A practical example

Suppose you have a list of prices and you want only the prices above 100, with tax added:

prices = [50, 120, 80, 200, 90]
final_prices = [round(price * 1.10, 2) for price in prices if price > 100]
print(final_prices)
# Output: [132.0, 220.0]

Read it left to right: take each price, keep it only if it is above 100, then multiply by 1.10.

When NOT to use a list comprehension

Do not use one when:

The logic has several nested conditions or side effects, like printing or saving to a file.
The line becomes so long that you have to read it twice to understand it.
You do not actually need a list, only a single result. In that case, a loop with an early exit, or a generator, may be clearer.

Readability is the test. If a beginner on your team would struggle to read it, use a normal loop. Python's own style guide values readability over cleverness.

Takeaway

Start with the simple pattern: expression, loop, optional condition. Use comprehensions for simple transforms and filters. Switch back to a loop when the logic gets complex. That balance is what makes Python code both short and readable.

Originally published at https://practicaldevblog.blogspot.com/2026/10/python-list-comprehensions-explained.html

React useEffect Explained: When to Use It, and When to Avoid It

The Practical Developer — Mon, 26 Oct 2026 15:44:10 +0000

Introduction

useEffect is one of the most misunderstood React hooks. Beginners use it for everything. Experienced developers use it only when a component needs to sync with something outside React.

The simple rule is this: if the code is a reaction to a user action, like a button click, use an event handler. If the code needs to run because the component is on screen, like fetching data or starting a timer, useEffect may be the right tool.

What useEffect actually does

useEffect runs after React has rendered your component and updated the screen. It is for side effects — work that affects the outside world, not just the calculation of what to show.

Common valid uses:

Fetching data when a component loads
Subscribing to a WebSocket or event listener
Starting and cleaning up a timer
Syncing with browser APIs, like document title or local storage

A correct data-fetching example

import { useEffect, useState } from "react";

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const controller = new AbortController();

    async function loadUser() {
      setLoading(true);
      try {
        const response = await fetch(
          `https://jsonplaceholder.typicode.com/users/${userId}`,
          { signal: controller.signal }
        );
        const data = await response.json();
        setUser(data);
      } catch (error) {
        if (error.name !== "AbortError") {
          console.error(error);
        }
      } finally {
        setLoading(false);
      }
    }

    loadUser();

    return () => controller.abort();
  }, [userId]);

  if (loading) return <p>Loading...</p>;
  if (!user) return <p>No user found.</p>;
  return <h1>{user.name}</h1>;
}

Three things matter here:

The dependency array [userId] means the effect re-runs only when userId changes.
The cleanup function aborts the request if the component unmounts or userId changes.
State updates happen inside the effect, not during render.

When NOT to use useEffect

Do not use useEffect to:

Transform data for display. Compute it directly during render instead.
Handle a form submit or button click. Use an event handler.
Chain state updates that could be calculated from existing state.

A common mistake is fetching data, storing it in state, then using another effect to derive a second value from it. In most cases, you can derive that second value directly during render, with no effect at all.

Checklist before you write useEffect

Is this work triggered by rendering, or by a user action? If it is a user action, use an event handler.
Does it need cleanup? If yes, return a cleanup function.
What should trigger it again? Put only those values in the dependency array.
Can the same result be computed during render? If yes, skip the effect.

Takeaway

useEffect is not a place to put all logic. It is a narrow tool for syncing a component with the outside world. Use it for fetching, subscriptions, and timers, and let rendering and event handlers do the rest. That one distinction will prevent most useEffect bugs.

Originally published at https://practicaldevblog.blogspot.com/2026/10/react-useeffect-explained-when-to-use.html