DEV Community: Juma Evans

JWT Authentication: A Backend Engineer's Mental Model

Juma Evans — Mon, 03 Aug 2026 12:56:51 +0000

Introduction

Imagine you arrive at a hotel.

At the reception, you show your ID and prove who you are. The receptionist then gives you a room key card.

You don't need to show your ID every time you enter your room. Instead, you simply present the key card.

The hotel doesn't need to ask your name again because the card itself proves that you already authenticated.

JWT (JSON Web Token) works exactly like that.

Username and password = Your ID
JWT = Hotel key card
Server = Receptionist

What is JWT?

JWT stands for JSON Web Token.

It is a compact string that proves a user has already logged in successfully.

Instead of storing login sessions on the server, the server gives the client a signed token.

The client sends this token with every request.

Example:

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

The server verifies the token and allows access.

Why Do We Need JWT?

Without JWT, every request would require sending the username and password repeatedly.

Browser
   |
Username
Password
   |
Server

That would be inefficient and insecure.

Instead:

Login once

↓

Receive JWT

↓

Reuse JWT for every request

Stateless Authentication

JWT enables stateless authentication.

Stateful Authentication

Server
|
|-- Session #12345
|-- Session #91821
|-- Session #44211

The server stores every user's session.

Stateless Authentication (JWT)

Server

(No session storage)

↓

Only verifies token signature

The server doesn't remember users.

The token remembers.

JWT Structure

A JWT consists of three parts separated by periods.

Header.Payload.Signature

Example

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjMiLCJuYW1lIjoiRXZhbnMiLCJyb2xlIjoiYWRtaW4ifQ
.
K6L6GQX....

Think of it like

Envelope
Letter
Wax Seal

Part 1 — Header

Example

{
  "alg": "HS256",
  "typ": "JWT"
}

The header tells us:

Which algorithm signed the token.
What type of token it is.

Fields:

alg → Signing algorithm
typ → JWT

Common algorithms:

HS256
RS256
ES256

Part 2 — Payload

The payload contains claims.

Example:

{
    "user_id": 42,
    "name": "Evans",
    "role": "admin"
}

Think of it as your digital identity card.

Typical information:

User ID
Username
Email
Role
Permissions

Standard Claims

Claim	Meaning
sub	Subject (User ID)
exp	Expiration Time
iat	Issued At
iss	Issuer
aud	Audience

Example

{
    "sub":"42",
    "role":"admin",
    "exp":1754440000
}

Important

The payload is NOT encrypted.

Anyone can decode it.

JWT

↓

Base64URL Decode

↓

Payload

Never store:

Passwords
PINs
Secret Keys
API Keys
Credit Card Numbers

inside a JWT.

Part 3 — Signature

The signature protects the token from tampering.

The server computes something similar to:

HMACSHA256(

Base64(Header)

+

Base64(Payload),

SecretKey

)

This produces the signature.

The secret key never leaves the server.

Why the Signature Matters

Suppose someone changes:

{
    "role":"user"
}

{
    "role":"admin"
}

The payload changes.

Therefore the signature changes.

Since the attacker doesn't know the server's secret key, they cannot generate a valid signature.

Result:

Server

↓

Verify Signature

↓

Invalid

↓

401 Unauthorized

This is why JWTs are tamper-evident.

Login Flow

User

↓

POST /login

↓

Username

Password

↓

Server

Server:

Checks the database.
Verifies the password.
Generates a JWT.
Returns it.

Example response:

{
    "token":"eyJhbGc..."
}

The client stores the token.

Authenticated Request

GET /profile
Authorization: Bearer eyJhbGc...

Server:

Reads the Authorization header.
Verifies the signature.
Checks expiration.
Extracts the user ID.
Returns the requested resource.

Complete Request Lifecycle

Client

↓

Login

↓

Receive JWT

↓

Store JWT

↓

Send JWT

↓

Server verifies

↓

Access granted

Where Should Tokens Be Stored?

Browser

Preferred:

Secure HttpOnly Cookies
Memory (for SPAs)

Avoid storing long-lived access tokens in localStorage because XSS attacks can expose them.

Mobile

Use secure platform storage:

iOS Keychain
Android Keystore

Token Expiration

Example

{
    "exp":1754440000
}

Server checks:

Current Time

↓

Expired?

↓

Yes

↓

401 Unauthorized

Expired tokens cannot be used.

Refresh Tokens

Access tokens should have short lifetimes.

Example:

Access Token

15 Minutes

When expired:

Client

↓

Refresh Token

↓

Server

↓

New Access Token

Refresh tokens allow users to remain logged in without entering credentials repeatedly.

JWT vs Sessions

JWT	Sessions
Stateless	Stateful
No server-side session storage	Server stores sessions
Easy to scale	More difficult to scale
Great for APIs	Great for traditional web applications
Client sends token	Client sends session cookie

JWT in a Go (Gin) Backend

Login Endpoint

POST /login

↓

Validate Request

↓

Find User

↓

Compare Password Hash

↓

Generate JWT

↓

Return Token

Protected Route

GET /users

↓

JWT Middleware

↓

Read Authorization Header

↓

Verify Signature

↓

Check Expiration

↓

Extract Claims

↓

Next()

↓

Handler Executes

Middleware Flow

Incoming Request
       │
       ▼
Read Authorization Header
       │
       ▼
Token Present?
   │        │
  No       Yes
   │        ▼
401      Verify Signature
             │
      Valid? │
        │    │
       No   Yes
        │    ▼
      401  Check Expiration
               │
        Expired? │
          │      │
         Yes    No
          │      ▼
        401   Extract Claims
                   │
                   ▼
      Store User in Context
                   │
                   ▼
          Execute Next Handler

Authentication vs Authorization

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

Example:

Login

↓

Authentication

↓

JWT

↓

Authorization

↓

Access Granted

Common Interview Questions

What is JWT?

A signed JSON token used for stateless authentication.

Is JWT encrypted?

No.

It is Base64URL encoded and digitally signed, but not encrypted.

Why can't users modify the payload?

Because changing the payload invalidates the signature.

What is the purpose of the signature?

To guarantee integrity and authenticity.

Why does JWT expire?

To reduce the damage if a token is stolen.

What is a Refresh Token?

A long-lived credential used to request a new access token after the current one expires.

What happens if the signature is invalid?

The server rejects the request with 401 Unauthorized.

Why is JWT called stateless?

Because the server does not store user sessions.

Every request contains all the information needed to authenticate the user.

Best Practices

Always use HTTPS.
Never store passwords inside JWTs.
Keep access tokens short-lived (10–30 minutes).
Use refresh tokens for long-lived sessions.
Store refresh tokens securely.
Validate the signature on every request.
Validate the expiration (exp) claim.
Use strong signing algorithms.
Rotate signing keys when appropriate.
Implement token revocation if your application requires immediate logout or compromised-token handling.

Key Takeaways

JWT stands for JSON Web Token.
A JWT has three parts:
- Header
- Payload
- Signature
The payload is readable by anyone who has the token.
The signature protects against tampering.
JWT enables stateless authentication.
Access tokens should expire.
Refresh tokens provide a secure way to obtain new access tokens.
JWT authentication is commonly implemented using middleware in Go (Gin), Express.js, Spring Boot, ASP.NET, and many other backend frameworks.

Final Mental Model

Think of JWT like a hotel key card.

User
 │
 │ Login (Username + Password)
 ▼
Server verifies credentials
 │
 ▼
Issues a signed JWT
 │
 ▼
Client stores the token
 │
 ▼
Client sends the token with every request
 │
 ▼
Server verifies:
    ✔ Signature
    ✔ Expiration
    ✔ Claims
 │
 ▼
Access Granted

The server does not need to remember the user.

The signed token carries the identity, while the server only needs its secret (or public key, depending on the algorithm) to verify that the token is authentic and has not been altered.

Your Code Doesn't Run. A Translation of Your Code Does.

Juma Evans — Sat, 01 Aug 2026 20:24:28 +0000

Every time you write a program and hit run, something extraordinary happens before a single instruction executes. Your source code,the plain text(human-readable), gets transformed through several distinct stages into something a CPU can actually understand.

Most developers never look at those stages. They trust the compiler the way they trust electricity: they know it works, they just don't know how.

This article is about how it works.

By the end, you'll understand every major stage a compiler goes through, what it's doing and why, and you'll never look at a compiler error the same way again.

What Is a Compiler, Really?

A compiler is a program that reads a program written in one language and outputs an equivalent program in another language.

Usually that means: read source code written by a human, output machine code understood by a CPU. But that's the end result of a pipeline, not a single step.

Think of it like translating a novel from Swahili to English. You don't just look at the whole book and magically produce a translation. You read sentence by sentence, understand grammar, resolve meaning, restructure where necessary, then write the output. The compiler does something structurally similar, just with ruthless precision, because machines tolerate zero ambiguity.

The pipeline has roughly five stages:

Lexing :— breaking source code into tokens
Parsing:— building a tree structure from those tokens
Semantic Analysis :— checking that the tree actually makes sense
Intermediate Representation :— translating to a language-neutral form
Code Generation :— producing the final machine code

Let's walk through each one.

Stage 1: Lexing (Also Called Tokenization)

The very first thing a compiler does is read your source file as raw text and break it into tokens, the smallest meaningful units of the language.

Take this line of Go:

go
x := 42 + y

The lexer reads this character by character and groups them into:

Token Type
x Identifier
:= Operator
42 Integer Literal

Operator y Identifier

Whitespace gets discarded. Comments get discarded. What's left is a flat stream of tokens, each labelled with its type.

