DEV Community: Tahsin Abrar

Mid-Year Backend Reset: My H2 Goals for Speed, Security, and Better Docs

Tahsin Abrar — Fri, 03 Jul 2026 20:47:52 +0000

July always feels like a natural pause point.

The first half of the year is already behind us. Some features shipped. Some bugs were fixed. Some ideas worked well. A few things probably stayed in the backlog longer than expected.

For me, this is not about making a huge roadmap or setting unrealistic goals. It is more about asking a simple question:

What backend systems do I want to make better before the year ends?

After thinking about my recent work, I found myself coming back to three areas:

Performance
Security
Documentation

These are not flashy goals. They are not always visible to users. But they are the kind of improvements that make a backend codebase healthier, safer, and easier to work with over time.

Why I Like Doing a Mid-Year Engineering Reset

At the start of the year, goals often feel exciting. We plan new projects, new features, new tools, and new habits.

But by the middle of the year, reality has already happened.

Urgent fixes appear. Product priorities change. Some technical debt gets ignored because there is always something more important to ship.

That is why I like the idea of an H2 engineering reset.

It gives me a chance to review the systems I work on with a fresh mind. Instead of only asking, “What should we build next?” I can also ask:

What is slowing us down?
What keeps breaking?
What is hard to understand?
What would make the next six months easier?

This kind of reset is useful because backend quality is not built in one big moment. It is built through small, careful improvements repeated over time.

Goal 1: Improve Performance

Performance is one of those things that is easy to ignore until users start feeling the pain.

A page loads a little slower. An API takes a few extra seconds. A database query works fine with 100 records but becomes painful with 100,000 records.

At first, these issues may not look urgent. But slowly, they make the product feel heavy.

For the second half of the year, I want to be more intentional about backend performance.

Where I Want to Focus

For Laravel projects, this means looking closely at a few common areas:

Slow database queries
Missing indexes
N+1 query problems
Heavy API responses
Unnecessary background jobs
Cacheable data that is being fetched again and again

A simple example is a dashboard page.

Maybe the dashboard shows user stats, recent orders, payment data, and notifications. At first, everything works fine. But after a few months, the page starts taking longer to load.

The problem may not be the whole system. It may be one query that loads too much data, or one relationship that is not eager loaded properly.

Small fixes can make a big difference.

Practical Steps I Want to Take

My performance reset will be simple:

First, I want to identify the slowest endpoints. I do not want to guess. I want to measure.

Then, I want to review the database queries behind those endpoints. Are they doing too much? Are they using indexes properly? Are they loading relationships in a clean way?

Finally, I want to use caching where it actually makes sense.

Not everything needs to be cached. But data that does not change often should not be rebuilt on every request.

The goal is not to make everything perfect. The goal is to make the most used parts of the system faster and more reliable.

Goal 2: Strengthen Security

Security is not a one-time task.

It is not something we finish after adding authentication or installing a package. It needs regular review, especially as an application grows.

New routes are added. New permissions are created. New integrations are connected. Over time, small gaps can appear.

That is why security is my second H2 backend goal.

The Areas I Want to Recheck

In Laravel apps, I want to review things like:

Authentication flow
Authorization rules
Role and permission checks
API token usage
Form request validation
File upload handling
Sensitive data exposure
Environment configuration

One real-life situation many developers face is permission logic becoming scattered.

For example, one controller checks if a user is an admin. Another checks if the user owns the resource. Another uses a policy. Another has the logic written directly inside the method.

Everything may work, but it becomes harder to trust.

When permission logic is not consistent, future changes become risky.

Practical Steps I Want to Take

For the second half of the year, I want to clean up authorization logic and move more checks into proper Laravel policies or gates where possible.

I also want to review validation rules more carefully.

Good validation is not only about showing nice error messages. It protects the system from bad data, unexpected input, and edge cases.

Another important step is checking what data gets returned from APIs.

Sometimes an API response includes more fields than the frontend actually needs. That can accidentally expose internal or sensitive information.

So the security goal is simple:

Make access clear, input strict, and output intentional.

That one sentence is easy to remember, and it covers a lot.

Goal 3: Improve Documentation

Documentation is usually the easiest thing to delay.

When we are busy, we tell ourselves, “I will document this later.”

But later often becomes never.

Then after a few months, someone asks:

“How does this job work?”
“Why does this API behave this way?”
“What happens when this webhook fails?”
“Where is this config coming from?”

And suddenly, the missing documentation becomes expensive.

For H2, I want to treat documentation as part of the backend system, not as an extra task.

What I Want to Document Better

I do not want to write huge documents that nobody reads. I want useful documentation that helps developers move faster.

That includes:

API behavior
Important business rules
Queue jobs
Scheduled commands
Webhook flows
Environment variables
Setup steps
Common debugging notes

For example, if a payment webhook updates an order status, that flow should be easy to understand.

A developer should be able to read a short note and know:

Which event comes from the payment provider
Which route receives it
Which job processes it
Which tables are updated
What happens if the webhook fails

This does not need a 20-page document. A clear Markdown file can be enough.

Practical Steps I Want to Take

My documentation reset will start with the most confusing parts of the system.

I want to document the areas where I have previously had to explain the same thing more than once. That is usually a good sign that documentation is missing.

I also want to keep docs close to the code when possible.

For example:

API notes inside an /docs folder
Setup instructions in README.md
Complex service explanations near the related module
Short comments only where the code needs context

Good documentation does not explain every line of code. It explains the decisions, flows, and important details that are not obvious.

Keeping the Reset Realistic

The biggest mistake with planning is trying to fix everything at once.

That usually leads to frustration.

So I want to keep this H2 reset small and realistic.

Instead of saying, “Improve the whole backend,” I can say:

Optimize the top 3 slowest endpoints
Review authorization for the most sensitive modules
Document the 5 most confusing backend flows

That feels much more doable.

It also creates visible progress.

A backend system improves when we choose specific problems and solve them carefully.

Redis on Windows with Laragon and Laravel: The PATH Issue That Looks Like a Redis Issue

Tahsin Abrar — Fri, 26 Jun 2026 13:19:09 +0000

A few days ago, I was working on a Laravel project on Windows. The project needed Redis for cache and queue handling, and since I was using Laragon, I thought the setup would be simple.

Laragon already had Redis inside its bin folder. I started Redis, opened the terminal, and ran:

redis-cli ping

It returned:

PONG

Perfect.

Then I moved to my Laravel project folder, opened Git Bash, and tried the same command again.

redis-cli ping

This time, I got:

bash: redis-cli: command not found

At first, it looked like Redis was not installed properly. Then I wondered if Redis only worked inside Laragon’s www folder. Maybe my Laravel project was outside the correct directory?

But the real problem was much simpler.

It was not a Redis problem.

It was not a Laravel problem.

It was not a project folder problem.

It was a PATH problem.

In this post, I’ll walk through the full Redis setup on Windows using Laragon, how to make redis-cli work from Git Bash, and how to connect it properly with a Laravel project.

The Real Situation

My Laravel project was not inside Laragon’s default www folder. It was somewhere like this:

C:\Users\Asus\Downloads\aromablendbd

But Laragon was installed here:

D:\C-data\laragon

When I opened Laragon’s own terminal or Cmder, this worked:

redis-cli ping

Output:

PONG

But inside Git Bash from my Laravel project folder, the same command failed:

bash: redis-cli: command not found

This is where the confusion started.

Redis itself does not care where your Laravel project is located. Redis runs as a server, usually on:

127.0.0.1:6379

So any project can connect to it, whether the project is inside www, Downloads, Desktop, or another drive.

The only issue was that Git Bash did not know where redis-cli.exe was located.

Laragon’s terminal automatically adds Laragon tools to its PATH. Git Bash does not.

Step 1: Find the Redis CLI File

First, we need to find the actual redis-cli.exe file inside Laragon.

In Git Bash, run:

find /d/C-data/laragon/bin -iname "redis-cli.exe"

Your Laragon path may be different. For example, if Laragon is installed in C:\laragon, you may need:

find /c/laragon/bin -iname "redis-cli.exe"

In my case, the result was:

/d/C-data/laragon/bin/redis/redis-x64-5.0.14.1/redis-cli.exe

This confirmed that Redis CLI was already installed. Git Bash simply could not find it globally.

Step 2: Test Redis Using the Full Path

Before changing PATH settings, it’s always good to test the command directly.

I ran:

/d/C-data/laragon/bin/redis/redis-x64-5.0.14.1/redis-cli.exe ping

And the output was:

PONG

That was the important moment.

It confirmed three things:

Redis was installed.

Redis server was running.

Git Bash could reach Redis when I used the full path.

So the server was fine. The port was fine. The Laravel folder location was fine.

Only the command shortcut was missing.

Step 3: Add Redis CLI to Git Bash PATH

To make redis-cli available from any folder in Git Bash, I added the Redis folder to ~/.bashrc.

Here is the command I used:

echo 'export PATH="$PATH:/d/C-data/laragon/bin/redis/redis-x64-5.0.14.1"' >> ~/.bashrc
source ~/.bashrc

After that, I tested again:

redis-cli ping

This time, it worked:

PONG

Now I could run redis-cli from any folder, including my Laravel project folder.

This is the clean fix for the redis-cli: command not found issue in Git Bash.

A Small Redis CLI Mistake That Can Confuse You

At one point, I entered the Redis shell by running:

redis-cli

Then the terminal changed to something like this:

127.0.0.1:6379>

Inside this prompt, I tried:

redis-cli ping

That was wrong.

When you are inside the Redis shell, you should only write Redis commands.

Correct:

ping

Output:

PONG

Wrong:

redis-cli ping

Why?

Because redis-cli is a terminal command. It starts the Redis command-line tool.

But once you are already inside Redis CLI, you only need to type Redis commands like:

ping
set name laragon
get name
exit

So there are two valid ways to test Redis.

From the normal terminal:

redis-cli ping

Or from inside the Redis shell:

redis-cli

Then:

ping

Both are correct, but they are used in different places.

Step 4: Make Sure Redis Server Is Running

If you installed the full version of Laragon, Redis is usually included inside the Laragon bin directory.

A common Redis path looks like this:

C:\laragon\bin\redis\redis-x64-3.2.100

Or in my case:

D:\C-data\laragon\bin\redis\redis-x64-5.0.14.1

You can start Redis by running:

redis-server.exe

Or from Git Bash, using the full path:

/d/C-data/laragon/bin/redis/redis-x64-5.0.14.1/redis-server.exe

Once the Redis server is running, keep that terminal open.

To stop the server later, press:

Ctrl + C

Laragon may also let you manage Redis from its menu depending on your installation.

One important note: Redis native Windows support is limited, and many Windows setups use older Redis builds. For the latest Redis versions, Docker, WSL, or Laradock can be a better option. But for local Laravel development, Laragon’s Redis works well enough in many cases.

Step 5: Configure Laravel `.env`

After Redis worked in the terminal, the next step was Laravel.

In the Laravel project, I opened the .env file and checked the Redis settings.

For my setup, I used:

REDIS_CLIENT=predis
REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379

If you want to use Redis for cache, also check your cache setting.

For newer Laravel versions:

CACHE_STORE=redis

For older Laravel versions:

CACHE_DRIVER=redis

The key point is this:

Laravel does not need the redis-cli command to connect to Redis.

Laravel connects to Redis through PHP using the host and port:

127.0.0.1:6379

So even if redis-cli was not available in Git Bash, Laravel could still connect if the Redis client package or PHP extension was correctly installed.

Step 6: Install Laravel Dependencies

If this is an existing Laravel project, run:

composer install

This installs the dependencies listed in composer.json.

In my case, Laravel was configured to use Predis:

REDIS_CLIENT=predis

But when I tested Redis in Laravel, I got this error:

Class "Predis\Client" not found

That means Laravel wanted to use Predis, but the package was not installed.

The fix was simple:

composer require predis/predis

After installing Predis, I cleared Laravel’s cached config:

php artisan config:clear
php artisan cache:clear
php artisan optimize:clear

