DEV Community: Hamid Shoja

A tip from a senior engineer

Hamid Shoja — Mon, 19 Jan 2026 18:12:06 +0000

The Trade-off: Clean Testing vs. Code Brevity in Modern JS

Hamid Shoja ・ Jan 19

Uvicorn in Modern Python APIs

Hamid Shoja — Mon, 19 Jan 2026 18:10:24 +0000

A quick guide to why Uvicorn is essential for Python developers in 2026, how to use it, and how it stacks up against other languages.

What is Uvicorn?

Uvicorn is a high-speed ASGI (Asynchronous Server Gateway Interface) server. While frameworks like FastAPI or Starlette help you write your code, Uvicorn is the "engine" that actually runs the code and handles web requests from users.

Why do we use it?

In the past, Python servers (WSGI) could only handle one request at a time per process. Uvicorn uses an asynchronous event loop, allowing it to handle thousands of concurrent connections (like WebSockets or long-polling) without waiting for one to finish before starting the next.

Quick Start Example

Install:

pip install uvicorn

Code (main.py):

async def app(scope, receive, send):
    await send({
        'type': 'http.response.start',
        'status': 200,
        'headers': [[b'content-type', b'text/plain']],
    })
    await send({
        'type': 'http.response.body',
        'body': b'Hello, Dev.to!',
    })

Run:

uvicorn main:app --reload

Alternatives to Consider

Hypercorn: Great if you need HTTP/3 support.
Daphne: The go-to for Django Channels.
Granian: A Rust-based runner for those who need even more speed.

Architecture Comparison (Python vs. The World)

How does Uvicorn's "Event Loop" compare to other languages in 2026?

Perfomance

Unicorn: ~150k requests/sec; excellent for I/O but limited by the Global Interpreter Lock (GIL).

Nodejs: ~600k requests/sec; highly optimized for I/O-bound web traffic.
Go (Goroutines): >1M requests/sec; built-in concurrency makes it a "workhorse" for microservices.
Rust (Tokio/Axum): >1M requests/sec; the fastest model due to lack of garbage collection and zero-cost abstractions.

Cpu-intensive tasks

In a single-threaded async loop, one heavy CPU calculation can freeze the entire server. We should offload blocking tasks to a thread pool or a separate worker (like Celery/Arq) to keep the Uvicorn loop responsive.

Example: Use run_in_executor for blocking code.

import asyncio

@app.get("/heavy-task")
async def heavy_task():
    # Don't run blocking code directly; offload it to keep the loop free
    loop = asyncio.get_running_loop()
    result = await loop.run_in_executor(None, some_blocking_heavy_math)
    return result

Summary

If you are building a modern Python web app, Uvicorn is the standard choice. It balances the ease of Python with the speed required for modern, real-time web applications.

Follow for more bite-sized dev tutorials! 🚀
HASH

refs:
https://medium.com/@yogeshkrishnanseeniraj/scaling-django-async-workers-uvicorn-gunicorn-celery-and-redis-full-benchmarking-guide-fef057069e96#:~:text=Uvicorn%20alone%20provides%20excellent%20async,with%20low%20to%20moderate%20traffic.
https://stackoverflow.com/questions/21485920/single-threaded-event-loop-vs-multi-threaded-non-blocking-worker-in-node-js#:~:text=As%20a%20minor%20addendum%20I,57.8k10%2093%20131
https://www.youtube.com/watch?v=n0KETvEqiCk&t=57

The Trade-off: Clean Testing vs. Code Brevity in Modern JS

Hamid Shoja — Mon, 19 Jan 2026 17:57:48 +0000

Hey fellow devs! 👋

In modern JavaScript and TypeScript development, we are constantly balancing two opposing forces: the desire for Code Brevity (writing concise, minimal code) and the need for Clean Testing (writing code that is easy to isolate and verify).

Often, the code that is fastest to write is the hardest to test.

Conversely, code designed for testability often looks "boilerplate-heavy" at first glance.

Let's explore this trade-off through real-world examples, moving from common patterns to the mindset required for architecting long-term scalable systems.

Round 1: The Environment Variable Dilemma

This is a classic debate that often appears in code reviews. How do you access environment variables like API keys or feature flags provided by Vite, Webpack, or Node?

The "Brief" Approach (Static Constants)

