DEV Community: Raj Maharjan

So I Finally Tried to Understand Kubernetes

Raj Maharjan — Wed, 01 Apr 2026 05:38:00 +0000

Okay, so a few days ago I sat down and told myself — today I will finally understand Kubernetes. Not just know the name, not just say "yes, yes, K8s" in a meeting and nod. Actually understand it.

I had been using Docker for a while. Build an image, run a container, push to a registry. That part I knew. But then people kept asking things like — "how do you handle scaling?" or "what happens when a container dies?" And I would just smile and say "hmm, good point."

So I started reading, set up a small cluster on my laptop, and spent a few hours just playing around. Here is what I learned, told the way I wish someone had told me.

The Problem Docker Doesn't Solve

Docker gives you a nice box to put your app in. You know how it works, you know what's inside, you can run it anywhere. Wonderful.

But the moment you move from your single laptop to actual servers — or even to a few containers talking to each other — questions start piling up:

Where do these containers actually run? What happens when one dies at 3am? How do they find each other on the network? How do I run three copies of the same service?

Kubernetes is basically the answer to all of those questions at once. It is an open-source platform that runs your containers, watches over them, restarts them when they die, and lets them talk to each other. You just tell it what you want, and it figures out the how.

Think of it as an operating system — but for your whole data center instead of one machine.

The Words You Need to Know

Before anything makes sense, there are a few terms. I was scared of these at first because they sound very technical. But they are actually simple ideas with fancy names.

Term	What it means
Cluster	All the machines working together as one system — your "data center."
Node	A single machine (real or virtual) inside the cluster that actually runs your apps.
Pod	The smallest thing K8s manages. Usually one container. Treat it as temporary — it can die anytime.
Deployment	Says "I want 3 copies of this pod always running." Handles restarts and updates for you.
Service	A stable address for your pods. Even if pods come and go, the Service address stays the same.
Namespace	A folder inside your cluster. Useful for keeping dev, staging, prod separate.

The Restaurant That Made It Click

I read a lot of explanations. The one that finally made sense to me was a restaurant comparison. Let me tell it my own way.

Imagine a restaurant. The whole restaurant is your Cluster. The manager sitting in the back — who decides which cook does what, who watches the orders, who keeps track of everything — that is the Control Plane. The actual cooking stations (grill, prep, fryer) are the Nodes. Each dish being cooked right now is a Pod.

Now here is the interesting part. When you order a "Chicken Burger" from the menu, you don't say "I want Chef Ramesh specifically to make it." You just say Chicken Burger. The menu item is always there, even if a cook leaves and a new one joins.

That menu item is the Service. It gives you a stable name to call, and it figures out which pod (cook) to send the work to. Even when pods die and new ones come up, the Service name stays the same.

Important: Never talk to a Pod directly by its IP address. Pods are temporary — their IP can change or disappear. Always use a Service as the stable middleman.

How Traffic Actually Flows

┌─────────────────────────────────────────────────────┐
│                     CLUSTER                         │
│  ┌──────────────┐     ┌───────────────────────────┐ │
│  │ Control Plane│────▶│       Worker Nodes        │ │
│  │ scheduler    │     │  ┌─────┐ ┌─────┐ ┌─────┐  │ │
│  │ etcd         │     │  │ Pod │ │ Pod │ │ Pod │  │ │
│  │ controllers  │     │  └─────┘ └─────┘ └─────┘  │ │
│  └──────────────┘     └───────────────────────────┘ │
└─────────────────────────────────────────────────────┘

Client ──▶ Service ──▶ Pod(s) ──▶ Container(s)

Your request starts from outside, hits a Service, and the Service decides which Pod handles it. You never call a Pod's IP directly.

kubectl — The Remote Control

To talk to your cluster, you use a command-line tool called kubectl. Think of it as a remote control. You press buttons, and the cluster does things.

One thing that confused me early: kubectl cannot create a cluster. It can only talk to one that already exists. This is like — the TV remote can change channels, but it cannot build the TV.

To create a cluster on your laptop for learning, you use a separate tool. The two most popular ones are kind and minikube.

Tool	What it does	Best for
`kind`	Runs K8s nodes as Docker containers. Very light.	Quick setup, CI, already using Docker
`minikube`	Spins up a local VM or Docker cluster with extra addons.	Built-in dashboard, more feature-rich for learning

I used kind because it was the easiest to start. One command and you have a working cluster:

# Create a cluster named k8-learning
kind create cluster --name k8-learning

# Check what's in it
kubectl get nodes
kubectl get pods

When I ran kubectl get nodes, I saw only one node called k8-learning-control-plane. I panicked a little — "where are the other nodes?" But this is normal. With kind's default setup, you get one node that does everything. Fine for learning.

Writing My First Pod

A Pod is just a YAML file describing what you want to run. Here is the simplest possible one:

apiVersion: v1
kind: Pod
metadata:
  name: hello-pod
  namespace: default
spec:
  containers:
    - name: app
      image: nginx:stable

Apply it and check on it:

kubectl apply -f pod.yaml
kubectl get pods
kubectl get pods -o wide

A few seconds later, your nginx container is running inside the cluster.

The Namespace Trap: I kept running kubectl get pods and seeing nothing, even after creating pods. The reason was namespaces. If you create something in a namespace called production and forget to add -n production to your command, K8s will look in the wrong place. Always specify the namespace.

Don't Use Bare Pods. Use Deployments.

Here is a mistake I almost made. I was creating bare Pods and thinking "okay, I'm done." But bare Pods are not safe for real apps.

