How the Internet Actually Works: Understanding Client-Server Architecture with Real Code

The Big Picture: What Happens When You Visit a Website?

Every time you type a URL into your browser and hit Enter, a surprisingly complex chain of events kicks off in the background. Most people never think about it, but understanding this process is the foundation of everything we’ll cover in this guide.

Let’s walk through what actually happens when you visit something like https://www.example.com.

Step 1: Your browser looks up the address

Your computer doesn’t understand domain names like www.example.com. It needs an IP address, which is basically a numerical home address for a server somewhere in the world. To get it, your browser contacts a DNS (Domain Name System) server, which works like a giant phone book for the internet. It translates the human-friendly name into something like 93.184.216.34.

Step 2: Your browser opens a connection

Now that your browser knows the IP address, it reaches out to that server and says “hey, I’d like to talk.” This happens using a protocol called TCP (Transmission Control Protocol), which sets up a reliable back-and-forth channel between your machine and the server.

Step 3: Your browser sends an HTTP request

Once the connection is open, your browser sends a message to the server. That message looks something like this:

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

This is a raw HTTP request. It’s just text, following a specific format. The GET part means “please give me this resource.” The / refers to the homepage.

Step 4: The server sends back a response

The server receives your request, figures out what you want, and sends back a response:

HTTP/1.1 200 OK
Content-Type: text/html

<!DOCTYPE html>
<html>
  <body><h1>Hello, World!</h1></body>
</html>

The 200 OK means everything went fine. The server then sends the actual HTML content your browser will display.

Step 5: Your browser renders the page

Your browser reads the HTML, fetches any additional files it needs (like CSS, images, or JavaScript), and paints the final page on your screen.

The whole process typically takes under a second, but it involves your computer, at least one DNS server, and a web server potentially located on the other side of the planet.

This request-and-response cycle is the heartbeat of the web. Everything else we cover in this tutorial builds directly on top of it.

Clients vs. Servers: Who Does What?

Before we write any code, let’s get one thing straight: a client and a server are just two computers (or programs) having a conversation. That’s it. No magic involved.

Here’s the simple breakdown:

• The client is the one asking questions. Your web browser is a client. When you type a URL and hit enter, your browser is saying “Hey, can I have that webpage?”
• The server is the one answering. It sits around waiting for requests, and when one arrives, it figures out what to send back.

Think of it like ordering food at a restaurant. You’re the client, you make a request (“I’ll have the burger”), and the kitchen is the server, preparing and sending back exactly what you asked for.

A Client Sends Requests

A request has a few key pieces:

1. A method (like GET or POST) that says what kind of action you want
2. A URL that says where you want to do it
3. Headers that carry extra info (like what kind of data you can accept)
4. A body (optional) that carries data you’re sending along

Here’s what a dead-simple client looks like in Python using the requests library:

import requests

response = requests.get("https://jsonplaceholder.typicode.com/posts/1")

print(response.status_code)  # 200 means success
print(response.json())       # The actual data sent back

Run that and you’ll see a dictionary of data come back. Your script just acted as a client.

A Server Listens and Responds

The server’s job is to:

1. Listen on a specific port for incoming connections
2. Read the incoming request
3. Process it (look up data, run some logic, whatever)
4. Send back a response with a status code and some data

A status code is just a number that tells the client how things went. You’ve probably seen 404 before, which means “I couldn’t find what you asked for.” A 200 means everything went fine.

Here’s a quick cheat sheet of the most common ones:

Neither side can do the other’s job. The client can’t serve data, and the server doesn’t go out looking for things to do — the client always starts the conversation, and the server always responds. That boundary is also why you can swap out a Spring Boot backend for FastAPI without touching the Angular frontend, as long as the contract — the API — stays the same.

Next up, we’ll actually build one of these servers from scratch.

Building a Basic HTTP Server in Python from Zero

Alright, let’s get our hands dirty and actually build something. The good news is that Python comes with a built-in HTTP server module, so you don’t need to install anything extra to get started.

Open up your terminal and try this one-liner first, just to see the magic happen:

python3 -m http.server 8080

Point your browser to http://localhost:8080 and you’ll see a file listing for whatever directory you ran that command in. Cool, right? But that’s cheating a little. Let’s build one ourselves so you actually understand what’s going on.

Create a new file called server.py and paste in this code:

from http.server import HTTPServer, BaseHTTPRequestHandler

class MyHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        # Send a 200 OK response
        self.send_response(200)
        self.send_header("Content-type", "text/html")
        self.end_headers()

        # Write the response body
        message = "<h1>Hello from my server!</h1>"
        self.wfile.write(message.encode("utf-8"))

# Start the server on port 8080
server = HTTPServer(("localhost", 8080), MyHandler)
print("Server running on http://localhost:8080")
server.serve_forever()

Run it with python3 server.py, then visit http://localhost:8080 in your browser. You should see a big “Hello from my server!” heading. You just wrote a web server.

Let’s break down what each part does:

• BaseHTTPRequestHandler is the class we inherit from. It handles the low-level networking stuff so we don’t have to.
• do_GET is a method that gets called automatically whenever someone sends a GET request to your server. The name matters here, so don’t rename it.
• send_response(200) tells the client “everything went fine.” That 200 is an HTTP status code.
• send_header and end_headers package up the metadata about your response before the actual content.
• self.wfile.write() is where you actually send the content back. It needs bytes, which is why we call .encode("utf-8").

Want to serve different content based on the URL? You can check self.path to see what the user requested:

def do_GET(self):
    self.send_response(200)
    self.send_header("Content-type", "text/html")
    self.end_headers()

    if self.path == "/about":
        message = "<h1>About Page</h1>"
    else:
        message = "<h1>Home Page</h1>"

    self.wfile.write(message.encode("utf-8"))

Now visiting /about gives a different response than visiting /. That right there is the core concept behind routing — something every web framework like Flask or Django builds on top of. Worth noting: this raw http.server approach is useful for learning, but in production you’d reach for FastAPI or Spring Boot, where routing, validation, and serialization are handled for you. For now, though, knowing what happens underneath those abstractions is exactly the point.

Press Ctrl+C in your terminal to stop the server when you’re done experimenting.

Making Your First API Request: Sending and Receiving Data

Now that you have a server running, let’s actually talk to it. This is where things get fun.

An API request is just your code asking another computer for data. Think of it like ordering food at a restaurant: you (the client) tell the waiter (the HTTP request) what you want, and the kitchen (the server) sends it back.

We’ll use Python’s requests library to do this. If you don’t have it yet, install it with:

pip install requests

Fetching Data with a GET Request

A GET request means “give me some data.” Here’s the simplest possible example:

import requests

response = requests.get("https://jsonplaceholder.typicode.com/posts/1")

print(response.status_code)   # Should print 200
print(response.json())        # Prints the actual data

Run that and you’ll see a real JSON response come back. The status_code of 200 means everything went fine. You’ll also notice response.json() automatically converts the raw text into a Python dictionary you can work with right away.

Sending Data with a POST Request

A POST request means “here’s some data, do something with it.” This is how login forms, sign-up pages, and chat apps send information to a server.

import requests

new_post = {
    "title": "My First Post",
    "body": "Hello, internet!",
    "userId": 1
}

response = requests.post(
    "https://jsonplaceholder.typicode.com/posts",
    json=new_post
)

print(response.status_code)   # Should print 201 (Created)
print(response.json())

Notice the status code here is 201 instead of 200. Servers use different codes to tell you what happened:

Reading the Response

Every response has two important parts:

1. Headers: metadata about the response (content type, server info, etc.)
2. Body: the actual data you requested

print(response.headers["Content-Type"])  # Tells you the data format
print(response.text)                     # Raw response as a string
print(response.json())                   # Parsed as a Python dict

One quick tip: always check the status code before trusting the data. A simple habit is:

if response.status_code == 200:
    data = response.json()
    print(data)
else:
    print(f"Something went wrong: {response.status_code}")

That’s genuinely all there is to making API requests. You’re sending a message over the internet and reading the reply. Everything else is just details built on top of this foundation.

Understanding Stateless vs. Stateful Communication

Here’s one of those concepts that trips up a lot of beginners, but once it clicks, everything starts to make more sense.

HTTP is stateless by default. That means every single request your browser sends to a server is treated as a brand new conversation. The server has no memory of you from one request to the next. It’s like calling a customer service line where the agent forgets you the moment you hang up, and you have to re-introduce yourself every single time you call back.