The fastest way is to read the variable directly and store it in a constant. It's one line of code. It's simple.

// config.ts
export const IS_PRODUCTION = import.meta.env.PROD;
export const API_URL = import.meta.env.VITE_API_URL;
// myFeature.ts
import { IS_PRODUCTION } from './config';
if (IS_PRODUCTION) {
  // do scary real things
}

The Hidden Cost

This code is brief, but it is tightly coupled to the build system's global state.

When you write a unit test for myFeature.ts, the IS_PRODUCTION constant is evaluated immediately when the test file loads. Once that constant is set to true or false, it is extremely difficult to change it within the same test suite run.

To test both scenarios, you often have to resort to "stubbing globally" , telling your test runner (like Vitest or Jest) to fundamentally alter how the JavaScript runtime behaves.

// ❌ Messy Global Testing
vi.stubEnv('PROD', 'true'); 
// Now EVERY test thinks it's prod until you remember to unstub it.
// If you forget, other tests break mysteriously.

The "Testable" Approach (Getter Functions)

The alternative is to wrap the access in a function. It adds boilerplate. It feels slightly redundant.

// config.ts
// It's just a function returning a value
export const getIsProduction = () => import.meta.env.PROD;
// myFeature.ts
import { getIsProduction } from './config';
// We call the function now
if (getIsProduction()) {
  // do scary real things
}

The Benefit: Creating a "Seam"

From a Senior Engineering perspective, we have just created a Seam.

A Seam is a concept (popularized by Michael Feathers) referring to a place where you can alter the behavior of your program without editing the source code.

In our tests, we no longer need to hack the global environment. We just need to spy on a standard JavaScript function.

// ✅ Clean Isolated Testing
import * as Config from './config';
test('does scary things only in prod', () => {
  // Create the seam just for this test block
  const spy = vi.spyOn(Config, 'getIsProduction');
  spy.mockReturnValue(true);
  // run expectations...
  spy.mockReturnValue(false);
  // run other expectations...
});

The testable approach trades brevity for isolation and control.

Round 2: Dealing with Time

Another common area where brevity hurts testing is handling current time.

The "Brief" Approach (Direct Access)

Imagine a function that determines if a discount code is expired.

// discount.ts
export const isDiscountExpired = (expiryDate: Date): boolean => {
  // Brevity wins here:
  const now = new Date(); 
  return now > expiryDate;
}

This code is incredibly short. But it is non-deterministic.

If you write a test today that says "Expires tomorrow should return false", that test will pass today. But if you run that same test suite tomorrow, it will fail.

To test this, you again have to rely on heavy-handed global tool hacks like "Fake Timers" to freeze the system clock of the test runner.

The "Testable" Approach (Dependency Injection)

To make this testable, we need to take control away from the function itself and inject the dependency (time).

We can do this via a defaulted parameter (a lightweight form of Dependency Injection).

// discount.ts
// We allow 'now' to be passed in, but default to current time
export const isDiscountExpired = (
  expiryDate: Date, 
  now: Date = new Date() // Default value makes it easy to use in app code
): boolean => {
  return now > expiryDate;
}

Now the test is trivial and deterministic. We don't need to freeze system time; we just pass in a fixed date.

// ✅ Clean Testing
test('checks expiration', () => {
  const fixedNow = new Date('2024-01-01T10:00:00Z');
  const tomorrow = new Date('2024-01-02T10:00:00Z');
  // We inject our fixed time, guaranteeing the result forever
  expect(isDiscountExpired(tomorrow, fixedNow)).toBe(false);
});

The Senior Engineer's Mindset

When you are a junior or mid-level developer, your primary metric is often "velocity" , how fast can I ship this feature? Brevity helps velocity in the short term.

As you advance to senior or principal roles, your primary metrics shift to maintainability, stability, and risk reduction.

Shift Left

We want to "shift left" on bugs , finding them during unit tests on a developer's machine, rather than in QA or production.

If code is brief but relies on global state (like import.meta.env or new Date()), developers will instinctively avoid writing tests for it because writing those tests is difficult and painful.

By introducing slight amounts of boilerplate , creating getter functions, injecting dependencies, creating seams , we lower the friction required to write a test.

Conclusion

Choose Brevity for throwaway prototypes, simple scripts, or incredibly confined UI components that have zero logic.
Choose Testability for business logic, configuration, helpers, and anything that your application relies on to function correctly over time.