If a bare Pod dies, it just... stays dead. Nothing brings it back. You have to do it manually. That is terrible for any real service.

A Deployment is the right way. You tell it "I want 3 copies of this pod always running." If one dies, the Deployment notices and starts a new one. If you want to update the image, it does a rolling update — takes down the old ones slowly, brings up new ones, no downtime.

Bare Pods are for quick tests. Deployments are for anything you actually care about.

Mistakes I (Almost) Made

❌ Treating Pods like permanent things. They are not. They die, they get restarted, their IP changes. Never rely on a Pod being there.
❌ Calling Pod IPs directly. Pod IPs are temporary. Use a Service as a stable address. Always.
❌ Forgetting -n for namespaces. "Why can't I see my pod?!" — because you're looking in the wrong namespace.
❌ Putting too many containers in one Pod. One main container per Pod is the rule. Only combine containers if they truly need to share memory or files — like an app and a logging sidecar.
❌ Thinking kubectl creates clusters. It doesn't. kind or minikube create the cluster. kubectl just talks to it.

Want to Try It Yourself?

1. Install the tools
On macOS: brew install kubectl and brew install kind. On Linux, follow the official docs — both have simple install scripts.

2. Create a cluster

kind create cluster --name k8-learning

Wait a minute. You now have a working Kubernetes cluster on your laptop.

3. Explore it

kubectl cluster-info
kubectl get nodes
kubectl get nodes -o wide
kubectl get pods

4. Run a pod

kubectl run nginx --image=nginx:stable --restart=Never
kubectl get pods -o wide

5. Clean up

kind delete cluster --name k8-learning

Everything gone, laptop happy.

What's Next

This was my first real day with Kubernetes. I went from "I know the name" to "I can actually run things and understand what is happening." That felt good.

The next things I want to learn: how Deployments handle rolling updates, how Services work in different modes (ClusterIP, NodePort, LoadBalancer), and eventually how to set up something close to a real production setup.

If you are a backend developer and you have been putting off learning this — don't. It is not as scary as it looks from outside. Set up kind, run a pod, break something, fix it. That is how it clicks.

Thank you for reading. 🙏

A small note: This is the beginning of a series where I write about things as I learn them — no expert voice, no pretending I know everything. Just a developer figuring things out and writing it down. Kubernetes is the current chapter. More blogs covering what I learn next will be coming soon — Deployments, Services, real configs, and whatever breaks along the way. Follow along if you are on a similar journey. 🚀

How I Used Next.js as Both the Frontend AND the Backend for My Microservices

Raj Maharjan — Wed, 25 Mar 2026 05:07:58 +0000

We are building a fintech product. The backend is a set of microservices — each service does one job, like handling payments, managing users, or dealing with authentication.

For the frontend, we chose Next.js.

But here is the interesting part: Next.js ended up doing two jobs in our architecture.

It renders the UI that the user sees — pages, components, everything visual.
It also acts as a Backend for Frontend (BFF) — a server layer that sits between the browser and our real microservices.

One Next.js project. Two responsibilities. This is the story of why I made that call, what it gave us, and what it cost us.

What Does "Next.js as BFF" Actually Mean?

Next.js is not just a frontend framework. It also lets you write API routes — real server-side code that runs on a Node.js server, not in the browser.

So our Next.js project has two parts living side by side:

/app
  /dashboard        ← React pages (frontend)
  /profile          ← React pages (frontend)

/app/api
  /auth             ← API route (BFF — calls Auth microservice)
  /payments         ← API route (BFF — calls Payments microservice)
  /dashboard        ← API route (BFF — combines data from 3 services)

The browser loads the React pages from Next.js. When those pages need data, they call the Next.js API routes — not the microservices directly. The API routes then talk to the real microservices behind the scenes.

Browser
  ↓  (loads page)
Next.js — React pages (frontend)
  ↓  (fetches data from)
Next.js — API routes (BFF)
  ↓  (calls)
Microservices (Auth / Payments / Users)

The browser never knows the microservices exist. It only ever talks to Next.js.

Why I Made This Decision

1. Security — Tokens Stay Out of the Browser

When a user logs in, the real Auth microservice gives back an access token. The normal thing to do is pass this token to the browser and store it in localStorage or memory.

But this is risky. If there is any XSS attack — malicious JavaScript running on your page — that token can be stolen and used to impersonate the user. In a fintech app, that is a serious problem.

Because Next.js API routes run on the server, they can handle the token before it ever reaches the browser. Here is the flow:

Browser sends login details to the Next.js API route (/api/auth/login)
The API route calls the real Auth microservice and gets the access token
The API route converts that token into a secure, HTTP-only cookie
The browser receives the cookie — it never sees the raw token

HTTP-only cookies cannot be read by JavaScript at all. Even if an attacker runs code in the browser, they cannot steal the token because the browser never had it.

// /app/api/auth/login/route.ts
export async function POST(req: Request) {
  const { email, password } = await req.json();

  // Call the real microservice
  const { accessToken } = await authService.login(email, password);

  // Convert to cookie — browser never sees the token
  const response = NextResponse.json({ success: true });
  response.cookies.set('session', accessToken, {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'strict',
    path: '/',
  });

  return response;
}

This was the single biggest reason for the whole decision. Security first.

2. Dynamic Ads for External Websites

Our product shows custom ads on third-party websites. These ads are not static images — they need real-time data from our APIs to decide what to show to which user.