This is why your compiler doesn't care whether you write x:=42+y or x := 42 + y. Both produce the exact same token stream because the spaces were never meaningful to begin with.

When Lexing Fails

If you type a character the language doesn't recognize say, a @ symbol in Go where it isn't valid the lexer is the one that catches it. That "unexpected character" error you've seen this before? That's the lexer talking.

Stage 2: Parsing — Building the AST

A flat list of tokens isn't enough. 42 + y * 3 means something different from (42 + y) * 3. The parser's job is to take the token stream and build a tree that encodes structure and precedence.

That tree is called an Abstract Syntax Tree, or AST.

For the expression x := 42 + y, the AST looks roughly like:

AssignStatement
├── Left: Identifier("x")
└── Right: BinaryExpression(+)
├── Left: IntLiteral(42)
└── Right: Identifier("y")

Every node in the tree represents a construct in the language. Statements contain expressions. Expressions contain sub-expressions. Functions contain blocks. Blocks contain statements. The whole program becomes one giant tree, with the root at the top and leaves at the bottom.

Why a Tree?

Because code is inherently hierarchical. A function contains statements. Statements contain expressions. Expressions contain sub-expressions. A flat list can't represent that nesting but a tree can.

The parser uses the grammar rules of the language to this tree. Grammar rules are what define what valid code even looks like. If your tokens don't fit the grammar say, you write x := := 42 the parser rejects it. That's a "syntax error." Not a character problem (the lexer passed), but a structure problem.

Stage 3: Semantic Analysis — Does This Actually Make Sense?

A program can be grammatically valid and still be nonsense.

go
var x int = "hello"

That's syntactically fine, it's a valid assignment statement. But it's semantically wrong. You're trying to put a string into an integer variable.

Semantic analysis is where the compiler checks meaning, not just structure. This stage does several things:

Type checking; are the types compatible? Is a function being called with the right argument types? Is a return value the right type?

Scope resolution; when you write y, does y exist? Was it declared before it was used? Is it in scope here?

Name binding; connecting every reference to a variable or function back to its declaration.

Constant folding; if you write 2 + 3, the compiler can compute this at compile time and just treat it as 5. No need to calculate it every time the program runs.

This is the stage that produces errors like "undefined variable", "cannot use string as int", and "function takes 2 arguments, got 3." These aren't syntax errors the structure was fine. The meaning was wrong.

Stage 4: Intermediate Representation (IR)

After semantic analysis, the compiler has a fully validated AST. Now it needs to translate that into something closer to machine code, but not quite machine code yet.

This middle step is called Intermediate Representation, or IR.

Why not go straight to machine code? Because different CPUs speak different machine languages. An x86 chip and an ARM chip have completely different instruction sets. If you went straight from AST to machine code, you'd need a separate compiler backend for every target architecture.

IR solves this by being a neutral, low-level language that isn't tied to any specific CPU. The Go compiler uses its own internal IR. LLVM (used by Clang, Rust, and others) uses a well-known IR called LLVM IR.

IR also enables optimization. Before generating final output, the compiler can analyze the IR and improve it:

Remove code that can never be reached
Eliminate variables that are assigned but never used
Inline small functions to avoid call overhead
Reorder instructions to keep the CPU pipeline busy

These optimizations happen on the IR, not the source code, which is why they work the same regardless of which language you wrote the program in.

Stage 5: Code Generation

The final stage. The compiler takes the (now optimized) IR and translates it into actual machine code for a specific target architecture.

Machine code is just numbers, binary instructions the CPU reads directly. For example, the instruction to move a value into a register on x86-64 might be encoded as 48 89 C3. The code generator knows the instruction set of the target CPU and emits the right bytes.

The output is typically an object file, a binary file containing machine code, but not yet a complete program. Object files get passed to a linker, which combines them with other object files (and libraries) to produce the final executable.

That final executable is what you actually run.

Putting It All Together

Let's trace a simple Go program through the full pipeline:

go
package main

import "fmt"

func main() {
x := 10
y := 20
fmt.Println(x + y)
}