It looks like more code today, but it buys you peace of mind tomorrow.

If this helped, give it a heart!
Hash

Understanding MCP Through a Simple Example: A Practical Introduction

Hamid Shoja — Sat, 17 Jan 2026 18:41:59 +0000

Hey fellow devs! 👋

I’ve been working with MCP fairly often and like most of us, I learn best by actually building something. Not something production-ready or revolutionary — just something simple enough to understand what MCP actually does.

That’s why I built a basic currency converter using MCP. It’s intentionally simple, but that’s the point.

Let me walk you through what can be learned from this example.

A Personal Take First

When new protocols and frameworks come out, I want to answer one question: “What problem does this actually solve?”

This currency converter teaches exactly how MCP works, and that’s worth sharing.

The Learning Goal

Before writing any code, I want you to understand one specific thing:

How does AI actually communicate with external tools through MCP?

What MCP Actually Does

Here’s what I learned by building this:

Without MCP:

You: "Is ¥10,000 enough to buy a $60 game?"
AI: "I don't have access to current exchange rates, 
     but you can check [some website]."

With MCP:

You: "Is ¥10,000 enough to buy a $60 game?"
AI: 
1. Realizes it needs an exchange rate
2. Sees there's a get_exchange_rate tool available
3. Calls: get_exchange_rate(from="JPY", to="USD", amount=10000)
4. Gets: 10000 JPY = 65.83 USD
5. Responds: "Yes, ¥10,000 is approximately $65.83 USD, 
              so you'd have $5.83 left after buying the game."

The key insight: MCP is just a standardized way for AI to discover and use your tools.

The Example Architecture

My simple implementation looks like this:

User sends natural language prompt
Hono API receives it
API gets list of provided MCP server tools (get_exchange_rate)
API Sends prompt + tools to Claude AI
Claude AI interprets when user wants a tool
In the interception step API calls MCP tool, getting the actual rate
API sends another request to Claude AI including actual rate + prompt
User gets their answer It’s basic. And that’s exactly why it’s useful for learning.

Look at the MCP tool definition:

{
  name: "get_exchange_rate",
  description: "Get exchange rate between currencies",
  inputSchema: {
    type: "object",
    properties: {
      from_currency: { type: "string" },
      to_currency: { type: "string" },
      amount: { type: "number", optional: true }
    }
  }
}

This tool just returns exchange rates. That’s it.

The AI takes care of everything else.

Now Let’s take a closer look at the implementation steps together.

1- User sends natural language prompt

"Is ¥10,000 enough to buy a $60 game?"

2- API receives it

app.post('/api/chat')
    const { prompt } = await c.req.json();

3- API gets list of provided MCP server tools (get_exchange_rate)

const tools = await mcpClient.listTools();
4- API Sends prompt + tools to Claude AI

const response = await anthropic.messages.create({
      tools: tools,
      messages: [{
        role: 'user',
        content: prompt
      }]
    });

5- Claude AI interprets When user wants an action that provided in tools get_exchange_rate

while (response.stop_reason === 'tool_use')
   const toolUse = response.content.find(block => block.type === 'tool_use');

6- In the interception step API calls MCP tool, getting the actual rate

const toolResult = await mcpClient.callTool({
        name: toolUse.name,
        arguments: toolUse.input,
      });

7- API sends another request to Claude AI including actual rate + prompt

response = await anthropic.messages.create({
        tools: tools,
        messages: [
          { role: 'user', content: prompt }, // original prompt
          {
            role: 'user',
            content: [{
              type: 'tool_result',
              tool_use_id: toolUse.id,
              content: JSON.stringify(toolResult.content) // rate info
            }]
          }
        ]
      });

8- User gets their answer

    const finalText = response.content
    return finalText 

// Yes, ¥10,000 is approximately $65.83 USD, 
//              so you'd have $5.83 left after buying the game

Why This Simple Example Matters

Here’s what this simple example demonstrates:

1.** Tool Discovery**
The AI can see what tools are available and understand when to use them based on the description.

Parameter Extraction The AI automatically extracts structured parameters from messy natural language:

“Is ¥10,000 enough for $60?” → from="JPY", to="USD", amount=10000
“How many dollars is 50 euros?” → from="EUR", to="USD", amount=50

Context Awareness The AI can handle complex queries:

“I have 5 euros in cash and 20 in my bank, total in USD?”
AI does: 5 + 20 = 25, then calls the tool with 25 EUR

Natural Responses The AI formats the tool’s response naturally instead of just dumping JSON.

See It Working

I recorded a quick demo showing different types of queries being handled:

Press enter or click to view image in full size

Nothing fancy, just the basic flow working as expected.

Setting It Up (For Learning Purposes)

If you want to try this yourself to understand MCP:

git clone https://github.com/hshoja/Currency-Exchange-MCP-Service
npm install
cp env.example .env
# Add your API keys to .env
npm run dev

You’ll need:

Anthropic API key (for Claude AI)
Freecurrencyapi key (for exchange rates)

Then just send POST requests with natural language prompts:

{
  "prompt": "What is 100 USD in EUR?"
}

The Real Takeaway

After building this simple example, We now understand:

MCP is not about building smarter APIs.

It’s about building simple, focused tools and letting AI be the smart layer that connects them to human intent.

Your tool can be dumb. It should be dumb. Just do one thing well, and let AI the rest.

Potential Use Cases (Beyond This Simple Example)

While the currency converter is basic, the pattern scales to more interesting problems, have a look to these examples.

AI Agent Crypto MCP Trading : an example which shows how create an mcp that opens or closes positions in a crypto platform by natural language
Kali Linux HACKING MCP : running kali commands for hacking by natural language
Natural language to SQL: connect and query the database by natural language
Building an agentic appointment scheduling app

The complexity isn’t in MCP itself — it’s in the tools you build and connect.

Check Out The Code

The full repository includes:

Feel free to clone it, modify it, or use it as a reference while learning MCP yourself.

Are you learning MCP too? Have you built simple examples to understand new tech? I’d love to hear about it — drop a comment!

P.S. — If this helped you understand MCP a bit better, give it a like! And remember: simple examples are valid examples.

How simultaneously swapping unique IDs in Postgres

Hamid Shoja — Mon, 08 Dec 2025 18:29:05 +0000

Hi friends

Here's a quick tip for when you're working with Postgres, this came in clutch for me when I had to use DEFERRABLE INITIALLY IMMEDIATE

I'm sharing this with a practical example where two rows in a table must exchange unique values simultaneously within the same transaction. This is common when swapping unique IDs or handling cyclic dependencies.

Example: Swapping Unique Teacher IDs

Consider a classes table where each class has a unique teacher_id, but you need to swap the teachers between two classes. The UNIQUE constraint would normally prevent this in a single UPDATE statement because, mid-operation, there would temporarily be duplicate teacher_id values.

So we can Define the table with a unique constraint that is DEFERRABLE INITIALLY IMMEDIATE:

CREATE TABLE classes (
    id INT PRIMARY KEY,
    teacher_id INT NOT NULL UNIQUE DEFERRABLE INITIALLY IMMEDIATE,
    class_name VARCHAR(100)
);
-- Insert initial data
INSERT INTO classes VALUES (1, 101, 'Biology'), (2, 102, 'Chemistry');

By default, the database checks the uniqueness after every statement.
Perform the swap within a transaction by explicitly deferring the constraint check:

BEGIN;
-- Temporarily set the specific constraint to DEFERRED mode for this transaction
SET CONSTRAINTS classes_teacher_id_key DEFERRED;

-- The update statements can now run without immediate failure
UPDATE classes SET teacher_id = 102 WHERE id = 1; -- Temporarily creates duplicate 102
UPDATE classes SET teacher_id = 101 WHERE id = 2; -- Resolves the duplicate

COMMIT;
-- At the COMMIT point, the database checks all deferred constraints.
-- Since the final state is valid (101 and 102 are unique again), the transaction succeeds.

If you tried these updates without the BEGIN; ... SET CONSTRAINTS DEFERRED; ... COMMIT; block, the first UPDATE statement would immediately fail due to the INITIALLY IMMEDIATE setting, which acts as a per-statement check.

this example demonstrate how to use DEFERRABLE INITIALLY IMMEDIATE constraints to swap unique values within a transaction:

Hope that helped!

Hash

React 19.2's useEffectEvent vs our Custom useEventCallback

Hamid Shoja — Sun, 05 Oct 2025 13:02:20 +0000

Hey fellow React devs! 👋