The problem: a third-party website cannot call our internal microservices directly. That would expose internal URLs, create CORS headaches, and open security holes.

With the Next.js BFF, the external website just calls a public-facing Next.js API route. That route handles all the internal API calls server-side and returns a clean response. The microservices stay completely hidden.

// /app/api/ads/route.ts — called by external websites
export async function GET(req: Request) {
  const userId = getUserFromCookie(req);

  // Internal calls — the external world never sees these
  const adData = await adsService.getPersonalizedAd(userId);

  return Response.json(adData);
}

No exposed microservice URLs. No CORS issues. The outside world only knows about Next.js.

3. Combining Multiple Services Into One Response

The dashboard page needs data from three different services — user profile, account balance, and recent transactions.

Without BFF — the browser makes 3 separate calls:

Browser → GET /users/me
Browser → GET /payments/balance
Browser → GET /transactions/recent

Three round trips. Slow. And the browser has to combine all the data itself.

With BFF — the browser makes 1 call to the Next.js API route, which calls all three services in parallel:

// /app/api/dashboard/route.ts
export async function GET(req: Request) {
  const [user, balance, transactions] = await Promise.all([
    userService.getMe(),
    paymentsService.getBalance(),
    transactionService.getRecent(),
  ]);

  return Response.json({ user, balance, transactions });
}

One call from the browser. One clean response. The browser does not care how many microservices were involved.

The Difficulties

This is where I have to be honest. This decision was not free.

Double Integration — The Biggest Pain

Because Next.js is doing two jobs, every API endpoint has to be written twice:

Once in the real microservice
Once as a Next.js API route that proxies or transforms the microservice call

If the backend has 20 endpoints, I have to write 20 Next.js API routes too. Some of them are almost identical to the microservice they are calling.

Microservice:  POST /auth/login   → returns { accessToken }
Next.js route: POST /api/auth/login → calls microservice, sets cookie

This feels like redundancy — and it is. You are doing the integration work twice. This is the main trade-off of using your frontend framework as a BFF at the same time.

Next.js Becomes a Critical Point of Failure

Before this architecture:

Browser → Microservice

After this architecture:

Browser → Next.js → Microservice

If Next.js goes down, everything stops — the UI and the API layer both die at the same time. Before, a frontend bug would only break the UI. Now a Next.js server crash breaks the whole product.

This means the Next.js deployment needs to be treated with the same care as a backend service — proper monitoring, health checks, and failover.

Keeping the Two Layers in Sync

When a microservice changes its API — a new field, a renamed key, a different response structure — the Next.js layer also needs to be updated. This could easily become a mess, but we have a clear process that keeps things manageable.

Here is how it works in practice:

The backend team updates their microservice and gives me updated Swagger or Postman documentation showing what changed.
I update the Next.js API route (the BFF layer) to match the new microservice contract.
I update the frontend — the React pages and components — to use the new data.

Steps 2 and 3 sound like extra work, but here is where having Next.js handle both roles actually helps: because the API routes and the React pages live in the same project, I can define a shared TypeScript interface for the response once and use it in both places.

// types/dashboard.ts — defined once, used everywhere in the same project
export interface DashboardResponse {
  user: { id: string; name: string };
  balance: number;
  transactions: Transaction[];
}

// /app/api/dashboard/route.ts — BFF layer uses it
import { DashboardResponse } from '@/types/dashboard';

// /app/dashboard/page.tsx — frontend also uses the same type
import { DashboardResponse } from '@/types/dashboard';

If the microservice changes and I update the interface, TypeScript immediately shows me every place in the frontend that is now broken. I do not have to search manually — the compiler tells me exactly what to fix.

So yes, there is still sync work to do whenever the backend team ships a change. But the tight loop between the BFF routes and the UI — all in one project, all sharing types — makes that sync much faster than if they were separate codebases.

"Wait, Is This Frontend or Backend?"

New developers joining the project often get confused at first. They see API routes inside a Next.js project and are not sure what the boundary is.

"Why is there auth logic in the frontend project?"
"Should I add new business logic here or in the microservice?"

These questions are completely valid. The answer needs to be written down clearly — the Next.js API routes are the BFF layer, not a second backend. They handle session management, data aggregation, and the public API surface. Business logic lives in the microservices.

Without clear documentation, this confusion slows down new team members.

What I Learned From My First Architecture Decision

This was the first time I made a real architectural call on a production product. Here is what I took away.

Next.js is genuinely good at this dual role. It was designed to run server-side code. API routes are first-class citizens. Using them as a BFF is not a hack — it is a well-supported pattern.

The security benefit is real and hard to get another way. The token-to-cookie conversion needs a server. If you are using Next.js for the frontend anyway, using its API routes for this is practical and keeps your stack simple.

The redundancy is the real cost. Every time I add a new microservice endpoint, I feel the double integration work. It is not a one-time pain. It is ongoing.

Document the "why", not just the "what". The code shows what the system does. Only documentation explains why Next.js is doing API work at all. Without that, every new developer has to rediscover the reasoning.

There is no perfect architecture. Every decision trades one problem for another. This decision traded simplicity for security and cleaner data access. Knowing that trade-off clearly — instead of just copying a pattern from a blog post — is what made it feel like a real decision.

Would I Do It Again?

Yes — for this project.

The security layer was non-negotiable for a fintech product. The dynamic ads feature needed a server in the middle. And combining multiple API calls into one response has kept the React components much simpler.