Let’s make this concrete. Imagine you log into a website. On request #1, you send your username and password. The server checks them and says “yep, that’s valid.” Now on request #2, you ask to see your profile page. The server has absolutely no idea who you are anymore. Stateless. Clean slate.

# Every request arrives with no memory of previous requests
# The server just sees raw data each time

from http.server import BaseHTTPRequestHandler, HTTPServer

class StatelessHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        # The server has zero context about who called before
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b"Who are you? I have no idea!")

So how do websites actually remember you’re logged in? They fake statefulness by passing identity information along with every request. The two most common tricks are:

Cookies – The server sends a small token to your browser after you log in. Your browser then automatically attaches that token to every future request, like wearing a name badge.

Tokens (like JWTs) – Similar idea, but the token itself contains encoded information about who you are, so the server can verify it without even checking a database.

# Simulating stateful behavior by reading a token from headers
class TokenHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        token = self.headers.get("Authorization")

        if token == "Bearer secret-token-123":
            response = b"Welcome back! I recognize your token."
        else:
            response = b"Access denied. Who are you?"

        self.send_response(200)
        self.end_headers()
        self.wfile.write(response)

Notice what happened there. The server itself still has no memory. But because the client sent a token, the server could figure out who was asking. The state lives in the token, not in the server.

This is actually a really smart design. If the server held everyone’s session in memory, it would get overwhelmed fast and become nearly impossible to scale. By keeping things stateless and pushing identity into tokens or cookies, you can run dozens of servers and any one of them can handle any request. In practice, this is exactly the pattern you see in Kubernetes-based deployments — pods can be added, removed, or replaced without any of them needing to share session memory, because the client carries its own identity on every call.

The takeaway: stateless does not mean insecure or forgetful from the user’s perspective. It just means the client is responsible for proving who they are on every single request.

Common Pitfalls Beginners Make and How to Avoid Them

You’ve made it this far, which means you’re ready to start building real things. But before you do, let’s talk about the mistakes that trip up almost every beginner. Learning these now will save you hours of frustration later.

Pitfall #1: Forgetting to Handle Errors in Your Requests

A lot of beginners write code that assumes everything will work perfectly. Spoiler: it won’t. Networks fail, servers go down, and URLs get mistyped. Always wrap your requests in error handling:

import requests

try:
    response = requests.get("https://api.example.com/data", timeout=5)
    response.raise_for_status()  # Raises an error for 4xx and 5xx status codes
    print(response.json())
except requests.exceptions.Timeout:
    print("The request timed out. Try again later.")
except requests.exceptions.HTTPError as e:
    print(f"HTTP error occurred: {e}")
except requests.exceptions.ConnectionError:
    print("Could not connect. Check your internet or the URL.")

Notice the timeout=5 parameter too. Without it, your program could hang forever waiting for a response that never comes.

Pitfall #2: Hardcoding Sensitive Data

Never put API keys, passwords, or tokens directly in your code like this:

# BAD - don't do this!
api_key = "my_super_secret_key_12345"

If you push this to GitHub, the whole world can see it. Instead, use environment variables:

import os

api_key = os.environ.get("API_KEY")

Then set the variable in your terminal before running your script:

export API_KEY="my_super_secret_key_12345"

Pitfall #3: Ignoring Status Codes

A request can “succeed” in the sense that it got a response, but that response might be a 404 Not Found or a 500 Internal Server Error. Beginners often skip checking the status code and then wonder why their data looks weird.

Always check response.status_code or use raise_for_status() as shown above.

Pitfall #4: Not Closing Your Server Properly

When you run a local Python server during testing, always stop it with Ctrl + C when you’re done. If you just close the terminal window, the port can stay occupied. Then the next time you try to start the server, you’ll see something like:

OSError: [Errno 98] Address already in use

You can find and kill the process using:

lsof -i :8080   # Find what's using port 8080
kill -9 <PID>   # Replace <PID> with the process ID shown

Pitfall #5: Assuming JSON is Always the Answer

JSON is super common, but not every API returns it. Some return XML, plain text, or even HTML. Always check the Content-Type header in the response before blindly calling .json(), or you’ll get a confusing parse error.

print(response.headers["Content-Type"])

Avoiding these five mistakes puts you way ahead of where most beginners start. Keep them in your back pocket and your debugging sessions will be a lot shorter.

NestJS vs Express: Which One Should You Choose in 2025?