So React 19.2 dropped and brought us useEffectEvent - a new hook that solves a problem many of us have been tackling with custom solutions. If you're like me and have been using a custom useEventCallback hook (or something similar), you're probably wondering: "Should I ditch my trusty custom hook for this new official one?"

BTW: if you interested to read it from medium.

Let me break it down for you based on some real-world experience.

The Problem Both Hooks Solve

First, let's talk about why these hooks exist. You know that annoying situation where you want to access the latest state/props/reference in a useEffect without adding them to the dependency array? Yeah, that one:

function Page({ url }) {
  const { items } = useContext(ShoppingCartContext);
  const numberOfItems = items.length;

  const onNavigate = useCallback((visitedUrl) => {
    logVisit(visitedUrl, numberOfItems);
  },[numberOfItems]);

  useEffect(() => {
    onNavigate(url);
  }, [url, onNavigate]); // if not passing onNavigate getting lint error

  // ...
}

In this example, the Effect should re-run after a render when url changes (to log the new page visit), but it should not re-run when numberOfItems changes that creates a new ref for onNavigate causing new log for every numberOfItems up and down!

So we need a way to get a persistent ref for onNavigate function including the latest numberOfItems.

Now if you use new hook useEffectEvent instead of useCallback this problem gets solved:

function Page({ url }) {
  const { items } = useContext(ShoppingCartContext);
  const numberOfItems = items.length;

  const onNavigate = useEffectEvent((visitedUrl) => {
    logVisit(visitedUrl, numberOfItems);
  });

  useEffect(() => {
    onNavigate(url);
  }, [url]);

  // ...
}

This problem already gets solved by another hook called useEventCallback by creating stable function reference.

Meet the Custom Champion: useEventCallback

This is what many of us have been building:

export function useEventCallback<T extends (...args: any[]) => any>(fn: T): T {
  const ref = useRef(fn)

  useEffect(() => {
    ref.current = fn
  })

  return useCallback((...args: any[]) => ref.current.apply(void 0, args), []) as T
}

It's reliable, battle-tested, and works everywhere.

CAN We Now Swap Them?

Here's where it gets interesting. These hooks are not drop-in replacements for each other.

useEventCallback instead of useEffectEvent:

Yes you can, the result is almost the same, example:

function Page({ url }) {
  const { items } = useContext(ShoppingCartContext);
  const numberOfItems = items.length;

  const onNavigate = useEventCallback((visitedUrl) => {
    logVisit(visitedUrl, numberOfItems);
  });

  useEffect(() => {
    onNavigate(url);
  }, [url]);

  // ...
}

But there are some caveats:

React's internal magic > our clever hacks, so maybe we're missing some React optimizations
The official API is designed for React's future - You need perfect Concurrent Mode compliance

useEffectEvent instead of useEventCallback:

✅ You CAN use useEffectEvent when you need stable event handlers for Effect deps

// ✅ useEffectEvent works
const handleClick = useEventCallback(() => doSomething());
useEffect(() => { 
  handleClick() 
}, [])

❌ You CANNOT use useEffectEvent when:

1. You need event handlers for JSX

// ✅ useEventCallback works
const handleClick = useEventCallback(() => doSomething());
return <button onClick={handleClick}>Click me</button>;

// ❌ useEffectEvent is NOT for this

2. You're passing callbacks to child components

// ✅ Safe with useEventCallback
const onChildEvent = useEventCallback(handleChildEvent);
return <ChildComponent onEvent={onChildEvent} />;

// ❌ Don't pass useEffectEvent callbacks as props

3. You need async operations

// ✅ useEventCallback handles async fine
const handleAsync = useEventCallback(async (id) => {
  const result = await fetchData(id);
  return result;
});

// ❌ useEffectEvent has restrictions with async

My Take: Use Both (For Now)

Here's my practical recommendation:

Keep using useEventCallback for general stable function references, event handlers, and callback props
Adopt useEffectEvent specifically for functions called within effects

They serve different purposes, even though they solve similar problems.

The Migration Path

If you're on React 19.2+, start migrating effect-specific uses:

// Before
const logEvent = useEventCallback((data) => {
  analytics.track('event', data, currentUser.id);
});

useEffect(() => {
  logEvent(someData);
}, [someData]);

// After
const logEvent = useEffectEvent((data) => {
  analytics.track('event', data, currentUser.id);
});