But if I was starting a small personal project? I would not add this complexity. The double integration work is a real ongoing cost, and it only makes sense when the benefits — security, abstraction, external API surface — actually justify it.

Have you used Next.js as both the frontend and the BFF in the same project? I would love to know how you handled the double integration problem — did you auto-generate the routes, or did you draw a strict line somewhere about what logic belongs where? Drop it in the comments.

Building Maintainable Backends with Port-Adapter Architecture in NestJS

Raj Maharjan — Thu, 15 Jan 2026 05:30:27 +0000

TL;DR

Port-Adapter Architecture helps keep business logic separate from infrastructure like databases and external services, making your NestJS app easier to test and change. Use it only where flexibility matters, not everywhere.

Introduction

When we start backend development, most of us write code like this:

Controller calls Service
Service directly talks to Database
Service also calls email, SMS, payment, etc.

This works fine at the beginning. But as the project grows, things slowly become messy. One small change breaks many places. Testing becomes hard. New developers feel lost.

This is where Port-Adapter Architecture (also known as Hexagonal Architecture) helps. It is not magic and not mandatory everywhere, but when used correctly, it makes backend code clean, understandable, and future-proof.

In this article, we will understand:

What Port-Adapter Architecture really is (in simple words)
Why and when to use it
How it compares to other approaches
A clear folder structure
When NOT to use ports

What Problem Are We Actually Solving?

Imagine this service code:

// ProductService
await this.productModel.create(data);
await axios.post("email-service/send");
await redis.set(key, value);

Problems here:

Database logic inside service
External API logic inside service
Hard to test
Hard to replace MongoDB or email provider
Too many responsibilities in one place

This creates tight coupling. Tight coupling makes future changes painful.

What is Port-Adapter Architecture (Hexagonal Architecture)?

Port-Adapter Architecture separates thinking from doing.

Port = What the application needs (interface)
Adapter = How it is actually done (real implementation)

Example:

"I need to save a product" → Port
"I save it using MongoDB" → Adapter

If tomorrow you want PostgreSQL, you only change the adapter. Business logic stays the same.

Why Port-Adapter vs Other Common Approaches?

1. Traditional Service → Repository (No Ports)

Controller → Service → Repository

This approach is completely fine for:

Small applications
MVPs
Side projects

But it becomes a problem when:

Service depends on many external systems
Testing requires mocking many things
You want to replace implementations

2. Clean Architecture

Clean Architecture is powerful, but:

Too many layers
Too much boilerplate
Hard for beginners
Slower development for small teams

3. Why Port-Adapter is a Good Balance

Port-Adapter gives:

Clear boundaries
Less coupling
Easier testing
Flexibility

Without being too complex or academic.

Important Rule: Ports Are NOT Required for Everything

This is very important.

Do NOT create ports for:

Simple CRUD repositories
Internal helper services
Utility functions
Logic that will never change

Use ports for:

External services (email, SMS, payment)
Cross-module dependencies
Business-critical operations
Things that may change in the future

Architecture should reduce complexity, not increase it.

Beginner-Friendly Folder Structure

src/
│
├── product/
│   ├── controllers/
│   │   └── product.controller.ts
│   │
│   ├── services/
│   │   └── product.service.ts
│   │
│   ├── ports/
│   │   └── product.port.ts
│   │
│   ├── repositories/
│   │   └── product.repository.ts
│   │
│   ├── dto/
│   │   ├── create-product.dto.ts
│   │   └── update-product.dto.ts
│   │
│   ├── schemas/
│   │   └── product.schema.ts
│   │
│   ├── product.tokens.ts
│   └── product.module.ts
│
├── inventory/
│   ├── ports/
│   ├── services/
│   └── inventory.module.ts
│
├── notification/
│   ├── ports/
│   ├── services/
│   └── notification.module.ts
│
└── common/
    ├── base/
    ├── utils/
    └── constants/

Why This Structure Works

Easy for new developers to understand
Clear separation of responsibilities
Business logic is easy to find
Infrastructure code is isolated

Where Ports Make the Most Sense

A very common and practical example is payment or transaction handling.

Imagine your application needs to process payments. Today you might use Stripe, but tomorrow the business may ask to support another payment partner like Khalti, Esewa, or any other gateway.

If you directly write Stripe code inside your service, changing the payment provider later will be painful and risky.

This is where a port makes perfect sense.

Payment Port Example

// payment.port.ts
export interface PaymentPort {
  charge(
    amount: number,
    currency: string,
    source: string
  ): Promise<PaymentResult>;
}

Stripe Adapter

@Injectable()
export class StripePaymentAdapter implements PaymentPort {
  async charge(amount: number, currency: string, source: string) {
    // Stripe-specific implementation
  }
}

Another Payment Adapter (Future)

@Injectable()
export class EsewaPaymentAdapter implements PaymentPort {
  async charge(amount: number, currency: string, source: string) {
    // Esewa-specific implementation
  }
}

Service Using the Port

constructor(
  @Inject(PAYMENT_SERVICE)
  private readonly paymentService: PaymentPort,
) {}

Now your business logic does not care whether the payment is done by Stripe, Esewa, or any other provider. You can switch implementations from the module without touching the service code.

This is an ideal and real-world use case for Port-Adapter Architecture.

When You Should Avoid Ports

If your code is:

await this.userRepository.findById(id);

And:

Repository is local
No external dependency
No plan to replace it

Then do not create a port. Keep it simple.

Simple Mental Model

Before creating a port, ask:

"Will I ever want to replace or mock this?"