This step is important because Laravel may keep old .env or config values in cache.

Predis vs PhpRedis

Laravel can use Redis in two common ways.

The first option is Predis.

REDIS_CLIENT=predis

For this, install the Composer package:

composer require predis/predis

This is often the easiest option when you are working on Windows and want a quick local setup.

The second option is PhpRedis.

REDIS_CLIENT=phpredis

For this, you need the PHP Redis extension enabled.

In Laragon, the Redis PHP extension does not always come enabled by default. You may need to download the correct php_redis.dll file that matches your PHP version, architecture, and thread-safety build.

You can check your PHP version from Laragon. Then download the matching Redis extension DLL from PECL:

https://pecl.php.net/package/redis

After downloading, copy:

php_redis.dll

Into your PHP extension folder, for example:

C:\laragon\bin\php\php-8.x.x\ext

Then add this line to your php.ini file:

extension=php_redis.dll

Restart Laragon after making the change.

For many local projects, Predis is simpler. For better performance in some production setups, PhpRedis is commonly used.

Step 7: Test Redis from Laravel Tinker

Now came the final test.

From the Laravel project folder, I ran:

php artisan optimize:clear
php artisan tinker

Inside Tinker, I first tried:

Redis::connection()->ping();

But I got:

Class "Redis" not found

This does not always mean Redis is broken. It can simply mean the Redis facade was not imported in Tinker.

The safer way is to use the full namespace:

\Illuminate\Support\Facades\Redis::connection()->ping();

Or use Laravel’s service container:

app('redis')->connection()->ping();

Expected output:

"PONG"

When I saw "PONG" from Laravel Tinker, the setup was finally complete.

At that point, Redis was working in three places:

From Laragon terminal.

From Git Bash.

From Laravel itself.

Common Errors and What They Really Mean

`bash: redis-cli: command not found`

This means your terminal cannot find redis-cli.exe.

It does not mean Redis is not installed.

Fix it by adding the Redis folder to Git Bash PATH:

echo 'export PATH="$PATH:/d/C-data/laragon/bin/redis/redis-x64-5.0.14.1"' >> ~/.bashrc
source ~/.bashrc

Then test:

redis-cli ping

`Class "Predis\Client" not found`

This means Laravel is using Predis, but the package is missing.

Fix:

composer require predis/predis
php artisan optimize:clear

`Class "Redis" not found`

This may happen in Tinker when the Redis facade is not imported.

Use the full namespace:

\Illuminate\Support\Facades\Redis::connection()->ping();

Or:

app('redis')->connection()->ping();

Redis Works in `www` but Not in Another Folder

This is usually not a folder issue.

Laragon terminal automatically sets PATH for Laragon tools. Git Bash does not.

Redis runs on:

127.0.0.1:6379

So your Laravel project can be anywhere as long as Redis is running and Laravel is configured correctly.

Final Working Setup

Here is the final setup that worked for me.

Redis CLI path:

/d/C-data/laragon/bin/redis/redis-x64-5.0.14.1/redis-cli.exe

Git Bash PATH fix:

echo 'export PATH="$PATH:/d/C-data/laragon/bin/redis/redis-x64-5.0.14.1"' >> ~/.bashrc
source ~/.bashrc

Redis terminal test:

redis-cli ping

Expected:

PONG

Laravel .env:

REDIS_CLIENT=predis
REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379
CACHE_STORE=redis

Install Predis:

composer require predis/predis

Clear Laravel config:

php artisan config:clear
php artisan cache:clear
php artisan optimize:clear

Test in Tinker:

php artisan tinker

Then:

\Illuminate\Support\Facades\Redis::connection()->ping();

Expected:

"PONG"

How to Create a GitHub Pull Request from the Terminal

Tahsin Abrar — Tue, 23 Jun 2026 09:04:54 +0000

Pull Requests are a normal part of working with GitHub. You write code in a branch, push it to GitHub, then open a Pull Request so your team can review and merge it.

Most developers create Pull Requests from the GitHub website. That works fine.

But once you get comfortable with the terminal, you can do the whole flow without leaving your editor or command line.

In this post, we will go through a simple and practical workflow:

update your local main branch
create a new feature branch
commit your changes
push the branch to GitHub
create a Pull Request from the terminal using GitHub CLI

Let’s use a real example: you are building a login page.

First, Know the Difference: `git pull` vs Pull Request

A lot of beginners get confused here.

git pull and Pull Request are not the same thing.

`git pull`

git pull means you are taking the latest code from GitHub and bringing it into your local project.

Example:

git pull origin main

This updates your local branch with the latest code from the remote main branch.

Pull Request

A Pull Request means you are asking to merge your branch changes into another branch, usually main or develop.

So the simple idea is:

git pull  = bring latest code to your computer
Pull Request = ask to merge your code into main

To create a Pull Request from the terminal, the usual flow is:

push your branch → create PR with GitHub CLI

Step 1: Update Your Main Branch

Before starting new work, always get the latest code from the main branch.

git checkout main
git pull origin main

This helps you avoid working on old code.

Think of it like this: before building your new feature, you are making sure your project is fresh and up to date.

Step 2: Create a New Branch

Now create a new branch for your work.

git checkout -b feature/login-page

Here, feature/login-page is your working branch.

Good branch names are short, clear, and meaningful.

Examples:

feature/navbar
fix/login-error
update/readme
feature/login-page

A clear branch name helps your teammates understand what you are working on before they even open the code.

Step 3: Make Your Code Changes

Now do your actual work.

For example, you may add:

a login page layout
email and password fields
a submit button
basic styling

After changing the code, check the current Git status:

git status

This shows which files were changed, added, or deleted.

Step 4: Add Your Files

To add all changed files:

git add .

The . means Git will add all changed files in the current project.

If you only want to add one file, use the file path:

git add src/App.jsx

This is useful when you changed many files but only want to commit some of them.

Step 5: Commit Your Changes

Now create a commit:

git commit -m "Add login page UI"

A good commit message should be short but clear.

Good examples:

git commit -m "Fix navbar responsiveness"
git commit -m "Update README installation steps"
git commit -m "Add user login form"

Avoid unclear messages like:

git commit -m "changes"
git commit -m "update"
git commit -m "fix"

Your future self and your teammates will thank you for writing clear commit messages.

Step 6: Push Your Branch to GitHub

Now push your branch to GitHub:

git push -u origin feature/login-page

You can also push the current branch like this:

git push -u origin HEAD

This is very handy because you do not need to type the full branch name.

After this, your local branch exists on GitHub too.

Step 7: Install GitHub CLI

To create a Pull Request from the terminal, you need GitHub CLI.

GitHub CLI gives you the gh command.

On Windows

Open PowerShell or Windows Terminal and run:

winget install --id GitHub.cli --source winget

After installing, close the terminal and open a new one.

Then check:

gh --version

On macOS

If you use Homebrew, run:

brew install gh

Then check:

gh --version

If you see the version number, GitHub CLI is installed correctly.

Step 8: Login to GitHub CLI

You only need to do this once:

gh auth login

You will see some options. In most cases, choose:

GitHub.com
HTTPS
Yes
Login with a web browser

A browser window may open for login and authorization.

After login, check if everything is working:

gh auth status

Once you are logged in, you can create Pull Requests from the terminal without opening the GitHub website.

Step 9: Create a Pull Request from the Terminal

The easiest way is interactive mode:

gh pr create

GitHub CLI will ask you questions like:

Title:
Body:
Base branch:

The base branch is usually:

main

Or, if your team uses develop, then use:

develop

After you answer the questions, GitHub CLI creates the Pull Request and shows you the PR URL.

Create a Pull Request in One Command

You can also create the Pull Request in one line.

gh pr create --base main --head feature/login-page --title "Add login page UI" --body "This PR adds the login page UI with form fields and basic styling."

Let’s understand this command:

--base main

This is the branch where you want to merge your code.

--head feature/login-page

This is your feature branch.

--title

This is the Pull Request title.

--body

This is the Pull Request description.

If you are already inside the feature branch, you can skip --head:

gh pr create --base main --title "Add login page UI" --body "This PR adds the login page UI with form fields and basic styling."

What Should You Write in a Pull Request?

A good Pull Request should explain two things:

What changed?
How did you test it?

Here is a simple example.

PR Title

Add login page UI

PR Body

## Summary
- Added login page layout
- Added email and password input fields
- Added submit button styling

## Testing
- Ran the app locally
- Checked the login page in browser

This is clear, professional, and easy to review.

Your reviewer does not need to guess what you did.

Best Way to Write a Multiline PR Body

Sometimes you want a clean Pull Request body with headings and bullet points.

You may try to paste multiline Markdown directly inside --body, but different shells can behave differently.

The safest and cleanest way is to use a body file.

Create a file named:

pr-body.md

Put it in your project root directory:

my-project/
├── src/
├── public/
├── package.json
├── README.md
└── pr-body.md

Inside pr-body.md, write:

## Summary
- Added login page layout
- Added email and password fields
- Added submit button styling

## Testing
- Ran the app locally
- Checked login page in browser

Then create the Pull Request:

gh pr create --base main --head feature/login-page --title "Add login page UI" --body-file pr-body.md

This is usually the best option for real projects.

It keeps your command clean and your PR description easy to edit.

After creating the Pull Request, you can delete pr-body.md if you do not want to keep it in the project.

One-Line Multiline Body Without a File

If you really want to write the body directly in the command, here are safe options.

Bash, Git Bash, or macOS Terminal

gh pr create --base main --head feature/login-page --title "Add login page UI" --body $'## Summary\n- Added login page layout\n- Added email and password fields\n\n## Testing\n- Ran the app locally\n- Checked login page in browser'

Here, \n means a new line.

Windows PowerShell

gh pr create --base main --head feature/login-page --title "Add login page UI" --body "## Summary`n- Added login page layout`n- Added email and password fields`n`n## Testing`n- Ran the app locally`n- Checked login page in browser"

In PowerShell, newline is written as:

`n

Still, for most real work, I recommend using --body-file.

It is simpler and less error-prone.

Check Your Pull Request

After creating the Pull Request, you can check its status:

gh pr status

To see Pull Requests in the repository:

gh pr list

To view the current branch’s Pull Request:

gh pr view

To open it in the browser:

gh pr view --web

Opening the browser is optional. You do not need it to create the PR.

The Full Practical Workflow

Here is the complete flow you can use every day:

git checkout main
git pull origin main

git checkout -b feature/my-work

# after code changes
git status
git add .
git commit -m "Add my work"
git push -u origin HEAD

gh pr create --base main --title "Add my work" --body "Added my work and tested locally."

For a cleaner Pull Request body:

gh pr create --base main --title "Add my work" --body-file pr-body.md

That is the core workflow.

Common Problems and Fixes

Problem 1: `gh: command not found`

This means GitHub CLI is not installed, or your terminal has not refreshed yet.

On Windows:

winget install --id GitHub.cli --source winget

Then close the terminal and open it again.

On macOS:

brew install gh

Then check:

gh --version

Problem 2: You Are Not Logged In

If you see a message saying you are not logged in, run:

gh auth login

Then check:

gh auth status

Problem 3: Current Branch Is Not Pushed

If GitHub CLI says your branch is not pushed yet, run:

git push -u origin HEAD

Then try again:

gh pr create

Problem 4: Pull Request Is Created from the Wrong Branch

First, check your current branch:

git branch --show-current

If you are on the wrong branch, switch to the correct one:

git checkout feature/login-page

Then create the Pull Request:

gh pr create --base main

Stop Guessing in Controllers: Debug MySQL Directly

Tahsin Abrar — Wed, 20 May 2026 21:33:32 +0000

Every backend developer has done this at some point.

A request fails.

Something is not inserting into the database.

And suddenly the codebase turns into this:

dd($request->all());

dd($user);

dd($campaign);

Log::info($query);

You add logs in controllers.

Then services.

Then repositories.

Then queue workers.

Then event listeners.

And after two hours, you are still confused.

Because the real problem is not where you are looking.

The Day I Realized Controller Debugging Wasn’t Enough

A few months ago, a developer on a team I worked with faced a strange issue.

A simple form submission was supposed to:

create a user
assign a campaign
generate a lead
push a welcome email into queue
write an activity log

Pretty normal workflow.

But randomly, some users were being created without campaign data.

Sometimes the queue job worked.

Sometimes it didn’t.

Sometimes the transaction rolled back silently.

The first reaction?

Start adding logs everywhere.

Inside controllers:

Log::info('Controller hit');

Inside services:

Log::info('Campaign assigned');

Inside queue workers:

Log::info('Email queued');

Inside transactions:

DB::beginTransaction();

The code became a forest of debugging statements.

Still no clear answer.

The Real Problem

Here’s what most developers forget:

No matter how beautiful your architecture is…

No matter whether you use:

Laravel
Raw PHP
Node.js
Python
Java

At the end of the day, every query goes to one place:

MySQL.

Always.

Your application is just the messenger.

The database sees everything.

That realization changes how you debug systems.

Instead of Guessing, Watch the Database Directly

The moment we enabled MySQL General Query Log, everything became obvious.

We literally watched the queries execute live.

One terminal command showed the full story.

SET GLOBAL general_log = 'ON';

Then:

tail -f /var/lib/mysql/hostname.log

And suddenly we could see:

INSERT INTO users ...

UPDATE campaigns ...

ROLLBACK;

That last line explained everything.

The transaction was rolling back because another process locked a table for a few seconds.

No controller log would have shown the full picture that clearly.

This Is Why Framework-Level Debugging Often Fails

Modern applications are no longer simple.

A single request may involve:

queues
events
transactions
scheduled jobs
caching
background workers
third-party APIs

By the time you debug from inside the controller, the actual issue may already be happening somewhere else entirely.

This is why developers sometimes spend hours debugging “application logic” when the real problem is:

a deadlock
a lock wait
a slow query
missing index
rollback
transaction conflict

And MySQL already knows all of this.

The Most Useful MySQL Debugging Tools

Honestly, there are four MySQL features every backend developer should know.

Not just DBAs.

Actual application developers.

Because these tools solve real-world production headaches.

1. General Query Log

See everything.

This is the closest thing to “watching the database think.”

Enable it:

SET GLOBAL general_log = 'ON';

Now every query gets logged.

You can literally submit a form and watch the database flow in real time.

This becomes incredibly useful when:

one request touches multiple tables
transactions fail
duplicate queries happen
hidden queries execute behind ORM magic

Especially in large Laravel applications where Eloquent sometimes hides too much.

2. Slow Query Log

Find hidden performance problems.

This one saves applications.

Seriously.

Sometimes developers optimize controllers endlessly while the real problem is one terrible query.

Enable it:

SET GLOBAL slow_query_log = 'ON';

SET GLOBAL long_query_time = 1;

Now MySQL logs anything slower than one second.

This helps identify:

missing indexes
N+1 problems
huge scans
inefficient joins

I once saw a dashboard drop from 12 seconds to under 800ms just because a slow query log exposed a missing index.

The application code itself was completely fine.

3. InnoDB Status

Understand deadlocks & locks.

This command feels like magic the first time you use it.

SHOW ENGINE INNODB STATUS;

If your application ever experiences:

hanging requests
frozen queues
stuck inserts
transaction conflicts

This command can immediately reveal:

LATEST DETECTED DEADLOCK

or:

LOCK WAIT

And suddenly the mystery disappears.

4. General Log Table Audit

This is where debugging becomes much more practical.

Most developers enable General Query Log and only think about the log file.

But MySQL can also write general logs into a table:

mysql.general_log

That means you can inspect logs using normal SQL.

You can filter by:

latest queries
specific table name
specific command type
specific MySQL thread ID
insert/update/delete queries
commit or rollback queries
transaction flow

This is much better than randomly placing Log::info() everywhere.

Prerequisite: Make Sure General Log Writes to Table

Before querying mysql.general_log, check where MySQL is writing logs.

SHOW VARIABLES LIKE 'log_output';
SHOW VARIABLES LIKE 'general_log';

If log_output is only FILE, logs will go to a file.

If you want to query logs from a table, enable table output:

SET GLOBAL log_output = 'TABLE';
SET GLOBAL general_log = 'ON';

If you want both file and table logging:

SET GLOBAL log_output = 'TABLE,FILE';
SET GLOBAL general_log = 'ON';

Now MySQL will write General Query Log entries into:

mysql.general_log

Important note:

You need enough MySQL permission to run SET GLOBAL and read from mysql.general_log.

This is usually something you do in a local, staging, or temporary production debugging session with proper access.

View Latest Queries from General Log Table

Once General Query Log is enabled with table output, you can inspect the latest queries like this:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
ORDER BY event_time DESC
LIMIT 100;

This gives you the real database activity.

Not what you think Laravel executed.

Not what your controller expected.

Not what your service class assumed.

What MySQL actually received.

Filter Only Actual SQL Queries

The general log contains different command types.

For example:

Connect
Query
Prepare
Execute
Quit

Most of the time, you only care about actual SQL statements.

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE command_type = 'Query'
ORDER BY event_time DESC
LIMIT 100;

This removes connection noise and focuses on real queries.

Find Queries for a Specific Table

Suppose your issue is related to the users table.

You can filter only queries that touched users:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE argument LIKE '%users%'
ORDER BY event_time DESC
LIMIT 100;

For campaign-related debugging:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE argument LIKE '%campaigns%'
ORDER BY event_time DESC
LIMIT 100;

This is extremely useful when one request touches multiple tables.

For example, one form submission may touch:

users
campaigns
leads
jobs
activity_logs

Instead of checking five different PHP files, you can ask MySQL directly:

“What happened to this table?”

Check Only INSERT Queries

If your form submission is supposed to create a user, check whether the INSERT query actually reached MySQL.

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE command_type = 'Query'
  AND argument LIKE 'INSERT%'
ORDER BY event_time DESC
LIMIT 100;

Specific table:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE command_type = 'Query'
  AND argument LIKE 'INSERT%'
  AND argument LIKE '%users%'
ORDER BY event_time DESC
LIMIT 100;

Now you can answer important questions:

Did the insert query happen?

Did it happen once?

Did it happen multiple times?

Did it happen before rollback?

Did another process insert something unexpectedly?

That is the kind of answer controller logs often fail to provide.

Check UPDATE and DELETE Queries

For update issues:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE command_type = 'Query'
  AND argument LIKE 'UPDATE%'
ORDER BY event_time DESC
LIMIT 100;

For delete issues:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE command_type = 'Query'
  AND argument LIKE 'DELETE%'
ORDER BY event_time DESC
LIMIT 100;

For a specific table update:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE command_type = 'Query'
  AND argument LIKE 'UPDATE%'
  AND argument LIKE '%campaigns%'
ORDER BY event_time DESC
LIMIT 100;

This helps you catch accidental updates or deletes triggered by:

model observers
queue jobs
event listeners
cron jobs
scheduled commands
background workers

Check COMMIT and ROLLBACK

This is one of the most important parts.

Sometimes the query runs successfully.

But the transaction rolls back later.

To check transaction result:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE LOWER(argument) IN ('commit', 'rollback')
ORDER BY event_time DESC
LIMIT 100;

If you see:

ROLLBACK

after your insert or update queries, then your problem is not the insert query itself.

Your problem is somewhere inside the transaction.

Maybe an exception happened.

Maybe a lock wait happened.

Maybe another process created a conflict.

Maybe a queue or event triggered something unexpected.

This is exactly why debugging only from the controller is not enough.

Trace One Request Using Thread ID

This is where things become really powerful.

Every MySQL connection has a thread_id.

If you find one suspicious query, copy its thread_id.

Then filter the full flow for that connection:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE thread_id = 12345
ORDER BY event_time ASC;

Now you can see the query sequence in order.

Example output may look like this:

START TRANSACTION;

INSERT INTO users ...

UPDATE campaigns ...

INSERT INTO leads ...

ROLLBACK;

That tells the real story.

Not guesswork.

Not random logs.

The actual database flow.

Trace Transaction Start, Commit, and Rollback

If you only want transaction-related statements:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE LOWER(argument) LIKE 'start transaction%'
   OR LOWER(argument) = 'begin'
   OR LOWER(argument) = 'commit'
   OR LOWER(argument) = 'rollback'
ORDER BY event_time DESC
LIMIT 100;

For a specific thread:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE thread_id = 12345
  AND (
        LOWER(argument) LIKE 'start transaction%'
        OR LOWER(argument) = 'begin'
        OR LOWER(argument) = 'commit'
        OR LOWER(argument) = 'rollback'
      )
ORDER BY event_time ASC;

This is very useful when a form submission works sometimes and fails randomly.

Because now you can see:

when the transaction started
which queries happened inside it
whether it committed
whether it rolled back

Can We Filter POST Requests from MySQL?

Not directly.

MySQL does not know whether the original HTTP request was:

GET
POST
PUT
PATCH
DELETE

MySQL only sees SQL.

So from the database side, you usually filter write operations:

INSERT
UPDATE
DELETE
COMMIT
ROLLBACK

For example, a POST request that creates a user usually results in:

INSERT INTO users ...

A PATCH request may result in:

UPDATE users ...

A delete action may result in:

DELETE FROM users ...

So instead of searching for “POST” inside MySQL, search for the SQL operation caused by that POST request.

Application-Level Request Tracking Example

If you want to connect application request logs with MySQL logs, add a request ID at application level.

Laravel example:

use Illuminate\Support\Str;
use Illuminate\Support\Facades\Log;

$requestId = request()->header('X-Request-Id') ?? (string) Str::uuid();

Log::withContext([
    'request_id' => $requestId,
    'method' => request()->method(),
    'path' => request()->path(),
]);

Log::info('Request started');

Now your Laravel logs can tell you:

request_id: 7e71e1d8-3d9b-45e5-8a80-ef98c0d9c101
method: POST
path: /users

Then you can add a temporary MySQL session marker:

DB::statement("SET @debug_request_id = ?", [$requestId]);

This statement will also appear inside the General Query Log.

Now search for that marker:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE argument LIKE '%debug_request_id%'
ORDER BY event_time DESC
LIMIT 20;

Once you find the thread_id, inspect all queries from that same thread:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE thread_id = 12345
ORDER BY event_time ASC;

This gives you a bridge between:

Laravel request
controller/service logs
actual MySQL queries
transaction commit/rollback result

That is much better than guessing.

Example: Debugging a Failed User Creation

Imagine this flow:

user submits form
Laravel receives POST request
application starts transaction
user is inserted
campaign is assigned
lead is generated
something fails
transaction rolls back

From application logs, you may only see:

User creation failed

But from MySQL general log, you can check:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE argument LIKE '%users%'
   OR argument LIKE '%campaigns%'
   OR argument LIKE '%leads%'
   OR LOWER(argument) IN ('commit', 'rollback')
ORDER BY event_time DESC
LIMIT 100;

Then you may discover:

INSERT INTO users ...

UPDATE campaigns ...

INSERT INTO leads ...

ROLLBACK;

Now the problem is clear.

The user insert happened.

The campaign update happened.

The lead insert happened.

But the transaction rolled back.

So the debugging direction changes immediately.

You stop asking:

“Why did user insert fail?”

And start asking:

“What caused the rollback?”

That is a huge difference.

Clean General Log Table

Do not let mysql.general_log grow forever.

After debugging, clean it.

First, disable General Query Log:

SET GLOBAL general_log = 'OFF';

Then truncate the table:

TRUNCATE TABLE mysql.general_log;

If you still need debugging, enable it again:

SET GLOBAL general_log = 'ON';

Full cleanup flow:

SET GLOBAL general_log = 'OFF';

TRUNCATE TABLE mysql.general_log;

SET GLOBAL general_log = 'ON';

Important note:

Do not use this as permanent production logging.

This is for temporary debugging.

Disable General Query Log After Debugging

This is the part developers often forget.

After investigation, turn it off:

SET GLOBAL general_log = 'OFF';

You can verify:

SHOW VARIABLES LIKE 'general_log';

If the value is OFF, logging is disabled.

One Important Thing Most Developers Ignore

Do not leave general_log permanently enabled in production.

That is a bad idea.

Because:

logs become massive
storage grows quickly
performance can suffer
sensitive query data may appear in logs
debugging tables can become noisy very fast

The smarter workflow is temporary debugging.

Temporary Debugging Workflow

Enable table logging:

SET GLOBAL log_output = 'TABLE';
SET GLOBAL general_log = 'ON';

Reproduce the issue.

Check recent queries:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
ORDER BY event_time DESC
LIMIT 100;

Filter by table:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE argument LIKE '%users%'
ORDER BY event_time DESC
LIMIT 100;

Filter by transaction result:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE LOWER(argument) IN ('commit', 'rollback')
ORDER BY event_time DESC
LIMIT 100;

Trace one thread:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE thread_id = 12345
ORDER BY event_time ASC;

Then disable logging:

SET GLOBAL general_log = 'OFF';

And clean the table:

TRUNCATE TABLE mysql.general_log;

That is the workflow.

Enable.

Reproduce.

Inspect.

Filter.

Understand.

Disable.

Clean.

That is how you stop guessing and start debugging from the place that sees everything:

Stack Pointer vs Base Pointer: A Friendly Guide to How Function Calls Work

Tahsin Abrar — Mon, 18 May 2026 11:38:49 +0000

Have you ever called a function and wondered what really happens inside the computer?

package main

import "fmt"

func add(x int, y int) int {
    result := x + y
    return result
}

func main() {
    a := 10
    sum := add(a, 4)
    fmt.Println(sum)
}

We know the output will be:

But inside the machine, a lot of quiet work happens.

The CPU needs to remember:

Where did this function start?

Where should it return?

Where are the arguments?

Where are the local variables?

Which function is currently running?

This is where the stack, stack frame, stack pointer, and base pointer come in.

Let’s break them down in a simple way.

First, What Is a Stack?

A stack is a special area of memory used while a program is running.

Think of it like a stack of plates.

You put a plate on top.

You remove the top plate first.

You cannot remove a plate from the middle without disturbing the others.

In programming, the stack works in a similar way.

When a function is called, the program creates a small memory area for that function. This small area is called a stack frame.

When the function finishes, its stack frame is removed.

So if main() calls add(), the stack may look like this:

add() stack frame
main() stack frame

add() is on top because it is currently running.

When add() finishes, its stack frame is removed, and the program returns to main().

What Is a Stack Frame?

A stack frame is the memory space a function gets while it is running.

It usually stores things like:

Function arguments
Return address
Old base pointer
Local variables
Temporary values

For our add() function:

func add(x int, y int) int {
    result := x + y
    return result
}

The stack frame may contain:

x = 10
y = 4
return address
old base pointer
result = 14

The exact layout depends on the CPU, compiler, operating system, and calling convention. But the main idea is the same:

A function needs a private workspace while it runs.

That workspace is its stack frame.

A Quick Note About Memory Addresses

Before we go deeper, let’s clear up one common confusion.

On most modern systems, memory is byte-addressable. That means every byte has its own address.

So memory addresses can look like this:

0, 1, 2, 3, 4, 5, 6, 7, 8 ...

But when we draw memory in larger chunks, like 4-byte chunks on a 32-bit-style example, we often label them like this:

0, 4, 8, 12, 16 ...

This does not mean addresses 1, 2, and 3 do not exist.

It simply means we are drawing memory in 4-byte blocks.

Address 0  -> byte 1 of first block
Address 1  -> byte 2 of first block
Address 2  -> byte 3 of first block
Address 3  -> byte 4 of first block

Address 4  -> byte 1 of second block

For this article, we will use a simple 32-bit mental model where each slot is 4 bytes.

So our stack addresses may move like this:

In many systems, the stack grows downward, which means the address gets smaller as new data is pushed onto the stack.

What Is the Stack Pointer?

The stack pointer, often called SP, points to the current top of the stack.

Imagine you are stacking plates.

The stack pointer is like your finger pointing at the top plate.

When a new value is pushed onto the stack, the stack pointer moves.

When a value is popped from the stack, the stack pointer moves back.

Before push:

Address 76 -> old value
Address 72 -> top of stack  <- SP

Push new value:

Address 76 -> old value
Address 72 -> old top
Address 68 -> new value     <- SP

Because our example stack grows downward, pushing data makes SP move from 72 to 68.

So the stack pointer is dynamic.

It keeps changing as the stack grows and shrinks.

What Is the Base Pointer?

The base pointer, often called BP or frame pointer, points to a stable location inside the current function’s stack frame.

Unlike the stack pointer, the base pointer usually stays fixed while the function is running.

Why do we need that?

Because the stack pointer keeps moving.

If the program only used SP, it would be hard to find local variables and arguments after more values are pushed or popped.

The base pointer solves this problem.

It gives the function a fixed reference point.

From that fixed point, the program can find values using offsets.

BP + 8   -> first argument
BP + 12  -> second argument
BP - 4   -> first local variable
BP - 8   -> second local variable

So the base pointer helps the program answer questions like:

Where is x?

Where is y?

Where is result?

Where should I return after this function ends?

Stack Pointer vs Base Pointer

Here is the simple difference:

Register	Meaning	Behavior
Stack Pointer	Points to the current top of the stack	Changes often
Base Pointer	Points to a fixed place in the current stack frame	Usually stays fixed during the function

A simple way to remember it:

SP tracks movement.

BP gives stability.

The stack pointer is like a moving bookmark.

The base pointer is like an anchor.

What Happens When `main()` Runs?

func main() {
    a := 10
    sum := add(a, 4)
    fmt.Println(sum)
}

When main() starts, the program creates a stack frame for main.

Inside that frame, it stores local variables such as:

a = 10
sum = ?

At first, sum does not have its final value because add(a, 4) has not returned yet.

So the stack may look like this:

main stack frame
----------------
return address
old BP
a = 10

Now main() calls add(a, 4).

That means the program needs a new stack frame for add().

What Happens When `add()` Is Called?

This line is important:

sum := add(a, 4)

The program needs to call add() with two values:

x = 10
y = 4

So it creates a new stack frame for add().

A simplified stack frame may look like this:

add stack frame
---------------
y = 4
x = 10
return address
old BP
result = 0

The order can vary depending on the system, but the idea is the same.

The add() function needs:

Its arguments: x and y

A return address: where to go back after add() finishes

The old base pointer: so the caller’s stack frame can be restored

Its local variable: result

Why Do We Need a Return Address?

When main() calls add(), the CPU jumps to the code for add().

But after add() finishes, the CPU must know where to go back.

It needs to return to this line:

sum := add(a, 4)

More specifically, it needs to return to the next step after the function call, so the returned value can be stored in sum.

That “go back here” location is called the return address.

Without a return address, the program would get lost.

It would finish add() and then have no idea where to continue.

Why Save the Old Base Pointer?

Before add() starts, main() already has its own base pointer.

When add() starts, it gets a new base pointer for its own stack frame.

But when add() finishes, the program must restore the old base pointer so main() can continue correctly.

That is why the old base pointer is saved inside the new stack frame.

Think of it like leaving a breadcrumb.

Before entering a new function, the program says:

“Let me save where I came from, so I can restore it later.”

When the function ends, the old base pointer is loaded back.

Now the caller’s stack frame becomes active again.

How `add()` Finds `x`, `y`, and `result`

Inside add(), we have this line:

result := x + y

The CPU does not understand variable names like humans do.

It does not think:

“Oh, x means 10 and y means 4.”

Instead, the compiler maps variables to memory locations.

Using the base pointer, the program can find values by offsets.

BP + 8   -> x
BP + 12  -> y
BP - 4   -> result

So when the function needs x, it looks at something like:

BP + 8

When it needs y, it looks at:

BP + 12

When it needs to store result, it may use:

BP - 4

So the line:

result := x + y

becomes something like:

read value at BP + 8
read value at BP + 12
add them
store the answer at BP - 4

x = 10
y = 4

result = 14

Returning Back to `main()`

Now add() reaches this line:

return result

The function returns 14.

Then the add() stack frame is no longer needed.

So the program removes it from the stack.

The stack pointer moves back.

The old base pointer is restored.

The return address tells the CPU where to continue.

Now we are back inside main().

The returned value 14 is stored in sum.

sum := 14

Then this line runs:

fmt.Println(sum)

And we see:

A Simple Visual Summary

Here is a simplified version of what happens.

Before calling add():

main stack frame
----------------
a = 10
sum = ?

While add() is running:

add stack frame
---------------
x = 10
y = 4
result = 14

main stack frame
----------------
a = 10
sum = ?

After add() returns:

main stack frame
----------------
a = 10
sum = 14

Then main() prints:

Does This Always Work Exactly Like This?

Not always.

This article uses a simplified model to make the concept easy to understand.

Real systems can be more complex.

Modern compilers may optimize away the base pointer.

Function arguments may be passed through registers instead of the stack.

Go uses goroutine stacks, which can grow and move.

The exact stack layout depends on architecture, compiler version, and calling convention.

But the core idea is still useful:

Functions need stack frames.

The stack pointer tracks the top of the stack.

The base pointer gives a stable reference point inside a function frame.

Return addresses help the program continue from the correct place.

Old base pointers help restore the caller’s frame.

Once you understand this model, debugging, assembly, recursion, memory layout, and low-level programming all become much less mysterious.

A Real-Life Way to Remember It

Imagine you are reading a book and solving exercises.

You are on Chapter 5.

Suddenly, Chapter 5 says:

“Before continuing, go solve Example 2 from Chapter 3.”

So you place a bookmark in Chapter 5.

Then you go to Chapter 3 and solve the example.

After finishing, you return to the bookmark in Chapter 5.

In this story:

The bookmark is like the return address.

Your current page position is like the stack pointer.

The start of your current exercise notes is like the base pointer.

The notes for each exercise are like stack frames.

Every function call is like temporarily jumping into another task, while carefully remembering how to come back.

How to Connect a Namecheap Domain to a DigitalOcean Droplet with Nginx

Tahsin Abrar — Sat, 16 May 2026 15:31:38 +0000

Buying a domain is exciting. Creating a server is exciting too.

But the moment you try to connect both of them, things can feel confusing.

You bought your domain from Namecheap. You created a VPS on DigitalOcean. Now you expect your website to open when someone visits your domain.

But unlike shared hosting or cPanel hosting, DigitalOcean does not automatically connect everything for you.

You need to set up two important things:

DNS : so your domain points to your server
Nginx : so your server knows how to serve your website

In this guide, we will walk through the full setup in a simple and beginner-friendly way.

By the end, your domain will point to your DigitalOcean Droplet, Nginx will serve your website, and HTTPS will be enabled.

The Big Picture

Before touching any settings, let’s understand the flow.

Namecheap Domain
        ↓
DNS points to DigitalOcean IP
        ↓
DigitalOcean Droplet
        ↓
Nginx Web Server
        ↓
Your Website

Your domain is like a human-friendly address.

Your DigitalOcean Droplet is the actual server.

DNS connects the domain to the server.

Nginx receives the request and serves your website files or forwards traffic to your app.

Step 1: Create a DigitalOcean Droplet

First, create a Droplet on DigitalOcean.

For a beginner project or test website, this setup is usually enough:

Ubuntu 22.04 LTS
Basic Droplet
1 GB RAM

After the Droplet is created, DigitalOcean will give you a public IP address.

It will look something like this:

159.89.xxx.xxx

Keep this IP address safe. You will need it in the next step.

This IP is where your domain will point.

Step 2: Point Your Namecheap Domain to DigitalOcean

Now go to your Namecheap account.

Open:

Domain List
→ Manage
→ Advanced DNS

There are two common ways to connect your domain.

Option A: Use A Records

This is the easiest method for beginners.

Add these DNS records:

Type	Host	Value
A Record	@	Your DigitalOcean IP
A Record	www	Your DigitalOcean IP

Example:

Type	Host	Value
A Record	@	159.89.xxx.xxx
A Record	www	159.89.xxx.xxx

You can keep TTL as the default value.

Here is what this does:

example.com       → DigitalOcean server
www.example.com   → DigitalOcean server

So both the root domain and the www version will go to the same Droplet.

For most simple projects, this is the best starting point.

Option B: Use DigitalOcean Nameservers

Another option is to manage DNS from DigitalOcean instead of Namecheap.

In DigitalOcean, go to:

Networking
→ Domains
→ Add Domain

Add your domain there.

DigitalOcean will give you nameservers like:

ns1.digitalocean.com
ns2.digitalocean.com
ns3.digitalocean.com

Then go back to Namecheap:

Domain
→ Manage
→ Nameservers
→ Custom DNS

Add those three DigitalOcean nameservers and save.

This method is useful when you want to manage all DNS records from DigitalOcean, especially if you have multiple subdomains or services.

Which DNS Method Should You Choose?

For beginners, use A Records.

It is simple, clear, and easy to debug.

Use DigitalOcean nameservers when your setup becomes larger, for example:

api.example.com
app.example.com
blog.example.com
admin.example.com

For now, we will continue with the beginner-friendly A Record method.

Step 3: Wait for DNS Propagation

DNS changes are not always instant.

Sometimes they work in a few minutes. Sometimes they take longer.

Usually, it can take:

5 minutes to 1 hour

In some cases, it may take up to:

24 hours

You can use tools like DNS Checker to see whether your domain is pointing to the correct server IP.

A common beginner mistake is changing DNS and immediately thinking something is broken. Sometimes nothing is broken. DNS just needs a little time.

Step 4: Connect to Your Server with SSH

Now connect to your DigitalOcean Droplet.

On Mac or Linux, open your terminal.

On Windows, you can use PowerShell or PuTTY.

Run:

ssh root@YOUR_SERVER_IP

Example:

ssh root@159.89.xxx.xxx

The first time you connect, your terminal may ask for confirmation. Type:

yes

Then enter your password or use your SSH key, depending on how you created the Droplet.

Step 5: Install Nginx

Once you are inside the server, update the package list:

sudo apt update

Then install Nginx:

sudo apt install nginx -y

Check if Nginx is running:

sudo systemctl status nginx

If everything is working, you should see that Nginx is active.

At this point, if you open your server IP in the browser, you may see the default Nginx welcome page.

That means your web server is working.

Step 6: Configure the Firewall

Ubuntu servers often use ufw for firewall management.

Allow Nginx traffic:

sudo ufw allow 'Nginx Full'

Also allow SSH so you do not lock yourself out:

sudo ufw allow OpenSSH

Then enable the firewall:

sudo ufw enable

You can check the firewall status with:

sudo ufw status

You should see that HTTP, HTTPS, and SSH traffic are allowed.

Step 7: Create a Website Folder

Now create a folder for your website.

sudo mkdir -p /var/www/myproject

Create a test HTML file:

sudo nano /var/www/myproject/index.html

Paste this:

<h1>Hello from DigitalOcean</h1>

Save the file:

CTRL + X
Y
Enter

This simple file will help us confirm that the domain and Nginx setup are working.

Step 8: Create an Nginx Server Block

An Nginx server block tells Nginx how to handle traffic for a specific domain.

Create a new config file:

sudo nano /etc/nginx/sites-available/myproject

Paste this configuration:

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/myproject;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Replace this:

example.com www.example.com

With your real domain.

For example:

server_name mycoolsite.com www.mycoolsite.com;

This config says:

“When someone visits this domain, serve files from /var/www/myproject.”

Step 9: Enable the Site

Nginx keeps available site configs in:

/etc/nginx/sites-available/

But it only uses configs that are linked in:

/etc/nginx/sites-enabled/

So we need to enable the site:

sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled/

Step 10: Test and Reload Nginx

Before restarting Nginx, always test the config:

sudo nginx -t

If everything is fine, you should see something like:

syntax is ok
test is successful

Now reload Nginx:

sudo systemctl reload nginx

Open your domain in the browser:

http://yourdomain.com

You should see:

Hello from DigitalOcean

Great. Your domain is now connected to your Droplet.

Step 11: Add HTTPS with Certbot

A production website should use HTTPS.

For that, we can use Certbot with Let’s Encrypt.

Install Certbot:

sudo apt install certbot python3-certbot-nginx -y

Then run:

sudo certbot --nginx

Certbot will ask you to choose the domain.

Select your domain and allow redirect to HTTPS.

After that, your site should work with:

https://yourdomain.com

Certbot also sets up automatic renewal, so your SSL certificate can renew before it expires.

Final Architecture

Your setup now looks like this:

Namecheap
   ↓
DNS A Record
   ↓
DigitalOcean Droplet IP
   ↓
Nginx
   ↓
Website Files

This is a common real-world setup used by many developers.

Why This Feels Different from cPanel Hosting

If you are coming from cPanel hosting, DigitalOcean may feel harder at first.

That is normal.

With cPanel hosting, the hosting company usually handles many things for you:

DNS
Apache or Nginx
SSL
PHP
File manager
Email tools

You often just change nameservers and upload your files.

But with a DigitalOcean VPS, you manage the server yourself.

That means you are responsible for:

Nginx
Firewall
SSL
App runtime
Deployment
Security
Logs

The benefit is flexibility.

You can run Node.js, Laravel, Docker, PostgreSQL, Redis, background workers, multiple apps, and more.

The tradeoff is that you need to understand the server setup.

A Real-Life Example

Imagine you built a small portfolio website.

You bought:

myportfolio.com

from Namecheap.

Then you created a DigitalOcean Droplet with this IP:

159.89.100.50

In Namecheap, you add:

Type	Host	Value
A Record	@	159.89.100.50
A Record	www	159.89.100.50

Then on your server, your Nginx config looks like this:

server {
    listen 80;
    server_name myportfolio.com www.myportfolio.com;

    root /var/www/myportfolio;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

After reloading Nginx and setting up SSL, visitors can open:

https://myportfolio.com

And see your website.

That is the full journey from domain to live website.

Hubs, Switches, and Routers Explained Like You're Debugging a Real Network

Tahsin Abrar — Mon, 11 May 2026 06:48:03 +0000

Have you ever connected your laptop to Wi-Fi, opened a browser, typed a URL, and wondered:

"How does my message actually reach the right computer?"

As developers, we often work with APIs, servers, ports, IP addresses, localhost, Docker networks, cloud servers, and routers. But networking can feel confusing because many explanations jump straight into heavy terms.

So let's slow down and make it simple.

In this post, we'll understand three important network devices:

Hub
Switch
Router

We'll also see how data moves from one computer to another inside a local network, and how your computer decides whether to send data directly to another device or through the router.

This article is based on the provided networking class transcript about hubs, switches, routers, MAC tables, and internal communication.

First, Imagine a Small Room Full of Computers

Imagine five computers connected in the same room.

One computer wants to send a message to another computer.

For example:

Computer A wants to send data to Computer D

That sounds simple. But the network has to answer some important questions:

Who sent the data?
Who should receive it?
Are both devices in the same network?
Should the data go to another device first?

This is where hubs, switches, and routers come in.

The Hub: The Loud but Not-So-Smart Device

A hub is one of the simplest network devices.

You can think of it like a loudspeaker.

When one computer sends data to a hub, the hub does not check who the data is for. It simply forwards the data to every other connected port.

So if Computer A sends data through a hub, the hub sends it to:

Computer B
Computer C
Computer D
Computer E

Even if the message was only meant for Computer D.

The other computers receive the data, check it, and then ignore it if it is not meant for them.

Why is a hub considered "not smart"?

Because a hub works at the physical layer, also called Layer 1.

It only understands electrical signals or bits.

It does not understand:

MAC addresses
IP addresses
Ports
Applications
Actual message content

So a hub cannot make smart forwarding decisions.

It just repeats the signal.

Simple way to remember a hub

A hub says:

"I don't know who needs this, so I'll send it to everyone."

That is why hubs are rarely used in modern networks.

The Switch: A Smarter Device That Learns

A switch is much smarter than a hub.

A switch works at the data link layer, also called Layer 2.

That means a switch can understand MAC addresses.

A MAC address is like the hardware address of a network device. Every network interface has one.

For example, imagine five devices connected to a switch:

Port 1 -> Computer A
Port 2 -> Computer B
Port 3 -> Computer C
Port 4 -> Computer D
Port 5 -> Computer E

Each computer has a MAC address:

Computer A -> MAC A
Computer B -> MAC B
Computer C -> MAC C
Computer D -> MAC D
Computer E -> MAC E

Now Computer A wants to send data to Computer D.

The Ethernet frame may look like this in a simplified way:

Source MAC: A
Destination MAC: D
Data: Hello

When the switch receives this frame, it checks the source MAC address.

It says:

MAC A came from Port 1

Then it saves that information in a table.

This table is commonly called:

MAC address table
CAM table
Forwarding database
Bridge table

Different books and vendors may use different names, but the idea is the same.

The switch keeps a record like this:

MAC Address    Port
A              1

What Happens When the Switch Does Not Know the Destination?

Now the switch checks the destination MAC address:

Destination MAC: D

But imagine this is the first time the switch has seen Computer D.

So the switch does not yet know which port leads to MAC D.

What does it do?

It floods the frame.

That means it sends the frame to every port except the port it came from.

So the frame goes to:

Port 2
Port 3
Port 4
Port 5

Computer B receives it and says:

This is not for me.

Computer C says the same.

Computer E says the same.

But Computer D checks the destination MAC and says:

This is mine.

So Computer D accepts the frame.

How the Switch Learns Over Time

Now Computer D replies to Computer A.

The reply frame looks like this:

Source MAC: D
Destination MAC: A
Data: Hello back

The switch receives the frame from Port 4.

It checks the source MAC address and learns:

MAC D came from Port 4

Now the switch table becomes:

MAC Address    Port
A              1
D              4

Next time Computer A sends data to Computer D, the switch does not need to flood the frame.

It already knows:

MAC D is on Port 4

So it sends the frame only to Port 4.

That is why a switch is more efficient than a hub.

Simple way to remember a switch

A switch says:

"I’ll learn where devices are, then send data only where it needs to go."

Hub vs Switch in One Simple Example

Imagine a classroom.

A hub is like a student who receives a note and shouts it to the whole class.

A switch is like a helpful class monitor who learns where everyone sits and quietly gives the note to the right person.

That is the main difference.

Where Does the Router Fit In?

A router works at the network layer, also called Layer 3.

That means a router understands IP addresses.

A switch mainly cares about MAC addresses inside a local network.

A router cares about moving data between different networks.

For example:

Your laptop -> your home network
Your home network -> the internet
The internet -> another server

The router is the device that connects your local network to other networks.

Simple way to remember a router

A router says:

"This data needs to go outside this network. I know where to send it next."

Your Home Router Is Usually More Than Just a Router

This part is important.

The device we casually call a "router" at home is usually not just a router.

It often contains multiple things inside one box:

Router
Switch
Wi-Fi access point
DHCP server
Firewall/NAT features

So when you plug an Ethernet cable into your home router, you are usually plugging it into the switch part of the device.

When your laptop connects through Wi-Fi, it connects through the wireless access point part.

The real routing happens when data needs to leave your local network and go somewhere else, like the internet.

LAN Interface and WAN Interface

A home router usually has two sides:

LAN side

This is your local network.

Your laptop, phone, printer, TV, and other home devices live here.

Example local IP addresses:

192.168.1.10
192.168.1.11
192.168.1.12

Your router may have a local IP like:

192.168.1.1

This is often called the default gateway.

WAN side

This is the side connected to your internet provider.

The router gets a public or provider-side IP address on this side.

So your router sits between:

Your private home network
The outside internet

How Does a Computer Decide Where to Send Data?

Now comes a very important question.

Suppose your computer wants to send data to another IP address.

How does it know whether the destination is inside the same local network or outside?

It uses:

Its own IP address
The destination IP address
The subnet mask
The default gateway

Usually, your computer gets these from DHCP.

A DHCP server may give your device:

IP address:       192.168.1.10
Subnet mask:      255.255.255.0
Default gateway:  192.168.1.1

Now your computer can make a decision.

Example 1: Sending Data Inside the Same Network

Let's say:

Computer A IP: 192.168.1.10
Computer C IP: 192.168.1.11
Subnet mask:   255.255.255.0

Computer A wants to send data to Computer C.

It checks whether both IP addresses belong to the same network.

With this subnet mask, both addresses are part of:

192.168.1.0/24

So Computer A understands:

Computer C is in my local network.

That means Computer A does not need to send the data to the router for routing.

Instead, it sends an Ethernet frame directly toward Computer C's MAC address.

Simplified frame:

Source MAC: A
Destination MAC: C
Source IP: 192.168.1.10
Destination IP: 192.168.1.11

The switch receives the frame and forwards it to Computer C.

The router part does not need to be involved.

Example 2: Sending Data Outside the Network

Now imagine Computer A wants to send data to:

8.8.8.8

That IP is not inside the local network 192.168.1.0/24.

So Computer A understands:

This destination is outside my network.

Now something interesting happens.

The destination IP stays as:

8.8.8.8

But the destination MAC address becomes the MAC address of the router.

Simplified frame:

Source MAC: A
Destination MAC: Router
Source IP: 192.168.1.10
Destination IP: 8.8.8.8

Why?

Because inside the local network, the computer can only deliver frames to local devices by MAC address.

To reach the outside world, it sends the frame to the default gateway first.

The router receives it, looks at the destination IP, and then decides where to send it next.

Important Detail: MAC Address Changes, IP Address Stays

This is one of the most useful networking ideas to understand.

When data moves across networks, the IP packet is trying to reach the final IP address.

But at each local network hop, the MAC address may change.

For example:

Your laptop -> Router
Router -> ISP device
ISP device -> next router
Next router -> destination server

Each step may use a different source and destination MAC address.

But the destination IP is still the final server's IP.

That is why:

Switches care about MAC addresses.
Routers care about IP addresses.

A Developer-Friendly Example

Imagine you are building a backend API.

Your laptop is running a frontend app:

http://localhost:5173

Another computer on the same Wi-Fi is running an API server:

http://192.168.1.25:3000

When your laptop calls that API, it checks:

Am I in the same network as 192.168.1.25?

If yes, your laptop sends the frame toward that device's MAC address.

The switch or Wi-Fi access point handles local delivery.

The router does not need to send the traffic to the internet.

Now imagine your app calls:

https://api.github.com

That server is outside your local network.

So your laptop sends the frame to the router's MAC address.

The router then forwards the packet toward the internet.

This is happening all the time while you code.

Quick Comparison: Hub vs Switch vs Router

Device	Layer	Understands	Main Job
Hub	Layer 1	Bits/signals	Sends data to all ports
Switch	Layer 2	MAC addresses	Sends frames inside a local network
Router	Layer 3	IP addresses	Sends packets between networks

Common Terms You Should Remember

Frame

A frame belongs to the data link layer.

It contains MAC address information.

Source MAC
Destination MAC
Payload

Packet

A packet belongs to the network layer.

It contains IP address information.

Source IP
Destination IP
Payload

Segment

A segment usually belongs to TCP at the transport layer.

It contains port information.

Source port
Destination port
Data

MAC address table

A switch uses this table to remember which MAC address is connected to which port.

MAC Address    Port
A              1
C              3
D              4

Default gateway

The default gateway is usually your router's local IP address.

Your computer sends data to the default gateway when the destination is outside the local network.

A Simple Mental Model

Here is the easiest way to remember everything:

Hub:
"I will send it to everyone."

Switch:
"I will send it to the correct local device if I know where it is."

Router:
"I will send it to another network."

That's it.

Once you understand this, many networking topics become easier:

DHCP
ARP
Subnetting
NAT
Docker networking
Kubernetes networking
Cloud VPCs
Firewalls
Load balancers

DNS Made Simple: What Really Happens Before Your Browser Opens a Website

Tahsin Abrar — Thu, 23 Apr 2026 16:25:15 +0000

We use domain names every day.

We type google.com, facebook.com, or linkedin.com into a browser, press Enter, and the website opens in seconds. It feels simple. Almost boring.

But under the hood, something very important happens before your browser can even start talking to that website.

That thing is DNS.

And here is the part many developers miss early on: if you want to understand TLS/SSL, networking, deployment, or even why a request is slow, you need to understand DNS first.

Because before secure communication begins, your browser has to answer one basic question:

"Where is this website actually hosted?”

Let's break it down in the simplest possible way.

First, let's understand the URL

Take this URL:

https://blog.example.com

It has a few parts:

https → the scheme or protocol
blog → the subdomain
example → the main domain
.com → the top-level domain (TLD)

Another example:

https://engineering.linkedin.com

Here:

https is the protocol
engineering is the subdomain
linkedin is the domain
.com is the TLD

This structure matters because DNS works with these names.

Before we go into DNS, we need to understand one thing clearly:

a domain name is not the real machine address.

It is the human-friendly name for that machine.

Why domain names exist

Humans are good at remembering words.

Machines are good at working with numbers.

That is the heart of the whole idea.

You can easily remember:

facebook.com

But remembering something like this is much harder:

157.240.22.35

That number is an IP address.

An IP address is the real network address of a machine or server.

So when you type a domain name into a browser, your system has to find the IP address behind that name.

That translation is what DNS does.

A simple real-life example

Think about your home address.

If someone knows your address, they can find your house.

Computers work in a similar way.

Every machine connected to a network needs an address. On the internet, that address is the IP address.

Now imagine you built an app locally on your laptop. Maybe it runs on:

localhost:3000

That works on your own machine because your machine knows what localhost means.

But if you deploy that app to a server on AWS, DigitalOcean, or anywhere else, people cannot visit it using localhost.

They need the address of that server.

That real address is the IP address.

But asking users to remember IP addresses is a terrible experience.

So instead of telling people:

Visit 142.250.183.206

we give the server a domain name like:

myapp.com

Now people can remember the name, and machines can still connect using the IP.

That mapping between a human-friendly name and a machine-friendly IP is the whole point of DNS.

So what is DNS?

DNS stands for Domain Name System.

Let's keep it simple:

DNS is the system that converts a domain name into an IP address.

For example:

You type facebook.com
DNS finds the IP address behind facebook.com
Your browser uses that IP to contact the correct server

It is called a system because it is not just one thing.

It involves multiple parts working together:

your browser
your operating system
DNS caches
a DNS resolver
root name servers
TLD name servers
authoritative name servers

That is why it is not called just "domain name lookup.”

It is a system.

Before DNS goes to the internet, it checks cache

This is one of the most useful things to understand.

When you visit a website, your computer does not always start from scratch.

It first checks whether the answer is already stored somewhere.

This stored answer is called cache.

Think of cache like a shortcut memory.

If the system already knows the IP address for a domain, it can skip a lot of work.

That makes everything faster.

Usually, the lookup goes through these layers:

Browser cache
Operating system cache
DNS resolver cache
If not found, then the full DNS lookup starts

That is why websites often open very quickly the second time you visit them.

The full DNS journey, step by step

Now let's walk through what actually happens when you type:

facebook.com

into your browser.

1. The browser checks its own cache

Your browser first asks:

"Do I already know the IP for this domain?”

If yes, great. It uses that IP immediately.

If not, it moves to the next step.

2. The operating system checks its cache

If the browser does not have the answer, your operating system checks whether it has that domain-to-IP mapping stored.

If the OS already knows it, it returns the IP to the browser.

If not, the request continues.

3. The system asks a DNS resolver

Now the request goes to a DNS resolver.

In many cases, this resolver belongs to your ISP, though it could also be a public DNS service.

Its job is to find the answer for you.

And just like the browser and OS, the resolver also checks its own cache first.

If the resolver already knows the IP for facebook.com, it returns it immediately.

If not, now the real DNS lookup begins.

The resolver starts asking other DNS servers

This is where many learners get confused, but the logic is actually very clean.

The resolver does not magically know every IP address in the world.

Instead, it asks the right servers in the right order.

4. It asks a root name server

The resolver asks a root name server something like:

"I need information about .com. Where should I go next?”

Notice something important:

It is not asking for the final IP address yet.

It is asking where the .com information is managed.

The root server replies with the address of the TLD name server for .com.

5. It asks the TLD name server

Now the resolver goes to the .com TLD server and asks:

"Who is responsible for facebook.com?”

Again, this server usually does not return the final website IP directly.

Instead, it returns the address of the authoritative name server for that domain.

That server is the source of truth for the domain's DNS records.

6. It asks the authoritative name server

Now the resolver asks the authoritative name server:

"What is the IP address for facebook.com?”

This server returns the actual DNS record, such as the IP address.

Now the resolver finally has the answer it needs.

7. The answer comes back and gets cached

Once the resolver gets the IP address, it does two useful things:

it returns the answer to your operating system
it stores the answer in cache for future requests

Then the OS may cache it too.

Then the browser may cache it too.

That means the next lookup can be much faster.

8. The browser can finally contact the server

Now your browser has the IP address.

At this point, it can finally open a network connection to the actual server and send the real HTTP or HTTPS request.

That is the moment when the website request truly begins.

So yes, DNS happens before the browser can talk to the web server.

And that is exactly why DNS matters when learning TLS/SSL.

A simple mental model

If all the server names sound too abstract, use this mental model:

Root server → "I do not know the full answer, but I know who handles .com.”
TLD server → "I do not know the full answer, but I know who handles facebook.com.”
Authoritative server → "I am responsible for this domain. Here is the actual answer.”

That is the chain.

Why DNS is called "resolution”

You may hear the phrase:

DNS resolution

This simply means:

the process of resolving a domain name into an IP address

So if someone says:

"The DNS resolution failed”

they mean:

"The system could not turn the domain name into an IP address”

No IP, no connection.
No connection, no website.

Where subdomains fit into this

Let's say you have a domain like:

example.com

You can create subdomains like:

blog.example.com
api.example.com
admin.example.com

This is useful because one domain can support multiple services.

For example:

blog.example.com → blog website
api.example.com → backend API
admin.example.com → internal admin dashboard

Same parent domain.
Different subdomains.
Different purposes.

That is why learning domain structure matters before learning DNS deeply.

Why websites feel fast after the first visit

A lot of developers notice this but do not always connect it to DNS.

The first request may take a bit longer because the system needs to find the IP.

Later requests are faster because the answer may already exist in:

browser cache
OS cache
resolver cache

That means the system can skip most of the lookup chain.

So if a website opens instantly the second time, caching is often part of the reason.

Does DNS use TCP or UDP?

In simple learning material, DNS is often explained with UDP, and that is a good starting point.

Why?

Because UDP is lightweight and fast. It does not need a full connection setup like TCP.

For many standard DNS queries, that makes it a great fit.

A simple way to think about it is:

DNS wants to ask a quick question
get a quick answer
and move on

That said, in real systems, DNS can also use TCP in some cases.

But when you are first learning how DNS feels fast and lightweight, starting with UDP gives you the right intuition.

Why DNS matters before TLS/SSL

This is the part many people skip.

They jump into HTTPS, SSL certificates, and TLS handshakes without asking a more basic question:

How did the browser even find the server in the first place?

Before secure communication starts, the browser needs to know where to connect.

That means:

resolve the domain name into an IP address
connect to the server
then begin TLS/SSL and HTTP communication

So if DNS is unclear, TLS/SSL will always feel a little foggy too.

Understanding DNS first makes the next networking topics much easier.

Why developers should care about this

It is easy to think:

"Do I really need to know all this? I can just build apps.”

You can. For a while.

But sooner or later, deeper understanding starts to matter.

Maybe:

your production request is slow
your domain is not pointing to the right server
your subdomain is broken
your SSL setup is failing
your infrastructure behaves differently across environments
a tool's official docs feel harder than they should

This is where fundamentals help.

When you understand DNS, you stop treating networking like magic.

You start seeing the path.

And once you can see the path, debugging becomes easier.

A small story every developer can relate to

Imagine this.

You deploy your app.
The code is fine.
The server is running.
But the site still does not open.

At first, you think:

is the backend broken?
is the port wrong?
is Nginx failing?
is HTTPS misconfigured?

But the real problem turns out to be simple:

the domain is not resolving correctly.

That one small DNS issue can make the whole app feel "down.”

This is why solid developers do not only learn frameworks.

They learn what happens around the request too.

The big lesson: do not skip the basics

A lot of hard topics become easier when your basics are strong.

Docker makes more sense.
Kubernetes makes more sense.
TLS/SSL makes more sense.
Load balancers, CDNs, proxies, reverse proxies, and hosting all make more sense.

Not because they are easy.

But because you already understand the ground they stand on.

Many developers struggle with official docs not because their English is bad, but because the underlying computer science concepts are still shaky.

That is normal.

And the fix is not shortcuts.

The fix is going back, learning the core ideas properly, and revisiting them again and again until they feel natural.

That is how real confidence is built.

Demystifying TCP: How the Internet Actually Sends Your Data (Without Losing It)

Tahsin Abrar — Mon, 13 Apr 2026 07:58:22 +0000

Let’s be honest for a second. When we write code to fetch data from a server, we usually don't think twice about how it gets there. We write a simple JavaScript fetch() call, hit save, and boom our frontend talks to our backend.

fetch('https://api.example.com/data', {
  method: 'POST',
  body: JSON.stringify({ message: "Hello World" })
});

To us, it feels like magic. We just say "send this," and it arrives. But the Application Layer (where our code lives) is blissfully unaware of the chaotic, noisy, and unpredictable journey that data takes across the internet.

The real unsung hero making sure your "Hello World" doesn't turn into a corrupted mess of random bytes is the Transport Layer specifically, the TCP (Transmission Control Protocol).

Today, we are going to look under the hood. No dry, boring textbook definitions. Just a practical, developer-friendly look at how TCP actually works, how it keeps our data safe, and why understanding it will make you a much better software engineer.

What is TCP, Really?

Imagine you are mailing a 1,000-page manuscript to a publisher, but the post office only allows you to send one page per envelope.

If you just dump 1,000 envelopes into the mailbox, what happens? Some might get lost. Some might arrive out of order. The publisher would be hopelessly confused.

TCP is the ultimate postal manager. It chops your big data into smaller pieces called segments, numbers them, sends them, and waits for a receipt. If a piece goes missing or gets corrupted, TCP demands that it be sent again.

That’s why the "C" in TCP stands for Control. It controls the transmission so you don't have to.

To do this, TCP breaks communication down into three distinct phases:

The Setup (Three-way Handshake)
The Data Transfer
The Teardown (Four-way Finishing)

Let’s walk through them.

Phase 1: The Three-Way Handshake 🤝

Before TCP sends a single byte of your actual data, it needs to make sure the server is awake, willing, and ready to talk. It does this using a process called the Three-Way Handshake.

Imagine calling a friend on the phone:

You: "Hey, are you there? Can you hear me?" (SYN)
Friend: "Yeah, I hear you! Can you hear me?" (SYN-ACK)
You: "Loud and clear. Let's talk." (ACK)

In TCP terms, it looks like this:

SYN (Synchronize): The Client sends a packet with the SYN flag turned on. It says, "I want to connect, and I'm starting my sequence at number 1000."
SYN-ACK (Synchronize-Acknowledge): The Server replies. "I got your request (ACK 1001), and I also want to connect. My sequence starts at 2000" (SYN).
ACK (Acknowledge): The Client sends one final confirmation. "Got it. I'm ready for your data starting at 2001."

Boom. The connection is established. Now, they can safely send data.

What’s Inside a TCP Segment? (The Anatomy of a Header)

When TCP chops up your data, it doesn't just send raw text. It wraps your data in a Header a block of metadata that contains all the instructions for delivery.

A TCP header is usually between 20 and 60 bytes. Let's break down the coolest parts of this header.

1. The Ports (Source & Destination)

You probably know that an HTTP server runs on port 80, HTTPS on 443, and your local React app maybe on 3000. But have you ever wondered what port the client (your browser) uses to make the request?

The TCP header reserves 16 bits each for the Source Port and the Destination Port. 16 bits means $2^{16} - 1$, which gives us a maximum of 65,535 possible ports.

Well-known ports (0 - 1023): Reserved for big stuff. (80 for HTTP, 443 for HTTPS, 22 for SSH).
Registered ports (1024 - 49151): Used by specific apps (like MySQL on 3306).
Ephemeral / Dynamic ports (49152 - 65535): This is the secret sauce!

When your browser makes a request to Facebook (port 443), your Operating System randomly grabs an unused Ephemeral port (let's say 50153) and assigns it to your browser. So the request goes from Your_IP:50153 to Facebook_IP:443. When Facebook replies, it knows exactly to send the data back to port 50153, so it reaches your exact browser tab!

2. Sequence & Acknowledgment Numbers

These are the page numbers of our manuscript analogy.

Sequence Number: "This is byte number 1001 of my data."
ACK Number: "I successfully received up to byte 1005. Please send byte 1006 next."

3. Window Size (Flow Control)

Imagine trying to drink from a firehose. You'd drown. Servers can experience the same thing if a client sends data too fast.

The Window Size is the server politely saying: "Listen, I can only handle 10,000 bytes at a time right now. Don't send me more than that until I acknowledge receipt, or I'll crash." This prevents overwhelming the receiver.

4. The Checksum (Error Detection)

As data travels across the ocean through fiber optic cables, routers, and Wi-Fi signals, electrical interference can flip a bit (turn a 0 into a 1). Your "I love you" might suddenly turn into "I hate you".

To fix this, TCP uses a Checksum. Before sending, the sender takes all the data, adds it up in a specific binary way, flips the bits (One's Complement), and puts that value in the Checksum field.

When the receiver gets it, they do the exact same math. If their result doesn't perfectly match, they know the data got corrupted in transit. They silently drop the corrupted segment, forcing the sender to re-transmit it.

5. Flags

These are tiny 1-bit switches that tell the receiver what kind of segment this is. Is it a setup request (SYN)? Is it an acknowledgment (ACK)? Or is it time to close the connection (FIN)?

Phase 2: Sending the Data

Once the handshake is done, the actual data transfer begins.

Let's say we are sending the string "Hello World". Based on the Maximum Segment Size (MSS) agreed upon during the handshake, TCP might split this into multiple segments.

The client sends "Hell", the server ACKs it. The client sends "o Wo", the server ACKs it.

Because of the Window Size, the client doesn't actually have to wait for an ACK after every single segment. If the window is large enough, it can blast 10 segments at once, and the server can send a single ACK saying, "Yep, got all 10!"

If an ACK never arrives, the sender's internal timer runs out, and it assumes the data was lost in the void. It then resends the data. That's the beauty of it it guarantees delivery.

Phase 3: The Four-Way Teardown 👋

When the client is done sending data, it doesn't just hang up the phone. It's polite. It initiates a Four-Way Teardown.

Client: Sends a FIN (Finish) flag. "I'm done sending data."
Server: Sends an ACK. "Understood, you're done." (At this point, the server might still have a little bit of its own data left to send back to the client. The client will wait and listen).
Server: Sends its own FIN. "Okay, I'm done sending data too."
Client: Sends a final ACK. "Got it. Goodbye forever."

The connection is closed, and the OS frees up the ephemeral port to be used by another application later.

Why Should You Care as a Developer?

You might be thinking, "This is cool, but my framework handles this. Why do I need to know it?"

Because things break.

When your API requests start timing out, understanding the Three-way Handshake helps you debug if a firewall is blocking your SYN packets.
When you wonder why you can't run two node servers on port 3000, you now understand how Ports bind to processes.
When you design high-traffic systems, understanding Window Size helps you realize why servers get overwhelmed and drop connections.

Understanding TCP is like moving from driving an automatic car to a manual transmission. You don't have to think about the gears every day, but when you're stuck in the mud, knowing exactly how the engine connects to the wheels is what gets you out.

Why We Talk OSI but Live in a TCP/IP World (A Developer’s Guide)

Tahsin Abrar — Sun, 12 Apr 2026 10:55:37 +0000

If you’ve ever sat in a tech meeting and nodded along while another engineer threw around terms like "Layer 7 load balancing" or "L4 routing," you aren't alone.

We talk about networking a lot in software development, but there’s a funny quirk in our industry: the model we learn in textbooks isn't exactly the model that runs the internet.

In our last deep dive, we talked about the OSI model a beautiful, theoretical 7-layer philosophy. But out in the wild? The entire world runs on the TCP/IP model.

Today, let's bridge the gap between theory and reality, figure out how data actually moves across the internet, and look at the only layers you actually need to care about as a software engineer.

The Reality Check: 7 Layers vs. 5 Layers

The OSI model breaks networking down into 7 distinct layers. But the TCP/IP model, which is what actually powers the internet today, condenses things down to just 5 layers:

Application Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer

Wait, what happened to the Presentation and Session layers from the OSI model?

In the real world, they didn't disappear; they just got absorbed. When you are building a modern web app say, a Nuxt.js frontend communicating with a Laravel backend your browser and framework handle everything at once.

When you type "Hello" in a chat app, the Application Layer formats that text into JSON (what the Presentation layer used to do), compresses it, converts it to binary, and even checks if the other person is online with that little green dot (what the Session layer used to do). Because the Application Layer handles all of this heavy lifting, the TCP/IP model just groups them together.

A Crucial Developer Rule: Even though the TCP/IP model condensed the top layers, we still use OSI numbering in our everyday developer conversations! We still call the Application Layer L7. We call the Transport layer L4, Network is L3, and Data Link is L2. If you ever call the Application layer "L5," other engineers will look at you funny. Always stick to the L7 terminology!

Layer 4: The Transport Layer (TCP vs. UDP)

Once your application has prepped the data, it hits the Transport Layer. This is where we decide how the data is going to travel, and you have two main choices: TCP or UDP.

TCP (Transmission Control Protocol)

Think of TCP as the highly reliable, slightly slower courier who requires a signature on delivery. It is 100% controlled.

Imagine you are sending a text message that says "I LOVE YOU." If the data gets scrambled and arrives as "O I V E U Y," you're going to have a bad time. For text, JSON payloads, important API requests, or critical database transactions, we use TCP. It ensures every single piece of data arrives in the exact right order. When using TCP, your data is broken down into chunks called Segments.

UDP (User Datagram Protocol)

UDP is the fast, reckless delivery driver throwing newspapers onto your porch without stopping. It doesn't care if a few get lost in the bushes.

We use UDP for things like live video streaming. If a stream contains 10 million frames and a couple of them drop out, your screen might glitch for a fraction of a second, but the video keeps playing. You wouldn't want the whole live stream to pause just to retrieve one missing frame. When using UDP, your data is broken down into chunks called Datagrams.

Moving Down the Stack: L3 to L1

After the Transport Layer, the data keeps moving down the chain:

Network Layer (L3): This is where IP addresses come in. Your data (the Segment or Datagram) gets tagged with the Sender's IP and the Receiver's IP. Once those are attached, the whole package is now called a Packet.
Data Link Layer (L2): Here, we attach MAC addresses to figure out the physical hardware hops the packet needs to take.
Physical Layer (L1): Finally, everything is converted into 1s and 0s raw electrical signals or light pulses shooting through cables.

A quick note for my fellow software engineers: You really only need to master L7, L4, L3, and L2. Unless you have a burning desire to become an electrical engineer, you can safely let the hardware folks worry about the Physical Layer!

A Quick Trip Back to 1969

You might be wondering: if OSI is the standard, why is TCP/IP so different?

It actually comes down to the Cold War. In 1969, the US Defense Department created an organization called ARPANET. They needed a decentralized network where data could survive even if computers or physical locations were destroyed in a war. Over the next decade, they actively developed the TCP/IP model.

It was messy, organic, and random. In fact, TCP was being used to send data long before IP addresses were even a standard! The beautifully organized, perfectly logical OSI model didn't actually come along until 1984 to try and make sense of it all. We teach OSI first because it's fundamentally easier to understand, but TCP/IP is the battle-tested system that won the internet.

Demystifying Linux: How GNU, Shells, and Terminals Actually Work Together

Tahsin Abrar — Tue, 07 Apr 2026 10:09:39 +0000

If you've been working with Linux for a while, you probably know that "Linux" technically just refers to the kernel. But a kernel alone is not enough to give you a working computer. To get a complete Operating System (what we call a Linux Distribution, like Ubuntu or Fedora), you need a lot of other moving parts.

Today, we're going to peel back the layers of a Linux operating system. We'll look at where the tools we use every day actually come from, the difference between a terminal and a shell, and what happens behind the scenes when you type a simple command.

Let's dive in!

The Origin Story: Enter Richard Stallman and GNU

To understand how Linux works today, we have to travel back to 1983. Back then, an operating system called Unix was highly popular among universities and large companies. The problem? Unix was proprietary and expensive.

A programmer named Richard Stallman didn't like this. He believed software, especially operating systems, should be free and accessible to everyone. So, he started the Free Software Foundation (FSF) and launched the GNU Project.

Fun fact: GNU is a recursive acronym that stands for "GNU's Not Unix!"

Stallman's team began building free, open-source replacements for all the essential pieces of Unix. Their plan was to build everything needed for an OS, so that anyone students, devs, or companies could piece together a free operating system.

If you use open-source tools today, you owe a huge "thank you" to Stallman and the FSF.

The Essential GNU Toolkit

So, what exactly did the GNU project build? They created a massive bundle of tools that bridge the gap between human developers and the kernel. Here are the heavy hitters:

1. GCC (GNU Compiler Collection)

If you've ever written a C program, you know you can't just run the raw text. You need to compile it into binary machine code that the computer understands. GCC is the legendary compiler that makes this happen. Without it, the open-source world as we know it wouldn't exist.

2. glibc (GNU C Library)

This one is fascinating. When you write a simple printf("Hello World"); in C, did you know that printf isn't actually a native part of the C language?

Native C handles things like if/else' statements andfor' loops. But interacting with hardware (like printing to a screen, allocating memory, or reading files) requires talking to the kernel. glibc is the massive library that provides functions like printf, scanf, and malloc. It acts as a translator, taking your code and making the complex "system calls" to the kernel on your behalf.

3. GNU Coreutils

This is the toolbox you use every single day. Have you ever typed ls, cd, cat, grep, cp, or rm?
These aren't just random words; they are individual, standalone programs bundled together in what we call the GNU Core Utilities (or Coreutils). They run in the "user space" and allow you to interact with your system.

The Visual Layer: Desktop Environments (DE)

Okay, so we have the kernel (the engine) and the GNU utilities (the steering wheel and pedals). But how do we actually see what we are doing?

That's where Desktop Environments (DE) come in. When you install an OS and see a taskbar, window frames, a file explorer, and icons, you are looking at the DE.

Here are a few popular ones:

GNOME: The default for Ubuntu, Fedora, and Debian. It's modern and beginner-friendly.
KDE Plasma: Popular on Arch and openSUSE. It's incredibly customizable.
Aqua: The proprietary desktop environment used by Apple for macOS (which includes the Finder and the Dock).

The Desktop Environment is also responsible for giving you a Terminal. On Ubuntu (GNOME), it's called GNOME Terminal. On KDE, it's called Konsole. The terminal is just a graphical window an interface that lets you type things. But it doesn't process the commands itself. For that, it needs a Shell.

The Brains of the Operation: The Shell

If the Terminal is just a blank window, the Shell is the smart program running inside it.

The Shell takes the text you type, interprets it, figures out what program you want to run (like an ls command from the Coreutils), and hands that request over to the kernel. When the kernel is done, the Shell takes the output and prints it on your Terminal screen.

A Quick History of Shells:

sh (Bourne Shell): Created by Stephen Bourne at Bell Labs in 1977. The OG.
ksh (KornShell): Created by David Korn in 1983, adding more features.
bash (Bourne Again Shell): The GNU project's free answer to the original Bourne shell. It became the default for almost all Linux distributions for decades.
zsh (Z Shell): A modern, highly customizable shell. If you use a modern Mac, zsh is now the default

Stop Calling Docker a Tool: The Real Story Behind 'docker run hello-world'

Tahsin Abrar — Mon, 06 Apr 2026 10:57:28 +0000

Let’s get one thing straight right out of the gate: Docker is not just a tool. It’s not just a simple application, and it’s certainly not just a piece of standalone software.

If someone tells you Docker is just a software tool, you can confidently tell them they’ve been misled.

So, what is it? Docker is a platform. It is an ecosystem.

To truly master Docker, you have to stop looking at it as a black box that magically runs your code, and start looking at it as a living, breathing ecosystem. Today, we are going to dive deep into how this ecosystem actually works.

The Ecosystem Analogy

Think about a biological ecosystem a food chain. An earthworm is eaten by a duck, the duck is caught by a snake, the snake is hunted by a mongoose, and the mongoose is swooped up by an eagle.

For the ecosystem to function, every single piece of that chain has to exist and interact. Docker works exactly the same way. It is a chain of distinct technologies working together to create what we call the "Docker Platform."

Before we look at the chain in action, let’s meet the main characters:

Docker Client (CLI): The interface where you type your commands.
Docker Engine (dockerd): The background daemon (the brain) that listens for API requests and manages Docker objects.
Docker Desktop: The unsung hero for Mac and Windows users. It quietly creates a Linux Virtual Machine in the background so the Docker Engine has a Linux kernel to work with.
Docker Images: Think of an image as a "screenshot" or a frozen snapshot of a container.
Docker Hub: The massive, cloud-based database where all these images (like Ubuntu, Redis, Postgres, or Node) live.
Docker Compose: (We’ll save this one for a future post, but just know it’s the orchestrator for multi-container setups!)

The Deep Dive: What actually happens when you hit Enter?

Most developers know how to type docker run hello-world. But what happens in the milliseconds after you hit enter? Let’s connect the dots.

Step 1: The Request

You type docker run hello-world into your terminal. The Docker Client catches this command and translates it into a REST API request. It sends this request to the Docker Engine (specifically, the dockerd daemon).

Step 2: Passing the Baton

dockerd is a busy manager. It receives your request and says, "Hey, **containerd* (the high-level container runtime), handle this for me."*

Step 3: The Cache Check

containerd acts like a smart librarian. First, it checks its local cache. It asks: "Do we already have the hello-world image downloaded on this computer?" If this is your first time running it, the answer is no.

Step 4: The Download (Pulling)

Because the image isn't stored locally, containerd reaches out to Docker Hub. It requests the hello-world image, pulls it down, and caches it locally so it won't have to download it again next time.

Step 5: The Build

Now that it has the image, containerd hands it over to runc (the low-level runtime) and says, "Execute this." ### Step 6: The Kernel Magic
Here is where the real magic happens. runc talks directly to the Linux Kernel (which, if you are on Mac/Windows, is provided by Docker Desktop).

It asks the kernel for two very specific things:

Namespaces: To create an isolated "alternate reality" for the container so it can't see what else is running on your machine.
Control Groups (cgroups): To set strict limits on how much RAM, CPU, and Hard Drive space this specific container is allowed to use.

The kernel agrees, builds this isolated little world, and the container is born!

Step 7: The Response

A new process starts inside that container, executes the hello-world script, and sends a success message all the way back up the chain from the daemon, to the CLI, and finally onto your screen.

What happens if you run it a second time?
Try running docker run hello-world again. Notice how much faster it is? It completely skips Docker Hub. containerd finds the image in the local cache, hands it straight to runc, and the container spins up instantly.

The "Just Make it Work" Trap

You might be wondering: Why do I need to know all of this? Here is a hard truth: there are software engineers out there with 5 to 10 years of experience who couldn't explain what you just read. They never dive deep. They treat Docker as a magical black box because their only goal is to "just make it work."

It’s easy to be lazy. It's easy to just copy-paste terminal commands. But taking the easy route puts a hard ceiling on your career.

Think of your brain like a massive library. If you just throw random facts into it without organizing them, you'll never be able to find the information when a server crashes at 2 AM. But if you take the time to connect the dots if you organize your knowledge logically, understanding how dockerd talks to containerd you create a mental index.

When you learn this way, you never forget.

DEV Community: Tahsin Abrar

Mid-Year Backend Reset: My H2 Goals for Speed, Security, and Better Docs

Why I Like Doing a Mid-Year Engineering Reset

Goal 1: Improve Performance

Where I Want to Focus

Practical Steps I Want to Take

Goal 2: Strengthen Security

The Areas I Want to Recheck

Practical Steps I Want to Take

Goal 3: Improve Documentation

What I Want to Document Better

Practical Steps I Want to Take

Keeping the Reset Realistic

Redis on Windows with Laragon and Laravel: The PATH Issue That Looks Like a Redis Issue

The Real Situation

Step 1: Find the Redis CLI File

Step 2: Test Redis Using the Full Path

Step 3: Add Redis CLI to Git Bash PATH

A Small Redis CLI Mistake That Can Confuse You

Step 4: Make Sure Redis Server Is Running

Step 5: Configure Laravel .env

Step 6: Install Laravel Dependencies

Predis vs PhpRedis

Step 7: Test Redis from Laravel Tinker

Common Errors and What They Really Mean

bash: redis-cli: command not found

Class "Predis\Client" not found

Class "Redis" not found

Redis Works in www but Not in Another Folder

Final Working Setup

How to Create a GitHub Pull Request from the Terminal

First, Know the Difference: git pull vs Pull Request

git pull

Pull Request

Step 1: Update Your Main Branch

Step 2: Create a New Branch

Step 3: Make Your Code Changes

Step 4: Add Your Files

Step 5: Commit Your Changes

Step 6: Push Your Branch to GitHub

Step 7: Install GitHub CLI

On Windows

On macOS

Step 8: Login to GitHub CLI

Step 9: Create a Pull Request from the Terminal

Create a Pull Request in One Command

What Should You Write in a Pull Request?

PR Title

PR Body

Best Way to Write a Multiline PR Body

One-Line Multiline Body Without a File

Bash, Git Bash, or macOS Terminal

Windows PowerShell

Check Your Pull Request

The Full Practical Workflow

Common Problems and Fixes

Problem 1: gh: command not found

Problem 2: You Are Not Logged In

Problem 3: Current Branch Is Not Pushed

Problem 4: Pull Request Is Created from the Wrong Branch

Stop Guessing in Controllers: Debug MySQL Directly

The Day I Realized Controller Debugging Wasn’t Enough

The Real Problem

Instead of Guessing, Watch the Database Directly

This Is Why Framework-Level Debugging Often Fails

The Most Useful MySQL Debugging Tools

1. General Query Log

2. Slow Query Log

3. InnoDB Status

4. General Log Table Audit

Prerequisite: Make Sure General Log Writes to Table

View Latest Queries from General Log Table

Filter Only Actual SQL Queries

Find Queries for a Specific Table

Check Only INSERT Queries

Check UPDATE and DELETE Queries

Check COMMIT and ROLLBACK

Trace One Request Using Thread ID

Trace Transaction Start, Commit, and Rollback

Can We Filter POST Requests from MySQL?

Step 5: Configure Laravel `.env`

`bash: redis-cli: command not found`

`Class "Predis\Client" not found`

`Class "Redis" not found`

Redis Works in `www` but Not in Another Folder

First, Know the Difference: `git pull` vs Pull Request

`git pull`

Problem 1: `gh: command not found`

What Happens When `main()` Runs?

What Happens When `add()` Is Called?

How `add()` Finds `x`, `y`, and `result`

Returning Back to `main()`