useEffect(() => {
  logEvent(someData);
}, [someData]);

But keep useEventCallback for everything else!

The Bottom Line

Don't feel bad about your custom hook - it's been doing great work! useEffectEvent isn't here to replace it entirely, but to provide a more specialized, optimized solution for a specific use case.

What's your experience been with these hooks? Are you planning to migrate, or sticking with your custom solutions? Drop a comment - I'd love to hear your thoughts!

7 Essential grep commands for software engineers

Hamid Shoja — Mon, 15 Jul 2024 07:02:52 +0000

I'd like to share a quick review of 7 essential grep commands that every software engineer should know and use in their daily work.

Commands covered:

Recursive search
Display line numbers
Display filenames
Invert match
Multiple Patterns
Context of matching lines
Use regular expressions

Search for a pattern in all files recursively:

grep -r "pattern" /path/to/directory

Display line numbers along with matching lines:

grep -n "pattern" filename

Display only the names of files with matching lines:

grep -l "pattern" *

Invert match (display non-matching lines):

grep -v "pattern" filename

Search for multiple patterns:

grep -e "pattern1" -e "pattern2" filename

Show the context of matching lines (before and after):

grep -C 3 "pattern" filename

Use regular expressions for complex patterns:

grep -E "pattern1|pattern2" filename

Best
HASH

Bumping the Node.js version to higher version

Hamid Shoja — Mon, 01 Jul 2024 14:06:07 +0000

Before bumping the Node.js version to higher version in your package.json, you should consider the following:

Check Node.js Release Schedule:

The Node.js release schedule is available at https://nodejs.org/en/about/releases/. You should use a version that is currently maintained.

Check Dependencies Compatibility:

Ensure that all your dependencies are compatible with the new Node.js version. You can check the engines field in the package.json of your dependencies, or check their documentation.

There are some methods to check this but you also can use this script to check all packages' engine

import fs from 'fs'
import { exec } from 'child_process'
const packageJson = JSON.parse(fs.readFileSync('package.json', 'utf8'))

const allDependencies = { ...packageJson.dependencies, ...packageJson.devDependencies }

for (const dependency in allDependencies) {
  exec(`npm view ${dependency} engines`, (error, stdout, stderr) => {
    if (error) {
      console.error(`exec error: ${error}`)
      return
    }
    console.log(`Engines for ${dependency}: ${stdout}`)
  })
}

Update Your Development Environment:

Make sure that your local development environment is running the same Node.js version. You can use a version manager like nvm to manage multiple Node.js versions on your machine.

Update Your CI/CD Pipeline:

If you have a continuous integration/continuous deployment (CI/CD) pipeline, make sure to update the Node.js version there as well.

Inform Your Team:

If you're working in a team, inform everyone about the Node.js version change so they can update their local environments.

Test Your Application:

After updating the Node.js version, thoroughly test your application to catch any potential issues caused by the version change.

Here's how you can update the Node.js version to 20 in your package.json:

"engines": {
  "node": ">=20"
}

Thank you for taking the time to read the article. I would love to hear your approach and tips on upgrading the node.
HASH

PM2 Cheat Sheet & Process Management Guide

Hamid Shoja — Sun, 21 Jan 2024 21:24:51 +0000

Hello friends,
I've created another cheatsheet, it's for pm2, which is actually my personal notes like the other articles. It could be helpful for you too.

PM2 (Process Manager 2). PM2 is a production process manager for Node.js applications that helps keep your apps alive, simplifies logging, and enables zero-downtime deployments.

🚀 Key Features

Process Management: Easily start, stop, and restart applications.
Cluster Mode: Scale apps across all CPU cores without code changes.
Auto-Restart: Automatically restarts apps on crash or system reboot.
Real-time Monitoring: Track CPU and Memory usage via CLI.
Log Management: Consolidated log streaming and flushing.

I personally utilize it primarily for managing processes and logging, allowing you to start, stop, and automatically restart Node.js processes.

💻 Here's a list of commonly used PM2 commands along with examples:

Starting Applications

Task	Command
Start a basic Node app	`pm2 start app.js`
Start Next.js with a name	`pm2 start npm --name "app-name" -- start`
Start and watch for changes	`pm2 start app.js --watch`

Monitoring & Status