Yes → Use a port
No → Do not use a port

Conclusion

Port-Adapter Architecture is a tool, not a rule.

Use it when:

Project is growing
Multiple developers are working together
Business logic is important
Testing matters

Avoid it when:

Application is small
Logic is simple
Abstraction adds confusion

In NestJS, this pattern fits naturally and helps keep code clean without becoming too complex. Start small and apply it only where it makes sense.

GIL in Python: What is it and Why Does it Matter?

Raj Maharjan — Fri, 23 May 2025 19:18:51 +0000

The Global Interpreter Lock (GIL) is a lock that makes sure only one thread runs Python code at a time. It helps prevent problems when Python works with memory, but it also means Python can't fully use multiple cores of a CPU at once.

What is the GIL?

The GIL is a lock used by Python to ensure that only one thread can run Python code at a time. This is necessary because Python’s memory management isn’t safe for multiple threads to access at once.

Why Does the GIL Exist?

The GIL exists to prevent issues with memory when multiple threads try to access Python objects at the same time. Python's memory management system isn't built for multi-threading, so the GIL makes sure it’s safe to use.

Reference Counting and Garbage Collection

In Python, memory is managed by two things: reference counting and garbage collection. These methods work together to automatically clean up unused objects and free up memory.

Reference Counting

Every object in Python has a reference count that tracks how many references point to it. When no one is using an object (i.e., its reference count becomes zero), Python automatically removes it from memory.

Example of Reference Counting

Step	Code	Description	Reference Count
Create an object	a = [1, 2, 3]	A new list object is created and assigned to a.	1
Assign to another variable	b = a	The reference count increases because b now points to the same list object as a.	2
Delete one reference	del a	Deleting a decreases the reference count, leaving only b pointing to the list.	1
Delete the last reference	del b	Both references are deleted, and the list object is deallocated.	0 (deallocated)

import sys

a = [1, 2, 3]  # Create a list object
print(sys.getrefcount(a))  # Output: 2 (one reference by 'a', another by getrefcount)

b = a  # Assign to another variable
print(sys.getrefcount(a))  # Output: 3 (now referenced by 'a', 'b', and getrefcount)

del a  # Remove one reference
print(sys.getrefcount(b))  # Output: 2 (now only referenced by 'b' and getrefcount)

This example shows how the reference count changes when we create and delete references to an object. Once there are no references left, Python removes the object from memory.

Garbage Collection

Reference counting works well, but it can’t handle cyclic references. This happens when objects reference each other in a loop, and the reference count never reaches zero. To deal with this, Python has a garbage collector that looks for these loops and frees the memory.

How It Works

When the garbage collector finds cyclic references, it removes them from memory.
The gc module allows you to control and work with garbage collection in Python.

import gc

class Node:
    def __init__(self, value):
        self.value = value
        self.next = None

node1 = Node(1)
node2 = Node(2)
node1.next = node2
node2.next = node1  # Creates a cycle

# Even if 'node1' and 'node2' are deleted, they will not be freed immediately
# because their reference counts never drop to zero.
del node1
del node2

# Manually run the garbage collector
gc.collect()  # Forces garbage collection to clean up cyclic references

In this example, even though we delete node1 and node2, the cycle between them stops their reference count from reaching zero. The garbage collector clears them when we run gc.collect().

Real World Analogy

Imagine a busy kitchen with several chefs (threads) and many cooking stations (CPU cores). The kitchen has enough space for many chefs to work at once, but there is a rule: only one chef can use the recipe book (the Python interpreter) at a time.

Here’s how it works:

Chef 1 starts cooking and picks up the recipe book.
The other chefs have to wait, even if stations are free, because only one chef can use the recipe book at a time.
Once Chef 1 finishes, they put the recipe book down for the next chef to use.
This cycle continues, making sure no two chefs are working at the same time, even though the kitchen could handle more.
This "one chef at a time" rule is like Python’s GIL. It makes things safe but doesn’t use resources fully, especially for tasks that need a lot of processing power.

Why is the GIL a Problem?

The GIL can slow down programs that need a lot of CPU power or use multiple threads. It stops Python from using multiple CPU cores at once, which can hurt performance on multi-core processors.

Example

import threading
import time

def task(name):
    for i in range(5):
        print(f"{name} is working on step {i + 1}")
        time.sleep(0.1)  # Simulate work

# Create two threads
thread1 = threading.Thread(target=task, args=("Chef 1",))
thread2 = threading.Thread(target=task, args=("Chef 2",))

# Start the threads
thread1.start()
thread2.start()

# Wait for threads to finish
thread1.join()
thread2.join()

Output

Chef 1 is working on step 1
Chef 2 is working on step 1
Chef 1 is working on step 2
Chef 2 is working on step 2

How Can I Avoid the GIL?

There are a few ways to avoid the GIL’s limitations:

Use multi-processing instead of multi-threading. -Use a Python version that doesn’t have the GIL, like Jython or PyPy. But keep in mind that these don’t support popular libraries like numpy and pandas.

What is the Future of the GIL?

As of PEP703, the GIL may become optional in the future, or even removed. But for now, if you want to avoid GIL issues, it’s best to use multi-processing or consider Python implementations that don’t use the GIL.

What is the Impact of the GIL on My Program?

The GIL affects your program depending on what you are doing. If your program does a lot of CPU-heavy work, like rendering games or running calculations, the GIL can slow it down. On the other hand, if your program does a lot of I/O work, like database queries or loading files, the GIL will have less impact.

In libraries like numpy and pandas, the GIL is not an issue because they are written in C/C++ and don’t rely on Python’s memory management.

What are Some Alternatives to the GIL?

Some alternatives to the GIL include:

PyPy
jython

Handling WebSockets in React Native with Socket.IO

Raj Maharjan — Fri, 23 May 2025 07:39:27 +0000

WebSockets are essential for creating interactive, real-time apps, but using them in a mobile setting like React Native presents difficulties due to poor internet, disconnected connections, and retries.

What is socket.io?

Socket.IO is a library that enables low-latency, bidirectional and event-based communication between a client and a server. Socket.IO manages events, retries, and connection management, making WebSocket implementation easier. It is an great option for guaranteeing good event delivery as it also supports acknowledgements.

1. Setting Up the Project

Install Dependencies

First, create a React Native project and install the required dependencies:

npx @react-native-community/cli@latest init SocketIOExample
cd SocketIOExample
npm install socket.io-client

2. Creating the Socket Context

To make the socket instance globally accessible, we’ll use a React Context.

SocketContext.tsx

import React, {createContext, useContext, useEffect, useRef} from 'react';

import {AppState} from 'react-native';
import {io, Socket} from 'socket.io-client';

// Define the context type
interface Message {
  id: string;
  text: string;
}

interface SocketContextType {
  socket: Socket | null;
  isConnected: boolean;
  messages: Message[];
  setMessage: React.Dispatch<React.SetStateAction<Message[]>>;
}

const SocketContext = createContext<SocketContextType | undefined>(undefined);

export const SocketProvider: React.FC<{children: React.ReactNode}> = ({
  children,
}) => {
  const socketRef = useRef<Socket | null>(null);
  const [isConnected, setIsConnected] = React.useState(false);
  const [message, setMessage] = React.useState<Message[]>([]);

  useEffect(() => {
    socketRef.current = io('http://localhost:3000', {
      reconnection: true, // Enable automatic reconnection
      reconnectionAttempts: Infinity, // Number of reconnection attempts
      reconnectionDelay: 1000, // Initial delay between reconnection attempts (ms)
      reconnectionDelayMax: 10000, // Maximum delay between reconnection attempts (ms)
      timeout: 10000, // Connection timeout (ms)
      autoConnect: true, // Automatically connect to the server when the component mounts
      forceNew: false, // Do not force a new connection on each connection attempt
    });

    const socket = socketRef.current;

    const handleAppStateChange = (nextAppState: string) => {
      if (nextAppState === 'active') {
        socket?.connect();
      } else if (nextAppState === 'background') {
        socket?.disconnect();
      }
    };

    const appStateSubscription = AppState.addEventListener(
      'change',
      handleAppStateChange,
    );

    socket.on('connect', () => {
      console.log('Connected to server');
      setIsConnected(true);
    });

    socket.on('disconnect', reason => {
      console.warn('Disconnected:', reason);
      setIsConnected(false);
    });

    socket.on('connect_error', error => {
      console.error('Connection error:', error.message);
    });

    socket.on('message', data => {
      if (data && data.id && data.text) {
        setMessage(prevValue => [...prevValue, data]);
      } else {
        console.error('Invalid message data:', data);
      }
    });

    return () => {
      socket.disconnect();
      socket.removeAllListeners();
      appStateSubscription.remove();
    };
  }, []);

  return (
    <SocketContext.Provider
      value={{
        socket: socketRef.current,
        isConnected,
        messages: message,
        setMessage,
      }}>
      {children}
    </SocketContext.Provider>
  );
};

export const useSocket = (): SocketContextType => {
  const context = useContext(SocketContext);
  if (!context) {
    throw new Error('useSocket must be used within a SocketProvider');
  }
  return context;
};

Key Features:

Automatically manages connection and disconnection.
Provides a global socket instance.

3. Handling Acknowledgements and Event Queue

Acknowledgements ensure the server processes your events. We’ll also handle retries and queue events when disconnected.

useSocketInstance.tsx

import {useCallback, useEffect, useState} from 'react';
import {useSocket} from './SocketContext';

interface EventQueueItem {
  eventName: string;
  eventData: any;
  retryCount: number;
}

export const useSocketInstance = () => {
  const {socket, isConnected, messages: message, setMessage} = useSocket();
  const [eventQueue, setEventQueue] = useState<EventQueueItem[]>([]);

  const MAX_RETRIES = 3;
  const ACK_TIMEOUT = 5000; // Timeout in ms

  const addToQueue = (eventName: string, eventData: any, retryCount = 0) => {
    setEventQueue(prev => [...prev, {eventName, eventData, retryCount}]);
  };

  const emitWithAck = useCallback(
    async (
      eventName: string,
      eventData: any,
      retryCount = 0,
    ): Promise<void> => {
      if (!socket || !isConnected) {
        console.warn(`Socket disconnected. Queuing event: ${eventName}`);
        addToQueue(eventName, eventData, retryCount);
        return;
      }

      try {
        const response = await socket
          .timeout(ACK_TIMEOUT)
          .emitWithAck(eventName, eventData);
        if (response.status === 'ok') {
          console.log(`Event ${eventName} delivered successfully.`);
        } else {
          console.error(`Server error for event ${eventName}:`, response.error);
          throw new Error(response.error);
        }
      } catch (error) {
        console.warn(`Ack failed for event ${eventName}:`, error);
        if (retryCount < MAX_RETRIES) {
          console.log(
            `Retrying event ${eventName} (${retryCount + 1}/${MAX_RETRIES})`,
          );
          addToQueue(eventName, eventData, retryCount + 1);
        } else {
          console.error(
            `Event ${eventName} failed after ${MAX_RETRIES} retries.`,
          );
          // Notify the caller about the failure
          throw new Error(
            `Event ${eventName} failed after ${MAX_RETRIES} retries.`,
          );
        }
      }
    },
    [isConnected, socket],
  );

  const processQueue = useCallback(() => {
    if (socket && isConnected) {
      eventQueue.forEach(({eventName, eventData, retryCount}) => {
        emitWithAck(eventName, eventData, retryCount);
      });
      setEventQueue([]); // Clear the queue after processing
    }
  }, [emitWithAck, eventQueue, isConnected, socket]);

  useEffect(() => {
    if (isConnected) {
      processQueue();
    }
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [isConnected, eventQueue]); // This will rerun the effect when either the socket is connected and when there is queue to run

  return {emitWithAck, isConnected, message, setMessage};
};

4. Integrating into the App

App.tsx

import React from 'react';
import {SocketProvider} from './SocketContext';
import ChatScreen from './ChatScreen';

function App(): React.JSX.Element {
  return (
    <SocketProvider>
      <ChatScreen />
    </SocketProvider>
  );
}

export default App;

ChatScreen.tsx

import React, {useState} from 'react';
import {View, TextInput, Button, StyleSheet, Alert, Text} from 'react-native';
import {useSocketInstance} from './useSocketInstance';

const ChatScreen = () => {
  const {emitWithAck, isConnected, message} = useSocketInstance();
  const [currentMessage, setCurrentMessage] = useState('');

  const sendMessage = () => {
    if (currentMessage.trim()) {
      emitWithAck('sendMessage', {currentMessage}).catch(error => {
        console.error('Error sending message:', error);
        // Handle the error, e.g., display an error message to the user
        Alert.alert('Error sending message: ' + error.message);
      });
      setCurrentMessage('');
    }
  };

  return (
    <View style={styles.container}>
      {message.map(value => (
        <Text key={value.id}>{value.text}</Text>
      ))}
      <TextInput
        value={currentMessage}
        onChangeText={setCurrentMessage}
        placeholder="Type a message"
        style={styles.input}
      />
      <Button
        title="Send Message"
        onPress={sendMessage}
        disabled={!isConnected}
      />
    </View>
  );
};

const styles = StyleSheet.create({
  container: {padding: 20},
  input: {
    borderWidth: 1,
    borderColor: '#ccc',
    borderRadius: 5,
    marginBottom: 10,
    padding: 10,
  },
});

export default ChatScreen;

Conclusion

This setup ensures:

Reliable Event Delivery: Acknowledgements with retries and timeouts ensure messages are not lost.
Reconnection Management: Automatically processes queued events when the connection is restored.
Global Access: A centralized socket context simplifies application logic.
With this robust approach, your React Native app can handle WebSocket communication even under unreliable network conditions.

Github Link: https://github.com/dubbyding/react-native-socket

Code Documentation: Necessity or a Waste of Time?

Raj Maharjan — Tue, 03 Oct 2023 08:27:10 +0000

When I began my first internship after graduating from engineering school, everyone kept saying how important documentation was for coding. I couldn't help but wonder, 'Why? I already understand what I'm doing,' 'Is it a waste of time?' or 'I could write more code instead of documenting.' Maybe not everyone feels this way, especially experienced developers who've struggled for days or even weeks trying to understand code from others who didn't include any documentation realizing more and more the importance of documentation.

Documentation?

Documentation may have different definitions if you look at different fields even in IT. Design documentation, Project Management Documentation, Programming Documentation, etc. Each holds a different section of importance in a project. For example for code, It’s definition is, “It is a collection of documents and code comments explaining how code works and how to use it.” There may be standard in place that helps to make documentation consistent in any field but at the end of the day, all it does is help the user and understand following things:-

What is to happen?
What did happen?
How did it happen? and Conclusion for others to use.

Why Documentation?

Since I am working in the programming sector, I’ll be explaining why we need it in coding using the above points.

What is to happen?

The first point, ”What is to happen?” helps us understand the idea of what we actually need to do so that we can create logic to face that problem more easily. You may say I can visualize the code all on my own so there is no need to write it down that’s where I say, It’s okay if the logic you are developing is very simple but what if it’s not? What if the logic you are developing is very complicated and you get lost on the logic you were developing due to bugs? That’s where documentation on what is to happen is required. Even if you are developing a database, the database you just end up with might not be the best result. There are lots of benefits of doing documentation on coding what you are about to do.

/**
 * To check if "n" is a prime number
 *
 * What I know?
 * 1) Prime number is the one which is no divisible by no other number but itself and 1
 * 2) I don't need to include 1 (Divides all numbers)
 * 3) I don't need to include n (Divides itself)
 *
 * Range should be from 2-n
 */

What did happen?

When building logic, there might be an occurrence where you find a great idea that you didn’t find anywhere on the internet and you implement it. Since no one but you implemented it, others might have no idea how it works. And the thing about coding is no matter how clean code you write, It does get a lot more difficult to remember what you did to solve that problem later.

Several developers may have problems in this section. In my case, I was trying to create a three-lane game, and I found a great way of making it work without using an addition. But when I was trying to put the finishing touches on it, I had no idea how everything was working. It took me another hour or so to go through everything to finally get what I actually did.

So writing about what happened in coding helps you revisit the code and understand the genius idea you had not only for yourself but for other developers as well.

function primeNumber(n) {
    let isPrime = true;

    if (n % 2 === 0 && n !== 2) {
        // All even numbers are not prime except 2
        return false;
    }

    for (let i = 2; i < n / 2; i++) {
        // We have dont n/2 since any number which is greater than n/2 while dividing will give result less than 1
        const reminder = n % i;

        if (!reminder) {
            isPrime = false;

            break; // Since we don't need to check for other numbers if it's not prime
        }
    }

        return isPrime;
}

How did it happen? and Conclusion for others to use.

This is the point which most of the developers are most familiar with. Writing about a function or a class including what it does, what is returns, and what are the requirements for it to run. If someone is using JS, there is JSDocs and another programming language has a similar documentation standard which is used by almost all developers for the reusability of the code.

While the other two parts are used for the purpose of understanding the code, this part is only written for the functional aspect. For example, you want to find a prime number and someone has created a function already to calculate the prime number, you don't usually need to know how they are calculating the prime number, you just want to know what they give as result and what they take in input.

/**
 * The function checks if a given number is prime
 *
 * @param {number} n - The parameter "n" represents the number that we want to check if it is a prime number or
 * not.
 * @returns The function is not returning anything.
 */

How to document a code?

To document a code, the simplest way is to use the standard commenting such as JSDocs for JS. It's most widely used and even if a new developer opens the code they can understand it quite easily.

The smallest way to document a code would be to use proper names for variables and functions which makes life way easier for refactor purposes or to change later down the line.

Not Always Possible

Saying how documentation is required, we might be pushed to think that we need to include it everywhere, but as we developers know, it's always not the case. Tight deadlines, and managing multiple projects, are only a few of the problems one might face while on a project which might not make it possible for us to write documentation at every moment.

Writing code in a particular architecture such as Clean architecture, or atomic structure pattern can also be a way for other developer to understand the code more easily.

Conclusion

Documentation even if we don't use at all is there for easement of ourselves and/or other developers working together in the project. Adding the small line of comment indicating what happens when you run a function helps a long time for any other developer trying to work on that project and if you work on it after months then it will surely be ease for you as well.

Wireframing and HTML Structure: The Unsung Heroes of Frontend Development

Raj Maharjan — Sat, 23 Sep 2023 06:40:42 +0000

We have all been there, Everyone is saying how good the pay there is in IT so the first thing we look at is frontend development. We explore the internet, looking at every tutorial on YouTube, w3schools, and other platforms. They all show you the HTML tags and CSS properties. They are doing a good job getting us familiar with the concept of where to use specific tags and CSS properties. But the problem occurs when we try to duplicate a page on our own with the knowledge we gained from those videos. We could follow them word to word, line to line to create the webpage they were showing in their tutorial but when we do it ourselves it gets hard. Even if we use ‘flex’ and ‘grid’ to fix our design for the desktop, it becomes very hard when it comes to making the page responsive. The core parts which should be wireframing and HTML structure are the thing that almost all of the tutorials forget to mention.

What is Wireframing?

Wireframing is something that usually no frontend developer is seen doing. Every task for building and creating the webpage seems so second nature that they just look at the design and start to implement it to create responsiveness in every device but when we are starting out, that second nature of the developer seems like magic of a kind. They write the code and it works but you try to do the same but it doesn’t work. The design that you just coded in HTML and CSS is not showing as in the design. What wireframing does is help you visualize even more in detail what every part goes on the webpage. If you are using libraries or frameworks, you can treat them like components that help you visualize the design and how to implement it more clearly.

Why Wireframing?

Wireframing should be taken as a tool that can help improve our productivity and like any tool to use it requires practice. I have tried and made a few myself and later down the road, I felt that the wireframe that I designed for the page was very inadequate and of very low quality. It is an iterative process where we create a wireframe and try to implement it, feel like the wireframe was not good enough to get a proper result, try what can be improved in code, and try to implement that in the wireframe again. Then try to create a better version of the wireframe and the circle continues for the case for learning which helps us visualize and structure our HTML document properly.

What is HTML Structuring?

Similar to wireframing, HTML structuring is something an experienced frontend developer just does without even breaking a sweat but becomes a big factor when making a site responsive. Normally whenever there is a problem in the responsiveness of the site it’s due to the HTML not being structured properly.

So what is this HTML Structuring? It is referred to as the proper way of containerizing your application's structure using proper semantics or div tags in the proper situation. This not only helps with the responsiveness of our webpage but also helps with the SEO of our site to be deployed which is an important factor if you want your site to show up in search engines like Google.

Connection of Wireframe with HTML Structuring

Creating a proper wireframe helps us plan to structure our HTML properly. Wireframe helps us visualize the tags before writing them into an IDE, such as Visual Studio Code, which helps you smooth out our workflow for senior developers and makes it easier for starters on frontend to create a proper clone of the website on their own.

For newcomers, I recommend building a clone of any site you are building using Float. Float seems simple, but if any of the HTML structures are off, the design doesn’t clone itself properly. I also recommend not using ChatGPT for learning purposes for this particular exercise. There is a quote by Monica of F.R.I.E.N.D.S that I'd like to share with a twist of programming, "Welcome to the real world. It sucks. You’re gonna love it."

Conclusion

Proper wireframes and proper HTML structure actually go hand in hand. Proper wireframes can lead to proper HTML for smoother workflow and learning while proper HTML structure helps to make the wireframes better as well.