Lexer: Reads the file, produces tokens: package, main, import, "fmt", func, main, (, ), {, x, :=, 10, ...

Parser: Builds an AST. The root is a PackageDeclaration. It has an ImportDeclaration and a FunctionDeclaration. The function body contains two AssignStatements and a CallExpression.

Semantic Analysis: Checks that x and y are declared before use. Checks that x + y produces an int. Checks that fmt.Println accepts an int. Resolves fmt to the imported package.

IR Generation: Translates the AST into a lower-level representation. The addition x + y becomes an ADD instruction. The function call becomes a CALL instruction with arguments set up correctly.
**
Optimization*: In this case, the compiler might even compute 10 + 20 = 30 at compile time and replace the addition with a constant.
*
Code Generation*: Emits x86-64 (or ARM, depending on your machine) instructions. Produces an object file.
*
Linker**: Combines the object file with the fmt package's compiled code. Produces the final binary.

You type go run main.go. In milliseconds, all of that happens. Then your program prints 30.

What This Changes About Reading Errors

Once you understand the pipeline, compiler errors stop being mysterious.

"unexpected token" → the lexer or parser failed. Your code's structure is wrong. Check syntax.

"undefined: x" → semantic analysis failed. You used something that wasn't declared, or declared it in the wrong scope.

"cannot use string as type int" → type checking failed. The types don't match. Semantic analysis caught it.

"x declared and not used" → Go's compiler enforces this at the semantic analysis stage as a hard rule, not a warning. Unused variables indicate bugs or dead code, so Go refuses to compile.

Each error is the compiler telling you exactly which stage it got to before it couldn't continue and what specifically went wrong.

Something worth noting on Interpreted Languages

Not every language uses this full pipeline. Python, JavaScript (in some contexts), and Ruby are traditionally interpreted, instead of compiling to machine code ahead of time, an interpreter reads the source and executes it directly, often line by line.

Interpreters still lex and parse. They build ASTs. But instead of generating machine code, they walk the AST and execute each node directly.

The tradeoff: interpreted languages start faster (no compilation step) but run slower (no ahead-of-time optimization, no direct machine code). That's why Python is convenient for scripting but Go or C are used when performance matters.

Modern JavaScript engines (V8 in Chrome, SpiderMonkey in Firefox) blur this line — they use JIT (Just-In-Time) compilation, which compiles hot code paths to machine code at runtime. It's a hybrid: interpret first, compile the parts that matter.

Why This Matters For Backend Engineers

You might be thinking: I write application code. I'm not building a compiler. Why does this matter?

A few reasons.

You debug faster. When you know what a compiler error is actually telling you, you spend less time guessing and more time fixing.

You write better code. Understanding what the compiler can and can't optimize helps you write code that performs well not through premature optimization, but through avoiding patterns that defeat the optimizer.

You understand your tools. Every build system, linter, code formatter, and static analysis tool is, at its core, doing some version of what a compiler does. Understanding the pipeline makes all of those tools less magical and more predictable.

You grow as an engineer. The engineers who built the systems you use every day databases, runtimes, operating systems understood this. Closing that gap between "I write code" and "I understand what runs my code" is part of what separates junior engineers from senior ones.

The One-Line Summary

Your source code is text. CPUs understand binary. A compiler is the translator that bridges that gap in five careful, well-defined stages, each building on the last.

Lexing breaks text into tokens. Parsing builds structure. Semantic analysis checks meaning. IR enables optimization. Code generation produces the final output.

Every time you compile, that entire process runs. Now you know what it's doing.

This is what building a Two-Node Lightning Network From Scratch looked like in one week.

Juma Evans — Sat, 01 Aug 2026 19:29:09 +0000

There's a version of learning Bitcoin where you read the whitepaper, nod along, and move on. Then there's the version where you're staring at a terminal at 11pm wondering why two nodes refuse to talk to each other then you actually understand the answer when you figure it out.

We did the second version. This article is what came out of it.

By the end of one week, I understood what Bitcoin actually is under the hood, why the Lightning Network exists, what a payment channel really means, and what it looks like to build all of this from zero, in a local test environment.

No hype. No "Bitcoin is the future" takes. Just the engineering.

First: What Is Bitcoin, Actually?

Before Lightning makes any sense, Bitcoin has to make sense. And I mean the technical version, not the investment version.

Bitcoin is a distributed ledger :— a database that no single person owns or controls, replicated across thousands of computers around the world. Every 10 minutes or so, a new "block" of transactions gets added to this ledger. That chain of blocks is the blockchain.

Here's the key property that makes it interesting: once a transaction is written into the chain, it is practically irreversible. There's no customer service desk. There's no refund button. The database is append-only, and changing historical records would require redoing an astronomically expensive amount of computational work.

This is great for finality. It's terrible for speed.

The Problem: Bitcoin Is Slow By Design

Bitcoin's base layer processes roughly 7 transactions per second. Globally. For everyone.

Visa handles tens of thousands per second. M-Pesa handles millions of transactions per day in Kenya alone. Bitcoin, as a base layer, cannot compete on throughput, and that's not a bug, it's a consequence of the tradeoffs that make it trust-less and decentralized.

So what do you do if you want fast, cheap Bitcoin payments? You build on top of it. That's where Lightning comes in.

What Is the Lightning Network?

The Lightning Network is Bitcoin's Layer 2 — a payment network that sits on top of Bitcoin and inherits its security without inheriting its slowness.

The core idea is elegant: what if two people could transact with each other thousands of times, but only touch the blockchain twice?

Once to open the channel. Once to close it.

Everything in between happens off-chain, instantly, with near-zero fees.

The Analogy That Made It Click For Me

Imagine you and a colleague work in the same office and you frequently owe each other small amounts like lunch money, airtime, split bills. Every time you settle, you don't go to the bank. You keep a running tab. "I owe you 200, you owe me 350 net, you owe me 150." At the end of the month, one person pays the other. One transaction.

A Lightning channel is that tab, except it's crypto-graphically enforced, so neither party can cheat. You put real Bitcoin into it when you open it. The channel tracks who owns what. When you're done, you close it and the final balances get written to the blockchain.

Scale this to millions of people with overlapping channels, and you have a network where you can pay anyone, even without a direct channel to them just by routing through intermediate nodes.

What we Actually Built

This was a structured bootcamp environment with a real set of goals:

Compile Bitcoin Core from source (no sudo apt install shortcuts)
Build a Bitcoin Explorer CLI in Go using only the standard library
Set up a two-node Lightning Network with LND in regtest
Fund channels, make payments, and observe what happens

Let's take a tour of each stage.

Part 1: Compiling Bitcoin Core From Source

Most guides tell you to download a binary. We didn't do that. We compiled Bitcoin Core v31.99.0 directly from source code, without sudo privileges.

Why does this matter? Because in production fintech systems, you often can't just trust a binary you downloaded. Compiling from source means you're running exactly what the code says — nothing added, nothing modified.

The process taught me something I hadn't thought about before: software has dependencies on dependencies on dependencies. Getting Bitcoin Core to compile meant first ensuring the right versions of Boost, lib-event, and other libraries were present. The compiler errors are honest and they tell you exactly what's missing.

Once compiled, I ran it in regtest mode.

What Is Regtest?

Regtest (short for regression test) is a local, private Bitcoin network that only exists on your machine. You control everything: the mining, the blocks, the funds. You can mine 1000 blocks in a second. It's basically a sandbox.

This is how you develop and test anything Bitcoin-related without spending real money or waiting for real confirmations.

Part 2: Building a Bitcoin Explorer CLI in Go

With Bitcoin Core running, I built a command-line tool in Go that could query it.

Bitcoin Core exposes a JSON-RPC interface — you send it HTTP POST requests with JSON bodies, and it responds with blockchain data. Think of it as the node's API.

Here's a minimal example of what that looks like in Go:

go
package main

import (
"bytes"
"encoding/json"
"fmt"
"net/http"
)

type RPCRequest struct {
Method string json:"method"
Params []interface{} json:"params"
ID int json:"id"
JSONRPC string json:"jsonrpc"
}

func callRPC(method string, params []interface{}) (map[string]interface{}, error) {
req := RPCRequest{
Method: method,
Params: params,
ID: 1,
JSONRPC: "1.0",
}

body, _ := json.Marshal(req)

resp, err := http.Post(
    "http://localhost:18443/",
    "application/json",
    bytes.NewBuffer(body),
)
if err != nil {
    return nil, err
}
defer resp.Body.Close()

var result map[string]interface{}
json.NewDecoder(resp.Body).Decode(&result)
return result, nil

}

func main() {
info, _ := callRPC("getblockchaininfo", nil)
fmt.Println(info)
}

The constraint was standard library only, no external HTTP clients, no JSON helper packages beyond encoding/json. This was intentional. It forced me to understand exactly what was happening at the network level, not abstract it away.

The explorer could query block height, fetch transaction details by ID, decode raw transactions, and display UTXO (Unspent Transaction Output) information. UTXOs are how Bitcoin actually tracks balances — not accounts, but unspent outputs you have the right to spend.

Part 3: Setting Up Two LND Nodes

LND (Lightning Network Daemon) is the most widely used Lightning implementation, written in Go by Lightning Labs.

I set up two nodes: Alice and Bob. Each one was a separate LND instance, each connected to the same local Bitcoin Core regtest node.

The configuration looks roughly like this for Alice:

ini
[Application Options]
datadir=/home/user/bootcamp-lnd/alice/data
logdir=/home/user/bootcamp-lnd/alice/logs
listen=0.0.0.0:9735
rpclisten=0.0.0.0:10009
restlisten=0.0.0.0:8080
noseedbackup=true

[Bitcoin]
bitcoin.active=1
bitcoin.regtest=1
bitcoin.node=bitcoind

[Bitcoind]
bitcoind.rpchost=localhost
bitcoind.rpcuser=your_rpc_user
bitcoind.rpcpass=your_rpc_password
bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332
bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333

Bob gets his own instance on different ports. Same structure, different directories, different ports.

The ZMQ Issue (and Why It Matters)

One thing that tripped me up: LND communicates with Bitcoin Core not just through RPC, but also through ZMQ (ZeroMQ) — a messaging protocol that lets Bitcoin Core push new block and transaction notifications to LND in real time.

Without ZMQ configured correctly, LND would start but wouldn't know about new blocks. Payments would appear to hang. The fix was ensuring zmqpubrawblock and zmqpubrawtx were properly set on both the Bitcoin Core side and the LND config side, and that the ports matched.

This is the kind of thing a tutorial glosses over. In practice, it's the difference between a working node and a node that silently does nothing.

Part 4: Funding a Channel

Once both nodes were running, I connected them:

bash

Get Alice's node info

lncli --rpcserver=localhost:10009 getinfo

Connect Alice to Bob (using Bob's pubkey@host:port)

lncli --rpcserver=localhost:10009 connect @localhost:9736

Open a channel from Alice to Bob, funding it with 1,000,000 satoshis

lncli --rpcserver=localhost:10009 openchannel --node_key= --local_amt=1000000

Opening a channel requires an on-chain transaction. So I mined a few blocks to confirm it:

bash
bitcoin-cli -regtest generatetoaddress 6

After 3 confirmations, the channel was active. Alice had 1,000,000 satoshis of outbound liquidity :- meaning she could send up to that amount to Bob. Bob had zero outbound liquidity toward Alice unless he funded his side too.

This asymmetry is one of the most important (and often confusing) things about Lightning. Liquidity is directional. Having a channel doesn't mean you can pay in both directions, it depends on where the funds sit within that channel.

Part 5: Making a Payment

With the channel open, Bob creates an invoice, essentially a payment request:

bash
lncli --rpcserver=localhost:10036 addinvoice --amt=50000 --memo="Coffee"

This spits out a BOLT11 payment string :- a long encoded string that starts with lnbcrt... in regtest. It contains the amount, a payment hash, Bob's public key, and an expiry time.

Alice pays it:

bash
lncli --rpcserver=localhost:10009 payinvoice

This happens in under a second. No block confirmation required. The channel's internal balance shifts: Alice now has 950,000 satoshis, Bob has 50,000. The blockchain hasn't changed at all. That shift only gets recorded on-chain when the channel closes.

The LND REST API

At the end of the bootcamp, I was also given access to a remote regtest LND node via its REST API, a taste of what integrating Lightning into a real backend looks like.

LND exposes every operation through HTTP endpoints. To check node info:

bash
curl -k \
-H "Grpc-Metadata-macaroon: " \
https://your-lnd-node/v1/getinfo

Macaroons are LND's authentication mechanism bearer tokens with baked-in permissions. The admin macaroon can do everything. The invoice macaroon can only create and read invoices. You'd use the invoice macaroon in a web server that generates payment requests, and never expose the admin macaroon to anything internet-facing.

In Go, you'd integrate this with:

go
tr := &http.Transport{
TLSClientConfig: &tls.Config{InsecureSkipVerify: true}, // only for dev/regtest
}
client := &http.Client{Transport: tr}

req, _ := http.NewRequest("GET", "https://your-lnd-node/v1/getinfo", nil)
req.Header.Set("Grpc-Metadata-macaroon", adminMacaroonHex)

resp, err := client.Do(req)

This is the pattern you'd use when building a payment backend on top of Lightning, creating invoices on demand, polling for payment confirmation, and triggering downstream actions (like unlocking content or marking an order as paid) when the payment settles.

What This Changes About How I Think

Before this bootcamp, I understood Lightning conceptually. After it, I understand it structurally. There's a difference.

A few things that specifically shifted:

Settlement finality is not binary. On-chain Bitcoin is "final" after enough confirmations. Lightning is final the moment the HTLC (Hash Time Locked Contract) resolves. Different guarantees, different use cases. Knowing which one you need matters when you're designing a payment flow.

How HTTPS Actually Works: TLS, Certificates, and Encryption

Juma Evans — Fri, 24 Jul 2026 23:41:00 +0000

Analogy

Imagine you're sitting in a coffee shop.

You connect to the free Wi-Fi.

You decide to log into your bank account.

Your browser sends your username and password over the network.

Now imagine every person connected to that same Wi-Fi can read everything you're sending.

Your password.

Your balance.

Your account number.

Terrifying.

Yet that's exactly how the early Internet worked.

There was no encryption.

No certificates.

No secure connections.

Just plain text traveling across the network.

HTTPS was invented to solve this problem.

But here's the fascinating part:

Your browser has never met your bank's server before.

So how do two complete strangers agree on a secret encryption key while an attacker is listening to every message?

Let's find out.

Before HTTPS

HTTP sends everything as plain text.

Imagine requesting a webpage.

GET /login HTTP/1.1
Host: bank.com

username=alice
password=myPassword123

Anyone who intercepts this packet can read it.

Wireshark.

Hackers.

Malicious Wi-Fi hotspots.

ISPs.

Nothing is hidden.

HTTP provides functionality.

It provides zero confidentiality.

Enter HTTPS

HTTPS is simply:

HTTP

TLS

Notice something important.

HTTP didn't change.

TLS wraps HTTP in encryption.

Think of TLS as an armored truck carrying ordinary letters.

The letters remain the same.

The transport becomes secure.

What Does HTTPS Actually Protect?

HTTPS provides three major guarantees.

1. Confidentiality

Nobody can read your data.

Even if someone captures every packet...

They see encrypted gibberish.

Instead of:

password=OpenSesame
They see:
8FA91B4D928AC17C3D...

2. Integrity

Imagine a hacker intercepts:
Transfer $100 and changes it to:

Transfer $10,000

TLS detects that the message was modified.

The connection immediately fails.

3. Authentication

How do you know you're actually talking to your bank?

Not a fake server pretending to be it?

This is where certificates enter the picture.

The Biggest Problem

Imagine I want to send you a locked box.

I lock it.

Now...

How do I safely send you the key?

If I send the key with the box...

Anyone can steal both.

This is exactly the problem HTTPS had to solve.

Symmetric Encryption

Symmetric encryption uses one secret key.

Key
↓
Encrypt
↓
Ciphertext
↓
Decrypt
↓
Same Key

Advantages:

Extremely fast
Perfect for large files
Efficient

Problem:

Both sides need the same secret key.
How do they agree on that key?
Asymmetric Encryption

Instead of one key...

There are two.
Public Key
Private Key

Anyone may know the public key.
Nobody should ever know the private key.

Think of it like a mailbox.
Anyone can drop letters inside.
Only the owner can open it.

Why Not Encrypt Everything with RSA?

RSA (or modern alternatives like Elliptic Curve Cryptography) is computationally expensive.

Encrypting an entire Netflix movie with asymmetric encryption would be painfully slow.

Instead HTTPS combines both worlds.
Fast symmetric encryption.
Safe asymmetric key exchange.

The best of both.

Meet TLS

TLS performs a handshake before any HTTP data is exchanged.

This handshake establishes trust.

Generates shared secrets.
Chooses encryption algorithms.
Verifies certificates.
Only after all of this...
Does HTTP begin.

Step 1 — Client Hello

Your browser starts.
Hello!

I support:
AES
ChaCha20
TLS 1.3

Random Number

Think of this as introducing yourself.

Step 2 — Server Hello

The server replies.

Great.

Let's use:

TLS 1.3

AES-256

Here's my certificate.

Now comes the interesting part.

Step 3 — Certificate

The certificate contains information like:

Domain

Public Key

Expiration Date

Certificate Authority

Digital Signature

Notice...

The server isn't saying:

"Trust me."

Instead it's saying:

"Someone you already trust verified me."

Certificate Authorities

Browsers already trust organizations like:

Let's Encrypt
DigiCert
GlobalSign
Sectigo

When a certificate is signed by one of these trusted authorities, the browser can verify that signature.

It's similar to a passport.
You don't personally know the passport holder.
You trust the government that issued it.
What If Someone Creates a Fake Certificate?
Suppose an attacker generates a fake certificate for:

bank.com

The browser checks the digital signature.
It doesn't match any trusted Certificate Authority.

Immediately:
Your connection is not private.
The browser refuses the connection
Key Exchange

Now the browser knows it's talking to the real server.

Both sides perform a key exchange (commonly using Elliptic Curve Diffie–Hellman Ephemeral (ECDHE) in TLS 1.3) to derive the same shared secret.

Here's the remarkable part:

Neither side ever sends the secret encryption key across the network.

They independently calculate the same shared key using exchanged public information and their own private values.

Even if someone captures every packet, they cannot derive the session key.

This is one of the cleverest ideas in modern cryptography.

Session Keys

Once both sides derive the shared secret...

RSA (or more accurately in modern TLS, the key exchange mechanism) has done its job.

From this point onward...

Everything uses symmetric encryption.

Usually:

AES-GCM
ChaCha20-Poly1305

Because they're much faster.

Why HTTPS Is Fast

Many developers assume HTTPS encrypts every message with RSA.

It doesn't.

RSA or ECDHE helps establish the secure session.

After that...

Symmetric encryption handles almost all application data.

This is why HTTPS is nearly as fast as HTTP on modern hardware.

What Happens Every Time You Visit a Website?

The flow looks like this:

Browser
↓
TCP Connection
↓
TLS Handshake
↓
Certificate Verification
↓
Key Exchange
↓
Shared Secret
↓
Encrypted HTTP
↓
Website Loads

Common Myths
"HTTPS encrypts the entire Internet."

No.

It encrypts the communication between your client and the server.

"HTTPS hides which website I'm visiting."

Not entirely.

Your ISP can usually see the destination IP address and some metadata, although modern technologies reduce what is exposed.

"The padlock means the website is safe."

No.

It only means the connection is encrypted and the certificate is valid.

A phishing website can also have HTTPS.

"HTTP is obsolete."

Not completely.

HTTP still exists.

HTTPS is simply HTTP running over TLS.

Real-World Examples

Uses HTTPS:

Online banking
GitHub
Gmail
Amazon
APIs
Payment systems

Without HTTPS:

Passwords
Cookies
Tokens
Credit card numbers

would all travel in plain text.

Interview Questions
a.Why does HTTPS need certificates?

To verify the server's identity and prevent attackers from impersonating legitimate websites.

b.Why use both symmetric and asymmetric encryption?

Asymmetric encryption (or key exchange) solves the problem of establishing trust and securely deriving a shared secret. Symmetric encryption is then used because it's much faster for encrypting the actual data.

c.Why is HTTPS built on TCP?

TLS requires reliable, ordered delivery during the handshake and while exchanging encrypted records. TCP provides those guarantees.

d.Does HTTPS stop hackers?

It protects data in transit between you and the server.

It does not protect against:

Weak passwords
SQL Injection
XSS
Malware on your computer
Social engineering

HTTPS solves one specific problem:

Protecting communication while it's traveling across the network.

Key Takeaways

Every time you visit an HTTPS website, your browser and the server perform a carefully orchestrated dance before a single web page is loaded. They agree on encryption algorithms, verify the server's identity through a trusted certificate, securely derive a shared secret without ever transmitting it, and then switch to fast symmetric encryption for the rest of the session.

The result is that even if someone intercepts every packet traveling across the network, they cannot read or modify the protected data without the session keys.

That small padlock in your browser represents decades of cryptographic research working together to make everyday activities—like online banking, shopping, email, and APIs—secure enough to use over an untrusted Internet.

TCP or UDP? Choosing the Right Protocol

Juma Evans — Fri, 24 Jul 2026 23:00:46 +0000

1. Analogy

Imagine you're sending your friend a 500-page book.

You have two delivery companies.

The first guarantees every page arrives in order.
If page 187 gets lost, they'll resend only page 187.

The second company is incredibly fast.
They throw pages onto trucks immediately.
If page 187 disappears...

They simply keep driving.

Which company would you choose?

The answer depends on what you're sending.

That's exactly why the Internet has TCP and UDP.

Why One Protocol Isn't Enough

Different applications have different priorities.

Imagine these scenarios:

Downloading Ubuntu ISO

↓

Watching Netflix

↓

Video Calling

↓

Playing Valorant

↓

Sending Bank Transactions

Should they all behave the same?

Absolutely not.

A.Meet TCP

TCP says:

I refuse to lose data.

Its priorities:

✔ Reliability

✔ Correct order

✔ Error recovery

✔ Flow control

✔ Congestion control

Not speed.

How TCP Works

Before sending anything:

TCP says:

Let's introduce ourselves.

This is the famous Three-Way Handshake.

Client Server

SYN ------------------>

  <----------------  SYN-ACK

ACK ------------------>

Now both sides know:

"I'm ready."

Only then does data start flowing.

Explanation:

SYN
ACK
Sequence Numbers
Sequence Numbers

Imagine sending:

Hello World

TCP splits it.

Packet 1

Packet 2

Packet 3

Each receives a number.

If packet 2 disappears:

❌

The receiver says:

"I got 1."

"I got 3."

"I'm still missing 2."

TCP resends only packet 2.

This is reliability.

Acknowledgments

Every successful delivery receives an ACK.

Packet

↓

ACK

No ACK?

Resend.

Simple.

Flow Control

Imagine:

Sender:

1000 Mbps

Receiver:

20 Mbps

Without control:

The receiver drowns.

TCP asks:

"How much can you handle?"

Receiver answers:

512 KB

TCP obeys.

Congestion Control

What if the Internet itself is busy?

Highways become congested.

TCP slows down.

Not because the receiver is slow.

Because the network is crowded.

Explain:

Traffic jam analogy.

B.Meet UDP

UDP has one philosophy.

Send it.

That's it.

No handshake.

No acknowledgments.

No retries.

No ordering.

No waiting.

UDP in Action
Packet 1

↓

Packet 2

↓

Packet 3

Packet 2 disappears.

UDP simply continues.

❌

No resend.

Why Would Anyone Want That?

Because sometimes waiting is worse than losing data.

Example:

a.Video Call

Imagine hearing:

Hello...

(wait 3 seconds)

How...

(wait)

are...

(wait)

you?

Terrible.

Instead,

if one audio packet disappears...

Your brain barely notices.

Speed matters more than perfection.

b.Gaming

Suppose you're playing FIFA.

Every 16 milliseconds your position changes.

If one packet disappears:

Do you want the old position?

No.

You want the newest one.

Old data is useless.

UDP wins.

c.Live Streaming

Watching football.

Frame 246 disappears.

Should Netflix stop?

No.

Show frame 247.

Keep going.

d.DNS Uses UDP Too

DNS requests are tiny.

Where is github.com?

The answer is tiny too.

If one packet gets lost:

Just ask again.

Using TCP would waste time establishing a connection for every lookup.

That's why most DNS queries use UDP.

When TCP Wins

Downloading files.

Example:

Linux ISO

PDF

ZIP

Database backup

One missing byte corrupts the entire file.

TCP ensures:

Nothing is lost.

Common Applications
TCP UDP
HTTP DNS
HTTPS VoIP
SSH Online Gaming
FTP Live Streaming
Email DHCP
Database Connections NTP

TCP vs UDP
Feature TCP UDP
Connection Yes No
Reliable Yes No
Ordered Delivery Yes No
Error Recovery Yes No
Speed Slower Faster
Header Size 20–60 bytes 8 bytes
Best For Files, APIs, Banking Games, Calls
How the OSI Model Fits

TCP and UDP both live in:

Layer 4

Transport Layer

Above them:

HTTP

HTTPS

DNS

SMTP

Below them:

Ethernet

Wi-Fi

Interview Questions

a.Why doesn't TCP always replace UDP?

Because reliability has a cost. Handshakes, acknowledgments, retransmissions, and congestion control all add latency.

b.Why doesn't UDP replace TCP?

Because some data must arrive intact and in order. Losing a byte in a bank transaction or software download is unacceptable.

c.Can UDP be made reliable?

Yes. Applications can implement their own reliability mechanisms on top of UDP. A good example is QUIC, which runs over UDP and powers HTTP/3 by handling reliability and security in user space.

d.Why does HTTP/3 use UDP?

Because it builds its own transport features on top of UDP, avoiding some of TCP's limitations—particularly connection setup delays and head-of-line blocking.

Final Takeaways

TCP and UDP aren't competitors trying to replace one another. They solve different problems. TCP prioritizes reliability, ensuring data arrives completely, in order, and without corruption. UDP prioritizes speed and low latency, accepting occasional packet loss when timely delivery is more important than perfect delivery.

The next time you're downloading a file, making a video call, joining an online game, or performing a DNS lookup, you'll know why the Internet chooses one protocol over the other.

Understanding the OSI Model Through One Network Request

Juma Evans — Fri, 24 Jul 2026 22:30:10 +0000

The Hook

Every networking course begins with the same seven mysterious layers:

Physical
Data Link
Network
Transport
Session
Presentation
Application

Students memorize them.

Developers ignore them.

Network engineers live by them.

But here's the problem:

Most people never learn why these layers exist.

In this article, we'll follow a single message;"Hello, Server!" as it travels through every OSI layer, crosses routers and switches, reaches another computer, and climbs back up the stack.

By the end, you'll understand not just the names of the layers, but why the Internet couldn't exist without them.

The Story

Imagine you open your browser.

https://github.com

You press Enter.

Now follow that request.

Layer 7 : Application

This is where humans interact with software.

Examples:

Browser
WhatsApp
Discord
Gmail
Spotify

The browser creates:

GET / HTTP/1.1
Host: github.com

Notice:

No IP.

No MAC address.

No Ethernet.

Just application data.

Layer 6 : Presentation

This layer asks:

How should the data look?

Examples include:

Encryption (TLS/SSL)
Compression (gzip)
Character encoding (UTF-8)
Serialization (JSON, XML, Protocol Buffers)

Here your HTTP request is encrypted into ciphertext before leaving your machine.

Without this layer:

Everyone on the network could read your passwords.

Layer 5 : Session

This layer manages conversations.

Think of it as the meeting organizer.

Responsibilities include:

Opening communication
Keeping it alive
Reconnecting if interrupted
Closing the session cleanly

Modern TCP/IP doesn't expose this as a separate layer, but the concept still exists in many protocols.

Layer 4 : Transport

Now things become interesting.

Imagine sending a 100 MB video.

Should it be one enormous packet?

No.

Transport breaks it into manageable pieces called segments.

It also adds:

Source port
Destination port
Sequence number
Acknowledgments
Error recovery

Protocols:

TCP
UDP

Analogy:

A courier numbers every box before shipping.

If Box #7 disappears...

Only Box #7 is resent.

Layer 3 : Network

Now we need directions.

The Network layer adds:

Source IP

Destination IP

Example:

192.168.1.10

↓

140.82.121.3

Routers read this information.

Their only job is:

Which road gets this packet closer to its destination?

Think Google Maps.

Layer 2 : Data Link

Now the packet reaches your home Wi-Fi.

The router doesn't care about IP first.

It wants:

MAC Address

Why?

Because devices communicate locally using hardware addresses.

The frame now contains:

Destination MAC

Source MAC

Payload

Switches live here.

They forward frames only to the correct device.

This is why switches are much smarter than hubs.

Layer 1 : Physical

Finally...

Everything becomes electricity.

Or light.

Or radio waves.

Bits become:

101001011010011001

Those bits travel through:

Copper cables
Fiber optics
Wi-Fi radio
Satellite signals

Layer 1 doesn't know HTTP.

It doesn't know IP.

It doesn't even know bytes.

It only knows:

1
Encapsulation

Here's the beautiful part.

Each layer wraps the previous layer with its own information.

Think of Russian nesting dolls.

Application Data

↓

Segment

↓

Packet

↓

Frame

↓

Bits

Or like mailing a package:

Letter

↓

Envelope

↓

Shipping Box

↓

Truck

↓

Road

Each layer adds just enough information for the next part of the journey.

At the Destination

The server receives:

Bits

↓

Frame

↓

Packet

↓

Segment

↓

Application Data

Each layer removes the information added by its counterpart on the sender's side.

This process is called decapsulation.

Eventually GitHub receives:

GET /

and responds with HTML.

Which Devices Work at Each Layer?
Layer Device
7 Browser, Web Server
6 TLS, SSL
5 Session managers
4 TCP, UDP
3 Router
2 Switch
1 Cable, Fiber, Wi-Fi

This table alone helps readers connect abstract layers to real-world hardware and software.

Why Was the OSI Model Invented though?

Before the OSI model, networking vendors often built proprietary systems that worked only with their own hardware and software. There wasn't a common language for how devices should communicate.

The OSI model introduced a layered architecture where each layer has a single responsibility and communicates only with the layers directly above and below it.

This separation provides several advantages:

Modularity: You can improve one layer without redesigning the entire stack.
Interoperability: Devices from different vendors can communicate because they follow the same layer responsibilities.
Troubleshooting: Network problems become easier to isolate. If you can't even establish a physical connection, there's no point debugging HTTP.
Scalability: New technologies can be introduced within a layer without affecting the rest of the system.

Although the Internet actually uses the simpler TCP/IP model, the OSI model remains one of the best conceptual tools for understanding how data moves across networks.

A Developer's View of the OSI Model

When you're writing backend services or APIs, you interact with multiple layers—even if you don't think about them:

You build REST or GraphQL APIs at the Application layer.
HTTPS relies on Presentation layer concepts like encryption.
Socket connections and ports depend on the Transport layer.
IP addresses and routing involve the Network layer.
Switches, Ethernet, and Wi-Fi operate at the Data Link and Physical layers.

Understanding where a problem occurs makes debugging much faster.

Key Takeaways

The OSI model isn't just a list to memorize for an exam—it's a way of thinking about networking. Every request you send travels down the stack, where each layer adds the information needed for its specific job. It crosses the network as electrical signals, light, or radio waves, then climbs back up the layers on the receiving machine until the original application data is reconstructed.

Once you see networking as a journey through these seven layers rather than seven isolated definitions, concepts like routers, switches, TCP, IP, TLS, and HTTP start fitting together naturally.

DNS Lookup Explained

Juma Evans — Fri, 24 Jul 2026 22:04:46 +0000

What Really Happens When You Visit a Website?

You type google.com.

Less than a second later you're watching YouTube, reading emails, or searching the web.

It feels instant.

But before your browser can even request a webpage, an entire conversation happens across the Internet.

Your computer has one important question:

"Where is google.com?"

That question is answered by one of the oldest and most important systems on the Internet:

DNS — the Domain Name System.

Think of DNS as the Internet's phonebook.

Instead of remembering IP addresses like

142.250.190.46
we remember names like;

google.com

DNS translates those human-friendly names into machine-friendly IP addresses.

Let's see exactly how that happens.

Why Do We Need DNS?

Imagine if every person in your contacts list had no names.

Instead of calling Mom, you'd have to memorize:

+254712345678

Now imagine doing that for every person you've ever met.

Almost impossible.

Computers have the same problem.

They communicate using IP addresses.

Humans communicate using names.

DNS bridges that gap.

The Journey Begins

Suppose you enter:

https://github.com

Your browser doesn't know where GitHub lives.

It starts asking around.

The entire lookup looks something like this:

You
│
▼
Browser Cache
│
▼
Operating System Cache
│
▼
Recursive DNS Resolver
│
▼
Root Name Server
│
▼
TLD Name Server (.com)
│
▼
Authoritative Name Server
│
▼
GitHub IP Address

Let's visit each stop.

Step 1 — Browser Cache

Your browser first checks:

Have I visited GitHub recently?

If yes...
github.com

↓

140.82.121.3
Done.

No Internet lookup needed.

Every browser keeps a temporary DNS cache.

Step 2 — Operating System Cache

If the browser doesn't know...

it asks the operating system.

Windows, Linux, and macOS all maintain DNS caches.

Example:

github.com

↓

140.82.121.3

Still no network request.

Step 3 — Recursive Resolver

If nobody knows...

your computer asks a DNS resolver.

Usually this belongs to:

Your ISP
Google DNS (8.8.8.8)
Cloudflare (1.1.1.1)
Quad9

The resolver's job is simple:

"Don't worry.
I'll find the answer."

This resolver does all the heavy lifting.

Step 4 — Root Name Server

The resolver first asks a Root Server:

Where is github.com?

The root server replies:

"I don't know GitHub...

but I know who manages .com."

Notice something important.

The root server doesn't know every website.

It only knows where to find top-level domains.

Step 5 — TLD Name Server

Next stop:

.com

The resolver asks:

Where is github.com?

The .com server replies:

"Ask GitHub's authoritative server."

Again...

No IP address yet.

Just directions.

Step 6 — Authoritative Name Server

Finally the resolver reaches GitHub's own DNS server.

Now it asks:

What is github.com?

The server replies:

140.82.121.3

Finally!

Now the resolver returns the answer to your computer.

Step 7 — The Browser Makes the Real Request

Only now can your browser send:

GET /
Host: github.com

140.82.121.3

DNS lookup is finished.

Only then does HTTPS begin.

Visualizing the Entire Journey
You

↓

Browser Cache

↓

OS Cache

↓

Recursive Resolver

↓

Root Server

↓

.com Server

↓

GitHub Authoritative Server

↓

IP Address

↓

Browser connects

Notice that DNS itself doesn't deliver webpages—it only answers the question:

"Which IP address should I connect to?"

Recursive vs. Authoritative DNS

These two are often confused.

Recursive Resolver

Think of it as your personal assistant.

You ask one question.

It does all the research.

You

↓

Resolver

↓

Internet

Examples:

Google DNS
Cloudflare DNS
ISP DNS
Authoritative Server

This server owns the official answer.

Example:

github.com

↓

140.82.121.3

Nobody argues with the authoritative server.

It's the source of truth.

Why DNS Is So Fast

The first lookup may take a few milliseconds.

The second lookup?

Almost instant.

Why?

Caching.

Once the resolver learns:

github.com

↓

140.82.121.3

it stores the answer.

The next thousand users can reuse it.

This dramatically reduces Internet traffic.

What Is TTL?

Every DNS record has a value called:

TTL

Time To Live

Example:

TTL = 3600

means

Keep this answer for one hour.

After that...

the resolver asks again.

TTL prevents outdated IP addresses from living forever.

Common DNS Record Types

DNS stores more than IP addresses.

Here are the most common record types you'll encounter:

Record Purpose
A Maps a domain to an IPv4 address
AAAA Maps a domain to an IPv6 address
CNAME Points one domain to another domain
MX Specifies mail servers for email delivery
TXT Stores text data, often used for verification and security (SPF, DKIM, DMARC)
NS Identifies the authoritative name servers for a domain

Example:

blog.example.com

↓

CNAME

↓

hosting.example.net
Try It Yourself

On Linux or macOS:

dig github.com

nslookup github.com

Example output:

github.com

140.82.121.3

You can even ask specific DNS servers:

dig @8.8.8.8 github.com

dig @1.1.1.1 github.com

This is a great way to compare responses from different resolvers.

Common Interview Questions
a.Why don't browsers connect directly using the domain name?

Because network communication happens using IP addresses. DNS translates human-readable domain names into those addresses.

b.What happens if DNS fails?

Your browser doesn't know where the server is.

You'll typically see errors like:

DNS_PROBE_FINISHED_NXDOMAIN

Server not found

c.Why are there multiple DNS servers?

The DNS hierarchy distributes responsibility. Root servers know top-level domains, TLD servers know authoritative servers, and authoritative servers know the actual records. This makes DNS scalable, resilient, and decentralized.

d.Does DNS happen every time I visit a website?

Not necessarily. Browsers, operating systems, and recursive resolvers cache DNS responses until the TTL expires.

Key Takeaways

Whenever you type a domain name into your browser, a carefully orchestrated lookup begins. Your browser checks its cache, then your operating system, then a recursive resolver. If needed, that resolver consults the root servers, the appropriate top-level domain server, and finally the authoritative name server to obtain the correct IP address. The result is cached for future requests, allowing subsequent lookups to happen much faster.

Without DNS, we'd have to remember numerical IP addresses for every website we visit. Instead, DNS provides a distributed, scalable naming system that makes the modern Internet usable.

The next time you type github.com or google.com and the page loads almost instantly, remember that an entire network of DNS servers worked together in just a few milliseconds to answer one simple question:

"Where can I find this website?"

How the Internet Works: From Typing a URL to Seeing a Website

Juma Evans — Sat, 04 Jul 2026 01:35:09 +0000

Every day we open a browser, type a website address, and within a few seconds a webpage appears. It feels almost magical, yet behind that simple action is a chain of technologies working together seamlessly.

If you've ever wondered what happens after pressing Enter, this article is for you. We'll follow a single request from your browser all the way to the server and back while explaining the core concepts every backend developer should know.

The Big Picture

Imagine you type:

https://roadmap.sh

into your browser.

Several things happen almost instantly:

Your device connects to the Internet.
The browser asks, "Where is roadmap.sh?"
DNS translates the name into an IP address.
The browser connects to the server.
An HTTP request is sent.
The server responds with HTML, CSS, JavaScript, and other resources.
The browser renders the webpage.

Let's understand each step.

What Is the Internet?

The Internet is simply a massive network of interconnected computers.

Every computer connected to the Internet can communicate with another computer using agreed-upon rules called protocols.

Think of it as an international postal system.

Computers are houses.
IP addresses are street addresses.
Routers are post offices.
Packets are letters.
Protocols are the rules everyone follows.

Instead of sending one huge file, computers divide information into packets.

Each packet contains:

the sender's address
the destination address
part of the data
instructions for reassembling everything

Routers forward these packets until they reach their destination.

What Is an IP Address?

Every device connected to the Internet has an address.

For example:

192.168.1.20

172.217.170.110

These are called IP addresses.

Just like your home has a postal address, every computer has an IP address so other computers know where to send information.

There are two common versions:

IPv4 (32-bit)
IPv6 (128-bit)

Since the number of Internet-connected devices keeps growing, IPv6 was introduced to provide a much larger address space.

Why Don't We Type IP Addresses?

Imagine remembering this every time you wanted to visit GitHub:

140.82.121.3

Instead we use:

github.com

Humans remember names better than numbers.

This is where domain names come in.

What Is a Domain Name?

A domain name is a human-friendly name that points to a server.

Examples include:

github.com
roadmap.sh
google.com

A domain itself doesn't contain a website.

Instead, it's a label that maps to an IP address.

Think of your phone contacts.

You don't remember everyone's phone number.

You save:

Alice
Bob
John

Your phone remembers the numbers.

DNS works in almost exactly the same way.

What Is DNS?

DNS stands for Domain Name System.

It is often called the phonebook of the Internet.

Its job is simple:

Convert a domain name into an IP address.

When you type:

roadmap.sh

your browser doesn't know where that website lives.

It asks DNS:

"Can you tell me the IP address for roadmap.sh?"

DNS replies with something like:

104.xxx.xxx.xxx

Now the browser knows exactly where to send its request.

Without DNS, every website would have to be accessed using an IP address.

How DNS Works

DNS resolution happens in several steps.

1. Browser Cache

The browser first checks whether it already knows the IP address.

If it does, no DNS lookup is needed.

2. Operating System Cache

If the browser doesn't know, your operating system checks its own cache.

3. Recursive Resolver

If the answer still isn't found, the request is sent to your Internet Service Provider (ISP) or another DNS resolver.

Examples include Google's 8.8.8.8 or Cloudflare's 1.1.1.1.

4. Root Name Servers

If necessary, the resolver asks a root DNS server where to continue the search.

The root server doesn't know the final answer but points the resolver in the right direction.

5. Top-Level Domain (TLD) Servers

The resolver then contacts the server responsible for the domain extension.

Examples include:

.com
.org
.net
.ke

6. Authoritative Name Server

Finally, the resolver reaches the authoritative DNS server, which stores the actual DNS records for the domain.

It responds with the correct IP address.

The browser caches the result for future requests.

What Is Hosting?

A website has to live somewhere.

That "somewhere" is called hosting.

Hosting is a service that provides servers connected to the Internet so your application is available 24/7.

When you deploy an application, you're copying your code onto a server that other people can reach.

Examples include:

a Go API
a Node.js application
a static HTML website

Hosting providers manage the hardware, networking, storage, and uptime.

What Is HTTP?

Now that we know where the server is, we need a language both the browser and server understand.

That language is HTTP.

HTTP stands for:

HyperText Transfer Protocol

It defines how clients and servers communicate.

The browser sends a request.

The server sends a response.

Simple.

The Client-Server Model

A browser is called the client.

The computer hosting your application is called the server.

Communication looks like this:

Browser
   |
HTTP Request
   |
Server
   |
HTTP Response
   |
Browser

Every website follows this pattern.

Anatomy of an HTTP Request

An HTTP request contains:

Request method
URL
Headers
Optional body

Example:

GET /articles HTTP/1.1
Host: example.com

Common methods include:

GET

Retrieve data.

GET /users

POST

Create new data.

POST /users

PUT

Replace existing data.

PATCH

Update part of existing data.

DELETE

Remove data.

HTTP Responses

Servers respond with:

Status code
Headers
Body

Example:

HTTP/1.1 200 OK

Some common status codes are:

200 OK
201 Created
301 Moved Permanently
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
500 Internal Server Error

These codes tell the browser what happened.

What Is HTTPS?

HTTPS is simply HTTP with encryption.

The extra "S" stands for Secure.

HTTPS uses TLS (Transport Layer Security) to encrypt data between the browser and the server.

Without HTTPS, anyone intercepting network traffic could potentially read usernames, passwords, or other sensitive information.

Modern websites should always use HTTPS.

How Browsers Work

Browsers do much more than display text.

Once HTML arrives, the browser:

Parses the HTML.
Builds the Document Object Model (DOM).
Downloads CSS.
Downloads JavaScript.
Builds the CSS Object Model (CSSOM).
Combines them into a render tree.
Calculates layout.
Paints pixels on the screen.

This process happens incredibly quickly, often in just a fraction of a second.

Putting It All Together

Let's revisit what happens when you type:

https://roadmap.sh

Your browser checks its cache.
DNS translates the domain into an IP address.
The browser opens a connection to the server.
HTTPS secures the communication.
An HTTP request is sent.
The server processes the request.
HTML, CSS, JavaScript, and images are returned.
The browser parses and renders the page.
You see the website.

Thousands of lines of code and decades of engineering make those few seconds feel effortless.

Final Thoughts

Understanding networking isn't about memorizing acronyms—it's about understanding the journey of a request.

Once you know how the Internet, DNS, hosting, HTTP, and browsers fit together, backend development becomes much less mysterious. Frameworks and libraries may change over time, but these fundamentals remain the foundation of every web application you build.

The next time you press Enter after typing a URL, you'll know exactly what's happening behind the scenes, from name resolution and secure communication to rendering pixels on your screen.

Understanding these basics is one of the most valuable investments you can make as a software developer because every API, website, and distributed system ultimately builds upon them.

Goroutines vs. Promises: Why Go and JavaScript Look at Concurrency Completely Differently

Juma Evans — Mon, 25 May 2026 07:43:46 +0000

Handling concurrency is one of the most critical decisions in modern software architecture. When applications need to handle thousands of simultaneous tasks—like serving HTTP requests, streaming data, or background processing. The design of a language’s concurrency model dictates how easily developers can write fast, safe, and maintainable code.
Go is famous for making concurrency a native, deeply integrated primitive through goroutines and channels. To truly appreciate Go's design, it helps to contrast it with JavaScript, which handles concurrency using a completely different philosophy: a single-threaded Event Loop fueled by asynchronous non-blocking I/O.
Here is an architectural deep dive into Go's multi-threaded concurrency engine and how it measures up against JavaScript's single-threaded asynchronous model.

Part 1: The Foundations of Go Concurrency
Go’s concurrency model is based on a paper by C.A.R. Hoare called Communicating Sequential Processes (CSP). The core philosophy of CSP in Go can be summarized by its most famous mantra:
"Do not communicate by sharing memory; instead, share memory by communicating."
Instead of having multiple threads fight over the same piece of memory using complex locks, mutexes, and semaphores, Go encourages developers to run independent processes (goroutines) that pass data back and forth through safe conduits (channels).

Primitives: Goroutines and Channels
Go replaces heavy, operating system-level threads with goroutines.
Goroutines: They are incredibly lightweight, starting with a stack size of just a few kilobytes (typically 2KB), which can grow and shrink dynamically. Because they require so little overhead, a single Go application can easily spin up hundreds of thousands of concurrent goroutines without exhausting system memory.
Channels: These are typed pipelines that allow goroutines to synchronize and exchange data. By default, channels are unbuffered, meaning a sender will block until a receiver is ready to take the data, creating natural synchronization points without manual locks.
The Magic Under the Hood: The M:N Scheduler
Go achieves this high efficiency using its internal Go Runtime Scheduler, often referred to as the GMP Model:
G (Goroutine): Represents the goroutine, its stack, and current status.
M (Machine): Represents a physical, OS-level thread managed by the operating system kernel.
P (Processor): Represents a logical resource or context required to execute Go code. The number of Ps usually matches the machine's physical CPU cores.
The scheduler assigns multiple goroutines (G) onto a smaller pool of OS threads (M) via the logical processors (P).
If a goroutine performs a blocking action, such as waiting for a network response or a file read—the Go runtime is smart enough to swap out that blocked goroutine, move the remaining active goroutines to a different OS thread, and keep the CPU busy. This concept is known as work-stealing, and it happens completely automatically behind the scenes.

Part 2: Go Concurrency in Action
Writing concurrent code in Go requires very little boilerplate. You simply prefix a function call with the go keyword.
Here is a practical pattern: a worker pool where multiple concurrent workers process jobs sent via a channel, and report their progress safely.

package main

import (
"fmt"
"sync"
"time"
)

// worker processes incoming jobs from the jobs channel
func worker(id int, jobs <-chan int, results chan<- int, wg *sync.WaitGroup) {
defer wg.Done() // Signal completion when the worker exits

for job := range jobs {
    fmt.Printf("Worker %d started job %d\n", id, job)
    time.Sleep(time.Millisecond * 100) // Simulating an I/O task
    results <- job * 2
}

}

func main() {
numJobs := 5
jobs := make(chan int, numJobs)
results := make(chan int, numJobs)

var wg sync.WaitGroup

// Spin up 3 concurrent workers
for w := 1; w <= 3; w++ {
    wg.Add(1)
    go worker(w, jobs, results, &wg)
}

// Send jobs to the channel
for j := 1; j <= numJobs; j++ {
    jobs <- j
}
close(jobs) // Closing tells workers no more jobs are coming

// Wait for all workers to finish in the background
go func() {
    wg.Wait()
    close(results)
}()

// Collect all results
for res := range results {
    fmt.Printf("Result processed: %d\n", res)
}

}

Part 3: The Contender
How JavaScript Handles Asynchrony
While Go provides a multi-threaded runtime that automatically abstracts away hardware limitations, JavaScript takes an entirely opposite approach. JavaScript's core philosophy is single-threaded simplicity driven by an Event Loop.
JavaScript operates on exactly one thread of execution (the main thread). It cannot natively execute two mathematical formulas simultaneously on different CPU cores. To prevent this single thread from freezing when downloading data or reading files, JavaScript relies on Asynchronous Non-Blocking I/O.

Primitives: Promises and Async/Await
Instead of lightweight threads, JavaScript relies on Promises and state management.
Promises: A Promise is an object representing the eventual completion (or failure) of an asynchronous operation. When a network request is fired, JavaScript leaves a Promise placeholder and immediately frees up the main thread to handle other UI interactions or requests.
Async/Await: Syntactic sugar built over Promises. When you mark a function as async, it pauses execution inside that specific function when it hits an await keyword, returning control of the main thread back to the runtime execution engine until the background task is ready.

The Engine: The Event Loop
Because JavaScript doesn't have a multi-threaded scheduler, it passes heavy lifting (like cryptography, network calls, or disk interactions) off to its container environment (the browser's Web APIs or Node.js background thread pool).
Once those background operations finish, they drop their callbacks into a Task Queue. The Event Loop constantly monitors the main thread. If the main thread is empty, it grabs the next task from the queue and executes it.
Let's look at how JavaScript achieves a similar worker execution strategy using Promises and Promise.all:
// Simulating an asynchronous job
async function worker(id, job) {
console.log(Worker ${id} started job ${job});

// Simulating an I/O task (like a database query) using a non-blocking timeout
await new Promise(resolve => setTimeout(resolve, 100));

return job * 2;
}

async function main() {
const jobs = [1, 2, 3, 4, 5];

// Map our jobs into an array of concurrent Promises.
// JavaScript kicks them all off immediately in the background.
const workerPromises = jobs.map((job, index) => {
const workerId = (index % 3) + 1; // Distribute across 3 simulated workers
return worker(workerId, job);
});

// Wait for all background tasks to finish and collect results
const results = await Promise.all(workerPromises);

results.forEach(res => {
console.log(Result processed: ${res});
});
}

main();

Part 4: Head-to-Head Comparison
To understand which paradigm fits a project best, we have to look at the architectural trade-offs between Go's implicit multi-threaded runtime and JavaScript's single-threaded execution queue.
a. Primary Model & Execution Strategy
The Go Way: Uses Communicating Sequential Processes (CSP). Concurrency is handled by spinning up independent, lightweight threads (goroutines) that communicate safely by passing data through typed conduits called channels.
The JS Way: Uses an Event-Driven Architecture. Concurrency is handled on a single main thread via an Event Loop that relies on Promises and callbacks to manage tasks asynchronously.

b. Hardware & CPU Utilization
The Go Way: Multi-threaded by default. Go’s built-in scheduler automatically distributes workloads across all available physical CPU cores, allowing for true, simultaneous hardware parallelism.
The JS Way: Single-threaded by default. It executes code on only one CPU core. While it can handle thousands of tasks concurrently by overlapping wait times, it cannot execute tasks simultaneously on the same thread.
c. Task Mechanism & Memory Overhead
The Go Way: Driven by Goroutines, which are managed entirely by the Go runtime rather than the OS. They are incredibly lightweight, starting with a tiny memory footprint of just around 2KB per goroutine.
The JS Way: Driven by Promises and Async/Await. These are not threads, but rather JavaScript object state machines that track the progress of a background task, carrying the memory overhead of the V8 JavaScript engine.

d. Handling Heavy Math and Computation
The Go Way: Excellent. Because it can utilize multiple CPU cores, heavy computations, data processing, or cryptography can run in the background without affecting or slowing down the rest of the application.
The JS Way: Weak. Because everything runs on a single thread, any heavy mathematical calculation or CPU-bound task will completely freeze the Event Loop, stalling the entire application until the calculation finishes.

e.Inter-Task Communication
The Go Way: Features Native Typed Channels. This built-in primitive allows goroutines to pass data to one another seamlessly, acting as a natural synchronization barrier without needing manual memory locks.
The JS Way: Relies on patterns like EventEmitters, Streams, or Async Generators. Because there is only one thread, tasks don't need to coordinate memory access, but streaming data requires using event-based libraries.

f.Task Control and Preemption
The Go Way: Supports Preemption. The Go runtime scheduler is highly intelligent; if it notices a single goroutine is acting greedily and hogging a CPU core for too long, it will forcefully pause it to give other tasks a turn.
The JS Way: Has No Preemption. JavaScript code is strictly cooperative. If a function contains a long, synchronous loop that doesn't include an await keyword, it will hold the entire main thread hostage until it completes.

True Parallelism vs. Non-Blocking Concurrency The ultimate mechanical difference is Parallelism vs. Concurrency. Go is capable of parallelism. If you have an 8-core CPU processor, Go can run 8 different computing tasks at the exact same millisecond. If one goroutine goes rogue and gets stuck in an infinite mathematical calculation loop, Go's scheduler will forcefully step in (preemption), pause it, and use the other CPU cores to keep your application running smoothly. JavaScript is strictly concurrent but serial. It excels at waiting without locking things up. If 1,000 users request data from a database at once, JavaScript fires off all 1,000 queries to the OS database drivers immediately, moves on to do other things, and handles the results one by one as they crawl back. However, if you give JavaScript a heavy mathematical equation to calculate, it cannot delegate it to another core—the entire server or UI freezes completely until that calculation finishes.

2. Synchronization and Data Safety
Because Go shares memory across actual physical CPU threads, it introduces the danger of Data Races (two threads trying to change the exact same memory address at the same time). Go provides channels to prevent this, but if developers get careless, they must use manual mutex locks (sync.Mutex) or run Go's runtime race detector (go run -race) to find hidden multi-threading bugs.
JavaScript completely bypasses data races by design. Because everything ultimately executes on a single main thread, you never have to worry about two blocks of code altering a variable at the exact same millisecond. This completely eliminates a massive category of complex, hard-to-track multi-threading bugs.

3. Memory & Resource Footprint
Go's goroutines are remarkably lightweight (~2KB), but they still carry the overhead of an active, multi-threaded runtime scheduler and an internal Garbage Collector that scans heap allocations across threads.
JavaScript's basic Promises are incredibly cheap state objects, but because JavaScript runs inside engines like Google's V8, its base memory baseline per application instance is significantly larger than a compiled, lean Go binary.
Conclusion: Which tool is right for the job?
Choose Go if you are building data-intensive microservices, streaming platforms, heavy background computing tools, or high-throughput network APIs. Go gives your application the muscle to exploit your hardware's full multi-core capacity effortlessly.
Choose JavaScript if you are building fast I/O bound applications like standard CRUD web APIs, web sockets, or real-time chat apps where the vast majority of execution time is spent passing data back and forth from databases. JavaScript keeps code straightforward, predictable, and exceptionally easy to debug.
Both ecosystems solved the ancient problem of traditional, clunky OS multi-threading, Go by building a highly advanced multi-threaded coordination engine, and JavaScript by proving exactly how much you can achieve on a single thread if you just learn how to wait effectively.

Regulalar Expression

Juma Evans — Wed, 13 May 2026 01:47:34 +0000

Mastering Regular Expressions in JavaScript: From Basics to Real-World Validation

At first glance, a regex pattern looks like a cat walked across your keyboard,a chaotic string of slashes, brackets, and symbols. However, once you decode the syntax, it becomes one of the most powerful tools in your developer toolkit.
Below is the break down of how regex works in JavaScript and build a robust pattern to validate something we use every day: email addresses.

What is a Regular Expression anyways?

A Regular Expression is an object that describes a pattern of characters. In JavaScript, you can create them in two ways:

Literal Notation: /pattern/flags
Constructor: new RegExp('pattern', 'flags') ### The Core Building Blocks Before we tackle the email login, we need to understand the "alphabet" of regex:
Character Classes:
- \d: Matches any digit (0-9).
- \w: Matches any alphanumeric character (letters, numbers, and underscores).
- \s: Matches whitespace (spaces, tabs).
- .: The wildcard—matches any character except a newline.
Quantifiers:
- +: Matches 1 or more of the preceding element.
- *: Matches 0 or more.
- {n,m}: Matches between n and m times.
Anchors:
- ^: Forces the match to start at the beginning of the string.
- $: Forces the match to end at the end of the string. ### Deep Dive: Validating an Email Address When we log in to a platform, the first line of defense is ensuring the input actually looks like an email. Let’s build a regex for a standard email like zone01.recode@company.co.ke. #### 1. The Local Part (zone01 .recode) We want to allow letters, numbers, dots, and underscores.
Pattern: ^[a-zA-Z0-9._%+-]+
Explanation: We start at the beginning (^) and allow a set of characters inside the square brackets. The + ensures there is at least one character. #### 2. The "@" Symbol We just need the literal character.
Pattern: @ #### 3. The Domain (company) Similar to the local part, but usually without the special symbols.
Pattern: [a-zA-Z0-9.-]+ #### 4. The TLD (.co.ke or .com) We need a literal dot, followed by letters. Since a dot . is a wildcard in regex, we must escape it with a backslash ..
Pattern: .[a-zA-Z]{2,}$
Explanation: This looks for a dot and at least two letters at the very end of the string ($). #### Putting it all together:

const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;

const testEmail = "dev_user123@zone01.edu";
console.log(emailRegex.test(testEmail)); // Output: true

Common Use Cases in Web Apps

Beyond login forms, regex is used everywhere in full-stack development:

Password Strength: Checking for at least one capital letter, one number, and one special character.
URL Parsing: Extracting slugs or IDs from a browser's address bar.
Data Scrubbing: Removing formatting from phone numbers (e.g., changing +254 712-345-678 to 254712345678).
Search and Replace: Swapping specific words across a whole document using the global /g flag. ### Helpful Methods in JavaScript To use your patterns, you’ll mostly use these two methods:
regex.test(string): Returns true or false. Perfect for form validation.
string.match(regex): Returns an array of matches. Great for extracting information from a large block of text. > Pro Tip: Use tools like RegEx101 to test your patterns in real-time before putting them into your code. It provides a "flavor" setting—make sure to select ECMAScript (JavaScript). > ### Conclusion Regex might feel like a steep climb, but it is a "learn once, use everywhere" skill. Whether you are working on a Go backend or a JavaScript frontend, the logic remains largely the same. Keep practicing by trying to validate other common inputs like phone numbers or postal codes!

Docker Unlocked: What I Wish I Knew earlier.

Juma Evans — Wed, 18 Feb 2026 20:20:02 +0000

When I first heard about Docker, I thought it was something extremely complex that only senior developers used.

Until recently, that is. When I finally started learning Docker, I found out how amazing it is, and I want to share what I've learned.
If you're just starting out, this is for you.

So…
1. What Is Docker?
Docker is a tool that lets you package your application with everything it needs to run:-dependencies, libraries, system tools, and your code;into something called a container.
2. What Problem Does Docker Solve?
Think of it like this:
"It works on my machine" stops being an excuse.
With Docker, if it works inside the container, it works everywhere.
Before Docker, this is what used to happen:
Developer X runs the application successfully.
Developer Y tries to run it, and it breaks.

Developer X tells Developer Y: “But it works on my machine!”

Why?
Different environments:

° Different operating systems
° Different versions of NODE or Go or Python
° Different installed dependencies

Docker solves this by creating a consistent environment that travels with your application.

3. What Is a Container?
A container is like a lightweight, portable box for your application.
But unlike a full virtual machine:

° It starts fast—usually in seconds
° It uses fewer resources
° It's easy to share and move around

How It Works:

You define how your application should run in a file called a Dockerfile (a blueprint for your environment).
Docker uses that file to build an image (a snapshot of your app and everything it needs).
Then that image runs as a container (the live, running version of your application).

When I first installed Docker, created my Dockerfile, built an image, and it actually worked…
I felt like I unlocked a new level in development 😂.
That was the moment I realized:
This is how real-world applications are deployed.

Why Every Beginner Should Learn Docker
Here is why I believe Docker is worth learning early:

It Makes You Think Like a Backend Engineer You begin to understand: ° Ports and how applications communicate ° Services and how they connect ° Environment configurations ° How production setups differ from local development
It Improves Your Project Structure You naturally start organizing your apps better when you know they'll run in containers.

🛠 Things That Confused Me at First
To be honest:
° Images vs. Containers: I couldn't keep them straight. (Think of an image as a recipe and a container as the actual cooked meal.)
° Dockerfile syntax: It looked scary at first glance.
° Ports: Mapping ports from the container to my computer didn't make sense initially.

But after building just one simple container for a Go app, everything started connecting.

What Next?
Now that I understand the basics, I plan to:

° Containerize my Go projects
° Learn Docker Compose (for running multiple containers)
° Understand how containers are used in production

One step at a time.

Summary
Imagine you bake a cake 🍰 at home.
You pack:
°The cake
°The ingredients list
°The exact oven settings
°The instructions

Then you put everything inside one box.
Now, no matter where that box goes, Nairobi, Kisumu, or New York, anyone can open it and get the exact same cake.
That is exactly what Docker does.

It puts:
. Your app
. The tools it needs
. The correct settings
Inside one “box” called a container.
So instead of saying:
“It works on my machine.”
You can confidently say:
“It works everywhere.”