Task	Command
List all processes	`pm2 ls`
Show app details	`pm2 show <app-name>`
Real-time Dashboard	`pm2 monit`
View Logs	`pm2 logs <app-name>`

Managing Life Cycle

Task	Command
Stop a process	`pm2 stop <app-name>`
Restart a process	`pm2 restart <app-name>`
Zero-Downtime Reload	`pm2 reload <app-name>`
Delete from list	`pm2 delete <app-name>`
Clear logs	`pm2 flush <app-name>`

Persistence (Server Reboots)

Task	Command
Save current process list	`pm2 save`
Generate startup script	`pm2 startup`

These commands should cover most of the common tasks you need to perform when working with PM2. For more detailed information, you can always refer to the official PM2 documentation.

📺 Deployment Tutorials

If you're deploying a Next.js site from scratch on Ubuntu with NGINX, these guides are highly recommended:

🔗 References

Official PM2 Documentation

Key differences between GraphQL and RESTful API

Hamid Shoja — Thu, 09 Nov 2023 20:42:28 +0000

GraphQL and RESTful API are two popular approaches for building APIs, but they have distinct differences in architecture, data fetching, development speed, metadata and validation, and API endpoints.

The main key differences between GraphQL and RESTful API are as follows:

Architecture:

GraphQL: GraphQL is an application layer server-side technology that is used for executing queries with existing data. It follows a client-driven architecture.
RESTful API: REST (Representational State Transfer) is a software architectural style that defines a set of constraints for creating web services. It follows a server-driven architecture.

Data Fetching:

GraphQL: With GraphQL, the client can specify exactly the data it needs in a query, and the server responds with a JSON object that fulfills those requirements. This eliminates overfetching and underfetching of data.
RESTful API: In RESTful API, the client needs to access multiple endpoints to gather the required data. This can lead to overfetching, as the endpoints may return additional information that is not needed.

Development Speed:

GraphQL: The development speed in GraphQL is generally faster compared to RESTful API, as it provides a declarative way of fetching and updating data.
RESTful API: The development speed in RESTful API is slower compared to GraphQL, as it requires creating new APIs for different data requirements.

Metadata and Validation:

GraphQL: GraphQL uses metadata for query validation, which helps in ensuring the correctness of queries.
RESTful API: RESTful API does not have machine-readable metadata cacheable, and query validation is not available.(There are some libraraies tried to solve this issue like TRPC)

API Endpoints:

GraphQL: GraphQL API endpoints are single, and the server determines the available resources.
RESTful API: RESTful API endpoints are multiple, and the shape and size of the resource are determined by the server.

Is there anything else you would like to include?

Best
Hash

Visual Regression testing with Playwright

Hamid Shoja — Fri, 06 Oct 2023 15:02:51 +0000

Visual Regression Testing is a software testing technique used to identify and prevent unintended visual changes in a web application or user interface (UI). It helps ensure that the visual appearance of a website or application remains consistent across different versions or updates.

How Visual Regression Testing typically works ?

capturing a baseline or reference screenshot of the UI (expected)
take second screenshot after changes to the code
testing pixel by pixel or at higher level (based on tools)
visual diff and report

What Visual Regression Testing is valuable for:

visual consistency
cross-browser and cross-device testing
automated testing

Which tool can be used for:

Applitools Eyes:
Popularity: High
Year of Introduction: 2014
Percy:
Popularity: High
Year of Introduction: 2015
Cypress with Cypress Image Snapshot:
Popularity: High
Year of Introduction: Cypress Image Snapshot is a plugin for Cypress.
Selenium with WebdriverIO:
Popularity: High
Year of Introduction: Selenium is older (introduced in 2004), WebDriverCSS and WebdriverIO are plugins/extensions.
Playwright with Playwright Test Runner:
Popularity: Growing
Year of Introduction: Playwright introduced in 2019; Playwright Test Runner is a testing framework built on top.

An Visual Regression testing with React and Playwright

Install Playwright and other necessary dependencies:

npm install playwright

Create a Visual Regression Testing script using Playwright and Jest. For this example, let's assume you want to test a simple React component.

Create a test file, e.g., visual-regression.test.js, with the following content:

import { test, expect } from'@playwright/test';