Node.js gives you two wildly different starting points when building a backend: the minimal, unopinionated Express and the structured, opinionated NestJS. Both are production-proven, but they solve different problems. This article breaks down the real trade-offs so you can make an informed choice.

What Is Express?

Express is a minimalist web framework for Node.js. It’s been around since 2010 and remains one of the most downloaded npm packages ever. You get routing and middleware — nothing else. Everything else is your call.

// server.js
const express = require('express');
const app = express();

app.use(express.json());

app.get('/users', (req, res) => {
  res.json([{ id: 1, name: 'Alice' }]);
});

app.listen(3000, () => console.log('Server running on port 3000'));

This simplicity is both its superpower and its weakness.

What Is NestJS?

NestJS is a full-featured framework built on top of Express (or Fastify) that brings Angular-style architecture to the backend. It’s written in TypeScript, uses decorators heavily, and enforces a module-based structure with built-in Dependency Injection.

// users.controller.ts
import { Controller, Get } from '@nestjs/common';
import { UsersService } from './users.service';

@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Get()
  findAll() {
    return this.usersService.findAll();
  }
}

NestJS makes decisions for you — and that’s the point.

Side-by-Side Comparison

Architecture: Freedom vs Structure

With Express, your architecture is entirely up to you. A small team might ship fast, but a large team will eventually diverge — inconsistent folder structures, mixed patterns, different approaches to error handling.

NestJS enforces a layered architecture out of the box:

src/
  app.module.ts          ← root module
  users/
    users.module.ts      ← feature module
    users.controller.ts  ← handles HTTP
    users.service.ts     ← business logic
    users.repository.ts  ← data access

Every feature is encapsulated in a Module. This scales naturally across teams because the pattern is always the same.

Dependency Injection

This is where NestJS’s biggest advantage lies. In Express, you wire dependencies manually:

// Express — manual wiring
const db = new Database(config);
const userRepo = new UserRepository(db);
const userService = new UserService(userRepo);
const userController = new UserController(userService);

In NestJS, the IoC container handles this:

// NestJS — DI container wires everything
@Injectable()
export class UserService {
  constructor(private userRepository: UserRepository) {}
}

Declare what you need, NestJS creates and injects it. This makes unit testing trivial:

const module = await Test.createTestingModule({
  providers: [
    UserService,
    { provide: UserRepository, useValue: mockRepository },
  ],
}).compile();

Swapping real implementations for mocks is a one-liner.

TypeScript Support

Express technically works with TypeScript, but it’s bolted on — you install @types/express, configure tsconfig.json, and still fight the type system at the edges.

NestJS is written in TypeScript and designed around it. Decorators, interfaces, generics — they’re not optional extras, they’re core to how the framework works. Your autocomplete actually knows what’s happening.

Middleware and Guards

Both frameworks handle middleware, but NestJS adds higher-level abstractions:

// NestJS guard — clean and declarative
@UseGuards(JwtAuthGuard)
@Get('profile')
getProfile(@Request() req) {
  return req.user;
}

Contrast with Express, where you’d nest middleware manually and hope it runs in the right order.

Real-World Validation

NestJS ships with a validation pipeline that pairs with class-validator decorators:

// create-user.dto.ts
import { IsEmail, IsString, MinLength } from 'class-validator';

export class CreateUserDto {
  @IsString()
  name: string;

  @IsEmail()
  email: string;

  @IsString()
  @MinLength(8)
  password: string;
}

// users.controller.ts
@Post()
create(@Body() dto: CreateUserDto) {
  return this.usersService.create(dto);
}

Enable ValidationPipe globally and any invalid request body returns a structured 400 error automatically. No express-validator setup, no manual if chains.

Performance

Both frameworks perform similarly in real-world workloads. NestJS defaults to Express under the hood, so the baseline is identical. Switch to Fastify in NestJS with one line if you need raw throughput:

// main.ts — switch to Fastify adapter
import { FastifyAdapter } from '@nestjs/platform-fastify';

const app = await NestFactory.create(AppFactory, new FastifyAdapter());

No code changes elsewhere — your controllers and services stay the same.

When to Choose Express

• Prototyping or MVPs — when you need something running in hours, not days
• Microservices with a single responsibility — a small proxy or webhook receiver doesn’t need modules
• Teams that want full architectural control — if you have strong conventions already
• Legacy codebases — migrating an existing Express app piecemeal

When to Choose NestJS

• Enterprise or team projects — consistent structure prevents architectural drift
• TypeScript-first teams — the DI system and decorators shine here
• APIs with complex domain logic — modules keep bounded contexts clean
• Projects that need WebSockets, GraphQL, or gRPC — NestJS has first-class adapters for all of these
• Long-lived products — the structure pays dividends as the codebase grows

The Verdict

Express is the right tool when you value freedom and want to move fast with minimal overhead. It’s battle-tested and the ecosystem around it is unmatched.

NestJS is the right tool when you’re building something that will grow, has multiple contributors, or requires features like GraphQL, WebSockets, or microservices out of the box. The learning curve is real, but the payoff is a codebase that stays maintainable at scale.

If you’re starting a new project that’s more than a weekend hack, NestJS is probably the better long-term bet. If you need something up in two hours, Express still wins.

Quick Start

# Express
npm init -y && npm install express

# NestJS
npm install -g @nestjs/cli
nest new my-project

What framework are you using in production? Drop your experience in the comments — I’d love to hear what drove your choice.

Traditional digital signature platforms have two major issues: privacy and cost.

To sign a document, you have to upload sensitive agreements to a third-party server. And as a developer, running server-side document rendering and signatures can lead to heavy API bills and database management overhead.

At Ananta Labs, we wanted to see if we could build a completely secure, contactless alternative that runs entirely on the client side using browser-native AI.

Here is how we built AirSign.

The Architecture: 100% Client-Side

Instead of hosting heavy machine learning models on a GPU server, we compiled our hand-tracking models to run locally inside the user’s browser.

1. Gesture Capture: We utilized MediaPipe’s hand-landmarker models compiled into WebAssembly. This allows the browser to track 21 3D hand coordinates in real-time at 30 FPS using a standard webcam.
2. Contactless Canvas: Using WebGL, we map the index finger coordinate to a HTML5 canvas. We implemented a custom interpolation algorithm to smooth out hand jitter and render a fluid, realistic signature line.
3. Local PDF Stamp: Once the user finishes drawing their signature in the air, we generate the final document. The signature coordinate vector is parsed and stamped onto the PDF using a client-side library.

Why this is the Future of AI Integration

By moving the computation from the server to the client:

• Absolute Privacy: 0 video frames, coordinate points, or document bytes are transmitted to any database.
• Zero Server Overhead: The hosting cost for this app is exactly $0 since it runs on the user’s CPU/GPU.
• Instant Load Times: Zero network latency during signature interpolation.

Try it Yourself

AirSign is completely open and free to test. We’d love to hear your feedback on the hand-tracking latency and mobile performance:

👉 Try AirSign: https://airsign-red.vercel.app/
👉 Explore our work: https://anantalabs.app/

In this blog , I will explain how I designed a multi-organization architecture for my ticket management system and the challenges I faced while implementing secure tenant isolation.

The Situation

I was building a ticket management system where teams could collaborate on issues, assign tickets, and manage workflows.

Initially, the application supported only a single workspace, but later I realized that real-world teams usually work inside organizations similar to GitHub, Supabase, or Jira.

So I decided to redesign the architecture in a way where:

• A user can create multiple organizations
• Organizations can have multiple members
• Each organization has isolated tickets and resources
• Users can switch between organizations
• Roles and permissions can be managed independent

The goal was to build a reusable multi-tenant foundation that could scale later.

Understanding Multi-Tenancy

Before implementing the system, I first needed to understand what multi-tenancy actually means.

A multi-tenant application is a system where:

• Multiple organizations share the same backend infrastructure
• But their data remains logically isolated

This means:

Organization A cannot access Organization B data
even though both use the same database and server.

Choosing architecture

There are multiple ways to multi-tenancy , after some research i found 3 different Approch

1. Separate Database per tenant: In this structure each organization have its own database which provide strict isolation and excellent scale but very complex , this architecture is used by enterprise SasS, banking system, when Physical isolation is required

2. Separate Schemas per tenant : It bit complex but provide good isolation

3. Shard DB with tenantId: It is Easy to implement and less time consuming

For my system , I Choosing

Shared Database + organizationId based on isolation

Because:-

• easier to scale Initially
• lower infrastructure cost
• faster development
• Easy migration
• Simpler to deploy

Note:-Main trade off is enforcing organization-level filtering which need proper indexing

Database Schemas

First step is to design Schema as shown

model User {
  id                String             @id @default(uuid()) @db.Uuid
  code              String             @unique
  email             String             @unique
  createdAt         DateTime           @default(now())
}

model Organization {
  id                String             @id @default(uuid()) @db.Uuid
  name              String
  createdAt         DateTime           @default(now())
  createdBy         String             @db.Uuid
}

model Membership {
  id             String        @id @default(uuid()) @db.Uuid
  organizationId String        @db.Uuid
  userId         String        @db.Uuid
  roleId         String        @db.Uuid
  createdAt      DateTime      @default(now())
  isSystem       Boolean       @default(false)

}

model Role {
  id             String        @id @default(uuid()) @db.Uuid
  code           String        @unique
  name           String
  permissions    Json
  createdBy      String        @db.Uuid
  organizationId String        @db.Uuid
  isSystem       Boolean       @default(false)
}

The Membership table become core abstraction because it allowed:

• One user to join multiple Organization
• Different Roles per organization
• Easy invitation system or transfer organization
• RBAC support

Organization Creation Flow

When a user creates a new organization, the system automatically performs multiple operations behind the scenes.

The goal was to ensure that every organization always has:

• a valid owner
• at least one role
• a membership relationship
• protected authorization rules

The creation flow looks like this:

User Creates Organization
        |
        v
Create Organization Row
        |
        v
Create Hidden "Owner" Role
        |
        v
Create Membership Record
        |
        v
Assign User to "Owner" Role

Request Cycle

Every request in the system flow through this lifecycle:

Request
   |
   v
Authentication Middleware
   |
   v
Tenant Middleware
   |
   v
Validate Membership
   |
   v
Attach Tenant Context
   |
   v
Execute Scoped Database Queries
   |
   v
Response

here it follow following steps

1. Every request enters the system with the x-organization-id header attached. This header identifies which organization the user is currently operating in.

2. The authentication middleware verifies the user and attaches user details to the request object.

req.user = {
  ...req.user,
  id: userdata?.id,
};

1. The tenant middleware identifies the organization from the request headers and determines what permissions the user has within that specific organization.

The middleware attaches organization details to the request object:

req.organization = {
  ...req.organization,
  isOwner: member?.role?.name === "OWNER",
  id: organizationId,
};

1. Any controller can now directly access the organization ID and organization-related metadata from req.organization.

By applying this approach, there is no need to send the organization ID in every route, such as:

/api/v1/:orgId/xyz

The active organization is decided by the frontend and passed through the x-organization-id header, resulting in cleaner and more maintainable APIs.

Isolation Strategy

The main challenge in multi-tenancy is isolating each organization’s data without leaking information across tenants. Since the database schema is shared among multiple tenants, the safest and most reliable approach is to always filter records by organizationId during every CRUD operation.

Example:

const data = await prisma.ticket.findMany({
  where: {
    organizationId: req.organization.id,
  },
});

By enforcing organization-level filtering consistently across all database operations, the application maintains strong tenant isolation while still using a shared database schema.

Multi-tenant architectures offer great scalability, but they essentially put all your customers’ eggs in one basket. If the “walls” between those eggs aren’t reinforced at the code level, a single leak can become a catastrophic breach.

In Addition of batter Security we need to implement Row Level Security to minimize risk of data leak between tenant

Security Challenges in Multi-Tenant Systems

In a multi-tenant environment, security revolves around Tenant Isolation (keeping data separate) and Access Control (ensuring users only do what they are permitted to do).

1. Tenant Data Leakage (The “Missing Filter” Problem)

This is the most frequent and severe risk. Because multiple tenants share the same database tables, a single forgotten WHERE clause in a query can expose sensitive data to the wrong organization.

• The Risk: An API endpoint like /api/customers might accidentally return all customers in the database instead of just those belonging to the requester’s organization_id.
• The Fix: Implement Row-Level Security (RLS) at the database level or use Global Query Filters in your ORM (Object-Relational Mapper) to automatically inject the tenant_id into every query.

2. Horizontal Privilege Escalation

This occurs when a user from Tenant A attempts to access resources belonging to Tenant B.

• The Scenario: A user changes a URL from tickets/123 (their own) to tickets/124 (another tenant’s).
• The Fix: Never rely on the resource ID alone. Your backend logic must perform a “Double-Check”:

1. Does ticket 124 exist?
2. Does ticket 124 belong to the organization_id associated with the current user’s session?

3. Organization ID Spoofing

Attackers often try to manipulate request headers, cookies, or JWT payloads to “masquerade” as a different organization.

• The Risk: Trusting an X-Org-ID header sent by the frontend without server-side verification.
• The Fix: Never trust the frontend context.
• Store the organization_id inside a secure, server-signed JWT.
• On every request, cross-verify that the user is a valid member of the organization they are claiming to represent.

4. Vulnerabilities in the Invitation System

The “Invite User” flow is a common entry point for attackers to bypass standard registration security.

Final Thoughts

At first, implementing organizations looked simple.

I thought adding an organizationId field would be enough to support multi-tenancy, but while building the system I realized tenant isolation affects almost every part of the architecture.

Things like:

• authorization
• database queries
• file uploads
• caching
• background jobs
• role management

all become organization-aware.

The lesson I learned was that multi-tenancy is not just a database design pattern. It is a system-wide architectural decision.

Building this system gave me a much deeper understanding of how SaaS applications structure teams, permissions, and tenant boundaries internally.

If you’ve solved this differently or noticed any issues with this approach, I’d like to hear your thoughts. I’m still refining how I structure these systems.

Your editor choice in 2026 isn’t just about syntax highlighting
anymore — it’s about how much of your coding workflow you’re willing
to hand off to AI. Here’s the honest breakdown.

What Actually Separates Them

VS Code is Microsoft’s free, open-source editor with GitHub
Copilot bolted on. Battle-tested, extensible, and free forever.

Cursor is a VS Code fork built around AI-first workflows. Looks
identical on the surface — but the AI is woven into the core, not
added as an extension.

The key distinction: VS Code adds AI to your coding. Cursor builds
coding around AI.

Cursor Pro: What It Gets Right

Multi-file context awareness is where Cursor earns its
reputation. Ask it to refactor a function and it understands
dependencies across your entire codebase — not just the open file.

Composer mode lets you describe a feature in plain English and
watch it scaffold code across multiple files simultaneously.

Chat with your codebase — ask “where does authentication happen?”
and get a reasonably accurate answer with file references.

Native shortcuts feel natural after a week. Cmd+K to edit inline,
Cmd+L for chat.

Cons:

• $20/month is $240/year for your editor alone
• Sends code to servers — privacy mode exists but enterprise teams hesitate
• Easy to accept suggestions without fully reading them
• Quality tied to underlying AI models

VS Code: What It Still Does Better

It’s free and always will be. No subscription, no pricing tiers.

Extension ecosystem is unmatched — tens of thousands of
extensions for anything you need.

GitHub Copilot has closed the gap significantly in 2025-2026.

Team standardization is easier — shared settings.json and
extensions list makes onboarding simple.

Better on large repos — more reliable on massive monorepos and
lower-end hardware.

Cons:

• AI experience feels assembled rather than native
• Multi-file AI editing is clunkier
• Requires more configuration out of the box

Who Should Use What

Choose Cursor if:

• You’re a professional developer where $20/month pays for itself
• You work heavily in multi-file features and complex refactoring
• You’re a solo dev or small team without strict data compliance needs

Stick with VS Code if:

• You’re learning to code and need to understand what you’re writing
• Your org has data privacy requirements
• You work in a large team needing consistent environments
• You’re cost-sensitive

Verdict

Cursor wins on raw AI-coding experience — it’s a more fluid tool for
developers who want AI deeply integrated. But VS Code with GitHub
Copilot is a completely credible free alternative that has closed the
gap significantly.

Best move? Run both for two weeks. Cursor has a free trial and
VS Code costs nothing. Your own workflow will tell you more than any
comparison article.

Full breakdown at The Dev Brief

At Google I/O 2026, the tech giant unveiled a transformative vision for the internet: the “Agentic Web.” Through major updates to the Chrome ecosystem, Google is redefining the relationship between developers, users, and AI. The announcements focus on three pillars: enabling AI agents to act as first-class citizens, expanding the capabilities of web UI, and … continue reading

The post Google I/O 2026 introduces the ‘Agentic Web’ era with major Chrome updates appeared first on SD Times.