test('Visual Regression Test', async ({ page }) => {
  // Navigate to your React application or component
  await page.goto('http://localhost:3000'); // Change the URL as needed

  // Capture a screenshot of the React component
  const screenshot = await page.screenshot();

  // Compare the screenshot with the baseline image
  expect(screenshot).toMatchSnapshot('react-component-screenshot.png');
});

run the jest by npm run test

Jest will execute the test script, and Playwright will launch a browser, capture a screenshot, and compare it to the baseline image. If there are any visual differences, Jest will report them.

After running the test, Jest will generate a folder named image_snapshots containing the baseline and compared images. You can review and approve any changes as needed.

Remember to replace the URL and adjust the test script to match your specific React component or application. This example demonstrates a basic setup for Visual Regression Testing with Playwright and React, and you can expand upon it to suit your project's needs.

if you would like to watch a video, there is another example: https://www.youtube.com/watch?v=Y1eTK-j66PU

Thank you for taking the time to read the article. let me know in the comments your approach to visual regression testing?

HASH

A Comparative Overview of Leading Web Servers: Nginx, Apache, LiteSpeed, and More

Hamid Shoja — Sun, 01 Oct 2023 08:35:06 +0000

In the ever-evolving landscape of web hosting and server technologies, picking the right web server can feel like choosing the perfect coffee blend—overwhelming at first, but crucial for your daily grind. Whether you're a seasoned sysadmin, a web developer, or just dipping your toes into the world of web hosting, this guide will help you navigate the options and find the ideal match for your projects.

🚀 Popular Web Servers at a Glance

Nginx

Creator: Igor Sysoev
Language: C
Popularity: High
Notable Modules: ngx_http_ssl_module (SSL/TLS support), ngx_http_proxy_module (HTTP proxy), ngx_http_fastcgi_module (FastCGI support)
Year Introduced: 2004
Famous Users: Airbnb, Dropbox, Netflix, WordPress.com

Apache HTTP Server (Apache)

Creator: Apache Software Foundation
Language: C
Popularity: High
Notable Modules: mod_ssl (SSL/TLS support), mod_rewrite (URL rewriting), mod_proxy (reverse proxy)
Year Introduced: 1995
Famous Users: Apple, IBM, Cisco

HAProxy

Creator: Willy Tarreau
Language: C
Popularity: Medium
Notable Modules: N/A (primarily a load balancer and proxy)
Year Introduced: 2001
Famous Users: GitHub, Stack Overflow, Imgur

Caddy

Creator: Matt Holt
Language: Go
Popularity: Medium
Notable Modules: tls.dns.cloudflare (DNS challenge provider for Let's Encrypt), http.expires (HTTP caching), http.proxy (HTTP proxy)
Year Introduced: 2015 (Caddy 1.0), 2020 (Caddy 2.0)
Famous Users: Segment, Atlassian, HashiCorp

Traefik

Creator: Containous
Language: Go
Popularity: Medium
Notable Modules: acme (Let's Encrypt certificate automation), traefik-forward-auth (authentication middleware), consul (Service discovery)
Year Introduced: 2014
Famous Users: SendGrid, Nokia, Ubisoft

Envoy

Creator: Lyft
Language: C++
Popularity: Medium
Notable Modules: N/A (primarily a proxy)
Year Introduced: 2016
Famous Users: Airbnb, Pinterest, eBay

Tomcat

Creator: Apache Software Foundation
Language: Java
Popularity: Medium
Notable Modules: N/A (primarily a servlet container)
Year Introduced: 1999
Famous Users: eBay, Adobe, LinkedIn

💡 Tips for Choosing a Web Server

Performance Matters: Nginx and Apache are known for their high performance, but Nginx often edges out Apache in handling concurrent connections. If speed is your priority, Nginx might be your go-to.
Ease of Use: Caddy and Traefik are praised for their simplicity and automatic HTTPS setup. If you're looking for a hassle-free experience, these are worth considering.
Scalability: HAProxy and Envoy are excellent choices for load balancing and microservices architectures. They shine in environments where scalability is key.
Community Support: Apache and Nginx have large, active communities, making it easier to find help and resources. If community support is important, these are solid picks.
Security: All servers offer robust security features, but Nginx and Apache are particularly well-regarded for their security modules. Always keep your server updated and follow best practices.

Last word!

Choosing the right web server is a blend of understanding your project's needs, evaluating performance, and considering ease of use.

Thanks for reading!

Hash!

References: