DEV Community: Khaled Saeed

Microservices Solve a Problem You Don't Have

Khaled Saeed — Thu, 23 Jul 2026 16:25:35 +0000

Somewhere right now, a three-person team is drawing boxes on a whiteboard. There is an auth-service, an orders-service, a notifications-service, a message broker between them, and an API gateway in front. The product has zero users. The team has never operated a distributed system. And every box on that whiteboard is about to become a repository, a deployment pipeline, a set of environment variables, and a production alert at 2 a.m.

This post makes one argument, carefully: microservices are an organizational scaling pattern, not a technical upgrade. But before arguing against a thing, let's define it properly.

First: what are microservices, actually?

Microservices are an architectural style where an application is built as a collection of small, independently deployable services. Each service:

owns a single business capability (payments, orders, notifications)
runs in its own process
owns its own data model and persistence, with no shared tables
talks to other services over the network, through HTTP or gRPC calls, or through messages in a broker

The opposite is the monolith: one codebase, one process, one deployable artifact. A request comes in, function calls happen in-process, one database transaction commits, done.

The promise on the microservices side sounds great. Services scale on their own, deploy on their own, fail on their own, and can even be written in different languages. Netflix, Amazon, and Uber run this way, and their engineering blogs are the canon of our industry.

Here is the catch. Copying their architecture without their problems is like buying a fleet of trucks because you saw a logistics company do it. The trucks are not the business. The trucks are what the business was forced to buy once it got big.

What problem do microservices actually solve?

Strip away the conference talks and the answer is narrow.

Microservices exist so that many teams can deploy independently without coordinating with each other. That is the core of it. Everything else, like independent scaling, mixed tech stacks, and fault isolation, is real but secondary: often achievable with simpler techniques first, or only economically meaningful at a scale most systems never reach.

Amazon did not move to services primarily because a monolith could not handle the traffic. They moved because hundreds of teams were stepping on each other: merge conflicts, release trains, one team's bug blocking another team's launch. The service boundary is a social contract. It says: you own this, I own that, we talk through an API, and neither of us needs to attend the other's standup.

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
Melvin Conway, 1967

Conway's Law is usually quoted as a warning. Read it the other way and it becomes the whole justification for microservices. If your communication structure is one team in one Slack channel, your natural system design is one deployable unit. Splitting that team's codebase into nine services does not decouple anything. The same people still coordinate every change, except now they do it across network boundaries, mismatched API versions, and distributed transactions.

The cost curves cross late:

A monolith's coordination cost grows with headcount. Microservices trade that for a large fixed operational tax that grows more slowly. Below the crossover point, which usually means several independent teams and not several developers, you are paying the tax with no refund.

The bill nobody itemizes

Every microservice split converts problems you understand into problems you don't:

Concern	Monolith	Microservices
Function call	Nanoseconds, in-process, type-checked, easy to refactor in your editor	A network hop: latency, retries, timeouts, serialization, partial failure, versioned contracts
Transaction	`BEGIN ... COMMIT`, the database does the hard part	Sagas, outbox pattern, idempotency keys, compensating actions, eventual consistency you must explain to product
Debugging	One stack trace, one log stream, a breakpoint	Distributed tracing (OpenTelemetry, collectors, sampling), correlation IDs, log aggregation, all before you can even ask "what happened?"
Refactor	Rename symbol, done, the compiler finds every caller	A cross-service migration: deprecation windows, dual writes, contract tests
Local dev	`pnpm dev`	`docker compose up` times 12, or a shared staging environment everyone breaks
Deploy	One pipeline, one artifact, clean rollback	N pipelines, compatibility matrices, and the question "which versions are live right now?"

None of these distributed-systems problems are unsolvable. They are just expensive, and the expense is permanent. Sagas, tracing, and contract tests are not a one-time setup fee. They are a mortgage on every feature you ship afterward.

Here is what the same checkout flow looks like once it is distributed, with the failure modes labeled honestly:

Same feature, same team. But the function call became nine failure modes, four pipelines, four schemas, and one saga.

"But we need to scale." Do you, though?

Scaling is the most common justification and the least examined one. Three facts get lost:

1. Monoliths scale horizontally just fine. A stateless Node/Express or NestJS monolith behind a load balancer scales the same way a microservice does. You add replicas. For most of its growth, Stack Overflow served one of the highest-traffic sites on the internet from a handful of servers running what is essentially a monolith. Shopify's core application has stayed a modular Rails monolith through flash-sale traffic that would terrify most microservice shops, with services extracted only at the edges. GitHub's core application has historically remained a large Rails monolith despite enormous scale. Basecamp is a monolith on purpose.

2. The bottleneck is almost never "the app tier can't be split." It is a slow query, a missing index, an N+1, an unbounded queue, or a hot row. Microservices fix none of these. They often add latency and complexity without removing the underlying bottleneck, because the query you used to do with one JOIN is now two HTTP calls and a merge in memory.

3. "Independent scaling" usually saves pennies. Unless one workload has a very different resource profile (GPU inference, video transcoding, heavy PDF rendering, and those do deserve extraction, more on that below), the money saved by scaling components separately is a rounding error next to the engineering cost of the split.

Ask around about the last ten "we can't scale" incidents on any team:

Illustrative distribution, not survey data. The point is the shape: check your own team's postmortems against it.

Postmortems overwhelmingly point at the data layer and at specific hot paths. Those are problems solved by indexes, caching, and targeted extraction, not by decomposing the entire application. Only the last bar is the one microservices actually address.

The alternative is not a big ball of mud

The honest objection to monoliths is real. Many of them rot into tangled dependency graphs where everything imports everything and no change is safe. But the cure for bad boundaries is boundaries, not networks. This is the modular monolith: one deployable, internally split into modules that behave like services without the distributed tax.

The rules are few and enforceable:

Modules own their domain. orders/, payments/, inventory/, each with its own controllers, services, repositories, and (this part matters) its own tables. No module touches another module's tables. Ever.
Modules expose a small public API. A facade, a set of exported functions, or in-process events. Everything else is private.
The boundary is enforced by tooling, not discipline. Lint it. Discipline is what fails at 6 p.m. on a Friday before a deadline.

In a TypeScript codebase this is almost free. ESLint's import rules (or dependency-cruiser, or Nx module-boundary tags) turn architectural intent into CI failures:

// eslint.config.ts, the architecture as a lint rule
{
  rules: {
    'import/no-restricted-paths': ['error', {
      zones: [
        // nobody reaches into another module's internals
        { target: './src/modules/orders',
          from:   './src/modules/!(orders)/**/internal/**' },
        { target: './src/modules/payments',
          from:   './src/modules/!(payments)/**/internal/**' },
      ],
    }],
  },
}

// modules/payments/index.ts, the module's entire public surface
export { capturePayment, refundPayment } from './internal/service';
export type { PaymentResult } from './internal/types';
// everything under internal/ is invisible to the rest of the app

For workflows that cross modules, prefer in-process domain events over direct calls. OrderPlaced fires, and the payments and notifications modules subscribe. You get the decoupled shape of an event-driven system with exactly-once delivery, zero brokers, and a stack trace that still makes sense. And if you ever extract a module, the event seam is already exactly where the network will go.

The point worth remembering: the real benefit of microservices is enforced boundaries. A modular monolith gives you the boundaries and lets you skip the enforcement-by-network part. You keep BEGIN ... COMMIT, keep the debugger, keep one pipeline, and keep the option to split later, because well-bounded modules are exactly what extract cleanly.

When microservices are the right call

To be clear, none of this means microservices are bad. Distributed systems are a serious engineering achievement, and the companies running thousands of services are making the correct choice for their situation. The mistake is treating microservices as a maturity milestone rather than a response to specific operational pressure. A three-person startup and Amazon can both be architecting correctly while building completely different systems.

So this is not monolith absolutism. There are legitimate triggers, and you can recognize them because they are pains you have observed, not pains you are predicting:

Team topology pressure. Multiple genuinely independent teams (say 4+ teams, 25+ engineers) whose release schedules keep colliding: release trains, merge queues, "we can't ship because their migration is mid-flight." This is the signal.
A very different workload. One component needs GPUs, a different runtime, 100 times the scale, or a different compliance boundary (card data, health records). Extract that component. One service, not a whole architecture.
Isolation as a product requirement. A truly untrusted or unstable subsystem, like user-submitted code execution or a flaky third-party integration, where limiting the blast radius is worth a process boundary.
A naturally separate lifecycle. A component that ships to a different destination, like an edge worker, an embedded agent, or a public API with its own versioning contract.

Notice what is missing from this list: "microservices are more modern," "we might need to scale someday," "the resume wants Kubernetes." Also notice that the legitimate cases mostly justify extracting one thing. The path is monolith, then modular monolith, then selective extraction, and each step should be forced by evidence.

The decision, honestly drawn:

Every "no" exits early to the cheaper option. Even the final "yes" produces selective extraction, not a nine-box whiteboard.

"We'll just start with microservices so we don't have to migrate later"

This is the most tempting counterargument, so it deserves a direct answer: starting distributed does not avoid the migration. It guarantees a worse one.

Service boundaries are the hardest thing to change in a distributed system. Moving a responsibility between two modules in a monolith is an afternoon and a compiler pass. Moving it between two services is a multi-week project with dual writes and a deprecation window. And early in a product's life, your understanding of the domain is at its lowest. You will draw the boundaries wrong, because you do not yet know where the product is going. Premature microservices do not lock in good architecture. They lock in your earliest misunderstandings, at the layer where mistakes are most expensive to fix.

Field note: even teams famous for distributed systems say this out loud. Amazon's own Prime Video team published a case study describing how they consolidated a distributed, serverless monitoring pipeline into a single monolithic process, reporting an infrastructure cost reduction of over 90% for that workload. The team that helped write the microservices canon will happily merge services when the workload says so.

A monolith with clean modules keeps every option open. Boundaries wrong? Refactor, the compiler has your back. Boundaries right and one team outgrows a module? Extract it, the seam already exists and the events already flow through it. The modular monolith is the reversible decision. The early split is the irreversible one: extracting a well-bounded module is a project, but merging two services whose boundaries turned out wrong is an ordeal. When in doubt, choose the door that swings both ways.

This is not a new position. Martin Fowler made the same argument years ago in Monolith First, and named the cost side of the trade in Microservice Premium: don't pay the premium until complexity forces you to.

What if you are already in microservices?

Then this is not an argument to merge everything tomorrow. Architecture accumulates constraints the same way code does, and a big-bang consolidation is just the original mistake in reverse. Instead, stop the bleeding: resist further fragmentation unless a new split solves a pain you have actually observed. Merge services whose boundaries turned out wrong, especially the ones that always deploy together, since those are a distributed monolith already paying network prices for nothing. And put real investment into the operational floor: tracing, contracts, and local dev, because if you are going to pay the tax, at least collect the benefits. Good architecture is not about maximizing or minimizing service count. It is about matching the system to the organization and the workload you actually have.

What to do on Monday

Default to one deployable. One repo, one pipeline, one process, replicated horizontally behind a load balancer.
Spend the saved effort on module boundaries. Domain-owned folders, private internals, a lint rule that fails the build on cross-module reach-ins, module-owned tables.
Use in-process domain events for cross-module workflows. They are your future extraction seams, and you get them for free.
Fix scaling where scaling actually breaks: indexes, query shape, caching, connection pools, background-job isolation. Measure before you architect.
Write down your extraction triggers now: team count, deploy-contention frequency, divergent workload. That way the future decision is made by evidence instead of fashion.
If a trigger fires, extract one module. Not the system. One module, along an existing seam, with the outbox pattern at the boundary. Then measure again.

Microservices are a genuinely great answer to the question "how do fifty teams ship without meetings?" If that is not your question, do not buy the answer. Build a modular monolith you are proud of, draw your boundaries in code before you draw them over the network, and let the org chart tell you when it is time to split. It will not be shy about it.

Access and Refresh Tokens in Token-Based Authentication

Khaled Saeed — Sat, 02 Aug 2025 22:09:39 +0000

🔑 Token-based authentication has become the standard for modern web applications and APIs. If you've ever wondered why we need both access tokens and refresh tokens, or how they work together to create secure, scalable authentication systems, this article will break it down for you.

🚀 Introduction

🔐 What is Token-Based Authentication?

Token-based authentication is a stateless approach to user authentication where the server generates a cryptographically signed token after successful login. This token contains encoded user information and is sent with every subsequent request to prove the user's identity.

⚖️ Traditional Session vs. Token-Based Authentication

Traditional session-based authentication relies on server-side storage:

👤 User logs in → 🖥️ Server creates a session → 🍪 Session ID stored in cookie
📨 Each request includes the session ID → 🔍 Server looks up session data
💾 Requires server memory/database to maintain session state

Token-based authentication, however, is stateless:

👤 User logs in → 🖥️ Server generates a signed token → 📱 Token sent to client
📨 Each request includes the token → ✅ Server verifies token signature
🚫 No server-side storage needed for authentication state

⚡ The Power of Stateless Authentication

Stateless authentication offers several advantages:

🔄 Scalability: No need to sync session data across multiple servers
🔧 Microservices-friendly: Tokens can be verified independently by any service
📱 Mobile-friendly: Perfect for mobile apps and single-page applications
🔗 Decoupled architecture: Frontend and backend can be completely separate

🎭 Access Tokens vs. Refresh Tokens

Understanding the distinction between these two types of tokens is crucial for implementing secure authentication.

🎫 Access Tokens

Access tokens are short-lived credentials that grant access to protected resources. Think of them as temporary passes that prove you're authorized to perform specific actions.

Key characteristics:

⏰ Lifetime: Typically 15 minutes to 1 hour
💾 Storage: Can be stored in memory, localStorage, or sessionStorage
⚠️ Security risk: Lower (due to short lifespan)
🔄 Usage: Sent with every API request in the Authorization header

🗝️ Refresh Tokens

Refresh tokens are long-lived credentials used exclusively to obtain new access tokens. They're like master keys that can generate new temporary passes.

Key characteristics:

⏳ Lifetime: Days, weeks, or months
🔒 Storage: Should be stored securely (preferably HttpOnly cookies)
🚨 Security risk: Higher (due to long lifespan)
🎯 Usage: Only sent to the authentication endpoint to get new access tokens

Token Flow Diagram

🤔 Why Do We Use Both?

The dual-token approach elegantly solves the security vs. usability dilemma that plagues authentication systems.

🚫 The Problem with Single Token Approaches

Long-lived access tokens create security risks:

💥 If compromised, attackers have extended access
🔒 Difficult to revoke without complex blacklisting
📊 Higher chance of tokens being exposed in logs, URLs, or client-side storage

Short-lived tokens alone hurt user experience:

🔄 Frequent re-authentication required
😤 Poor user experience with constant login prompts
📈 Increased load on authentication servers

⚖️ The Dual-Token Solution

By using both token types, we achieve:

🛡️ Security Benefits:

⏱️ Limited exposure window (short-lived access tokens)
🚫 Ability to quickly revoke access (by invalidating refresh tokens)
🛡️ Reduced risk if access tokens are compromised

😊 Usability Benefits:

✨ Seamless user experience (automatic token refresh)
🚫 No frequent login prompts
📱 Offline capability (cached refresh tokens)

⚡ Performance Benefits:

📉 Reduced authentication server load
🚀 Faster API responses (no session lookups)
💾 Better caching strategies

⚠️ Why Storing Long-lived Access Tokens is Dangerous

Long-lived access tokens in client storage create multiple attack vectors:

🕷️ XSS attacks can steal tokens from localStorage
🦠 Malware can access stored tokens
🕵️ Network interception gives attackers long-term access
📋 Token leakage through logs or error messages

Refresh tokens help by:

🎯 Limiting the blast radius of compromised access tokens
🎛️ Providing centralized revocation control
🔍 Enabling detection of suspicious refresh patterns

🔄 Security Risk Timeline

🔐 Security Tips for Using Refresh Tokens

Implementing refresh tokens securely requires careful consideration of storage, rotation, and monitoring strategies.

🏗️ Token Security Architecture

1. 🏦 Secure Storage Strategies

🖥️ Server-side storage (Recommended):

// Store refresh token in HttpOnly, Secure cookie
app.post('/login', (req, res) => {
  const { accessToken, refreshToken } = generateTokens(user);

  res.cookie('refreshToken', refreshToken, {
    httpOnly: true,     // Prevents XSS access
    secure: true,       // HTTPS only
    sameSite: 'strict', // CSRF protection
    maxAge: 7 * 24 * 60 * 60 * 1000 // 7 days
  });

  res.json({ accessToken });
});

✅ Why HttpOnly cookies are preferred:

🛡️ Immune to XSS attacks
🔄 Automatically sent with requests
🔧 Can be configured with security flags

2. 🔄 Implement Token Rotation

Always issue new refresh tokens when they're used:

app.post('/refresh', (req, res) => {
  const { refreshToken } = req.cookies;

  if (!isValidRefreshToken(refreshToken)) {
    return res.status(401).json({ error: 'Invalid refresh token' });
  }

  // Invalidate old refresh token
  revokeRefreshToken(refreshToken);

  // Generate new tokens
  const { accessToken, refreshToken: newRefreshToken } = generateTokens(user);

  // Store new refresh token
  res.cookie('refreshToken', newRefreshToken, cookieOptions);
  res.json({ accessToken });
});

3. ⏰ Set Proper Expiration and Revocation

📊 Implement sliding expiration:

⏳ Refresh tokens expire after inactivity
👥 Active users get extended sessions
🗑️ Inactive tokens automatically expire

🚪 Provide revocation endpoints:

app.post('/logout', (req, res) => {
  const { refreshToken } = req.cookies;

  // Revoke the refresh token
  revokeRefreshToken(refreshToken);

  // Clear the cookie
  res.clearCookie('refreshToken');
  res.json({ message: 'Logged out successfully' });
});

// Revoke all user sessions
app.post('/logout-all', (req, res) => {
  revokeAllUserRefreshTokens(userId);
  res.json({ message: 'Logged out from all devices' });
});

4. 🕵️ Monitor for Suspicious Activity

Implement detection for unusual patterns:

const detectAnomalies = (userId, metadata) => {
  const { ipAddress, userAgent, location } = metadata;

  // Check for suspicious patterns
  const recentActivity = getUserRecentActivity(userId);

  if (isDifferentLocation(recentActivity.location, location) ||
      isDifferentDevice(recentActivity.userAgent, userAgent)) {

    // Trigger security measures
    sendSecurityAlert(userId);
    requireReAuthentication(userId);
  }
};

5. 🔑 Protect Your Token Secrets

🛡️ Key management best practices:

💪 Use strong, randomly generated signing keys
🔄 Rotate keys regularly
🏦 Store keys in secure key management systems (AWS KMS, HashiCorp Vault)
🚫 Never commit keys to version control
🔧 Use different keys for different environments

// Use environment-specific keys
const JWT_SECRET = process.env.JWT_SECRET;
const REFRESH_SECRET = process.env.REFRESH_SECRET;

// Implement key rotation
const getCurrentSigningKey = () => {
  const keyVersion = process.env.KEY_VERSION || 'v1';
  return process.env[`JWT_SECRET_${keyVersion}`];
};

🚀 Advanced Notes

🔐 OAuth 2.0 Best Practices

When implementing OAuth 2.0, follow these guidelines:

🖥️ Use the Authorization Code flow for server-side applications
📱 Implement PKCE (Proof Key for Code Exchange) for public clients
✅ Validate redirect URIs strictly
🛡️ Use state parameters to prevent CSRF attacks

🎯 JWT vs. Opaque Tokens

🎫 JWT (JSON Web Tokens):

📦 Self-contained and stateless
⚡ Can be verified without database lookup
📏 Larger payload size
⏰ Difficult to revoke immediately

🔒 Opaque Tokens:

🎲 Random string references
🔍 Require database lookup for validation
📦 Smaller payload size
🚫 Easy to revoke immediately

Choose based on your specific requirements for scalability vs. control.

📱 PKCE and Single Page Applications

For SPAs and mobile apps, implement PKCE to enhance security:

// Generate code verifier and challenge
const codeVerifier = generateRandomString(43);
const codeChallenge = base64URLEncode(sha256(codeVerifier));

// Authorization request
const authUrl = `${authEndpoint}?` +
  `client_id=${clientId}&` +
  `redirect_uri=${redirectUri}&` +
  `response_type=code&` +
  `code_challenge=${codeChallenge}&` +
  `code_challenge_method=S256`;

🌐 OAuth 2.0 Flow with PKCE

🔄 JWT vs Opaque Token Decision Tree

📚 Further Reading

To deepen your understanding, explore these resources:

📖 OAuth 2.0 RFC 6749 - The official OAuth 2.0 specification
🛡️ OAuth 2.0 Security Best Practices - Latest security recommendations
🔐 Auth0 Documentation - Comprehensive authentication guides
🎫 JWT.io - JWT debugger and library information
🔒 OWASP Authentication Cheat Sheet - Security-focused authentication guidance

🎯 Conclusion

Understanding access and refresh tokens is fundamental to building secure, scalable authentication systems. The key takeaways are:

🎫 Access tokens should be short-lived and used for API requests
🗝️ Refresh tokens should be long-lived, securely stored, and used only for obtaining new access tokens
⚖️ The dual-token approach balances security, usability, and performance
🔧 Proper implementation requires secure storage, token rotation, monitoring, and key management
📈 Always follow current security best practices and consider your specific use case requirements

Remember that security is not a one-time implementation but an ongoing process. Stay updated with the latest security recommendations, monitor your authentication systems, and always prioritize user data protection.

💬 What's your experience with token-based authentication? Have you encountered specific challenges or implemented interesting solutions? Share your thoughts in the comments below – I'd love to hear about your real-world experiences and lessons learned! 🚀

CSR vs SSR in Next.js

Khaled Saeed — Fri, 18 Jul 2025 10:02:40 +0000

CSR vs SSR in Next.js: From Basics to Advanced Implementation

Introduction

When building modern web applications with Next.js, one of the most crucial decisions you'll make is choosing the right rendering strategy. Client-Side Rendering (CSR) and Server-Side Rendering (SSR) each have their strengths and use cases. This guide will walk you through everything you need to know about CSR vs SSR in Next.js.

What is Rendering?

Rendering is the process of converting your React components into HTML that can be displayed in the browser.

Next.js supports multiple rendering methods:

CSR (Client-Side Rendering)
SSR (Server-Side Rendering)
SSG (Static Site Generation)
ISR (Incremental Static Regeneration)

But let’s focus on CSR and SSR.

What is CSR?

Client-Side Rendering (CSR) is a rendering approach where the initial HTML sent to the browser is minimal, and JavaScript running in the browser generates the content dynamically.

How CSR Works:

What is SSR?

Server-Side Rendering (SSR) is a rendering approach where the HTML is generated on the server for each request, then sent to the browser as a fully-formed page.

How SSR Works:

Key Differences

Aspect	CSR	SSR
Initial Load	Slower (JavaScript must load first)	Faster (HTML ready immediately)
SEO	Poor (content loaded via JS)	Excellent (content in HTML)
Server Load	Lower	Higher
Subsequent Navigation	Faster	Slower
User Experience	Blank page → Content appears	Content appears immediately
Caching	Easier to cache assets	More complex caching

Code Examples

Client-Side Rendering Example

// pages/csr-example.js
import { useState, useEffect } from 'react';

function CSRExample() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    // This runs only on the client
    fetch('/api/data')
      .then(response => response.json())
      .then(data => {
        setData(data);
        setLoading(false);
      });
  }, []);

  if (loading) return <div>Loading...</div>;

  return (
    <div>
      <h1>Client-Side Rendered Page</h1>
      <p>Data: {data?.message}</p>
    </div>
  );
}

export default CSRExample;

Server-Side Rendering Example

// pages/ssr-example.js
function SSRExample({ data }) {
  return (
    <div>
      <h1>Server-Side Rendered Page</h1>
      <p>Data: {data.message}</p>
      <p>Generated at: {data.timestamp}</p>
    </div>
  );
}

// This function runs on the server for each request
export async function getServerSideProps() {
  // Fetch data from external API
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();

  return {
    props: {
      data: {
        ...data,
        timestamp: new Date().toISOString()
      }
    }
  };
}

export default SSRExample;

Performance Comparison

Time to First Byte (TTFB)

CSR: Fast TTFB (but slower content rendering)
SSR: Slower (server processing time)

First Contentful Paint (FCP)

CSR: Slow (wait for JS execution)
SSR: Fast (HTML ready immediately)

Time to Interactive (TTI)

CSR: Slow (dependent on JS bundle size)
SSR: Moderate (hydration required)

Performance Optimization Example

// pages/optimized-ssr.js
import dynamic from 'next/dynamic';

// Lazy load heavy components
// ! `ssr: false` turns the component into a client component.
const HeavyComponent = dynamic(() => import('../components/HeavyComponent'), {
  loading: () => <p>Loading...</p>,
  ssr: false // Disable SSR for this component
});

function OptimizedSSR({ criticalData }) {
  return (
    <div>
      <h1>Optimized SSR Page</h1>
      <div>Critical content: {criticalData.message}</div>

      {/* This component loads only on client */}
      <HeavyComponent />
    </div>
  );
}

export async function getServerSideProps() {
  // Only fetch critical data on server
  const res = await fetch('https://api.example.com/critical-data');
  const criticalData = await res.json();

  return {
    props: {
      criticalData
    }
  };
}

export default OptimizedSSR;

When to Use What

Use CSR When:

Building a dashboard or admin panel
User interaction is frequent
SEO is not a priority
You need real-time updates
Building a Single Page Application (SPA)

Use SSR When:

SEO is crucial
First-page load performance matters
Content changes frequently
Building e-commerce sites
Social media sharing is important

Advanced Topics

Dynamic Imports for Code Splitting

// Advanced code splitting example
import dynamic from 'next/dynamic';
import { useState } from 'react';

const DynamicChart = dynamic(() => import('../components/Chart'), {
  loading: () => <p>Loading chart...</p>,
  ssr: false
});

const DynamicTable = dynamic(() => import('../components/Table'), {
  loading: () => <p>Loading table...</p>
});

function AdvancedCSR() {
  const [view, setView] = useState('chart');

  return (
    <div>
      <nav>
        <button onClick={() => setView('chart')}>Chart View</button>
        <button onClick={() => setView('table')}>Table View</button>
      </nav>

      {view === 'chart' && <DynamicChart />}
      {view === 'table' && <DynamicTable />}
    </div>
  );
}

Streaming SSR (React 18+)

// pages/streaming-ssr.js
import { Suspense } from 'react';

function SlowComponent() {
  // Simulate slow component
  await new Promise((res) => setTimeout(res, 3000));
  return <div>Slow loading content</div>;
}

function StreamingSSR() {
  return (
    <div>
      <h1>Streaming SSR Example</h1>
      <p>This content loads immediately</p>

      <Suspense fallback={<div>Loading slow content...</div>}>
        <SlowComponent />
      </Suspense>
    </div>
  );
}

export default StreamingSSR;

Edge-Side Rendering with Middleware

// middleware.js
import { NextResponse } from 'next/server';

export function middleware(request) {
  const country = request.geo?.country || 'US';

  // Customize response based on location
  const response = NextResponse.next();
  response.headers.set('x-country', country);

  return response;
}

export const config = {
  matcher: '/api/:path*'
};

// Note: Middleware runs before requests but cannot render HTML. it's useful for things like redirects, geolocation, or A/B testing logic.

Best Practices

1. Choose the Right Rendering Strategy

// Decision matrix in code
const getRenderingStrategy = (pageType, requirements) => {
  if (requirements.seo && requirements.freshData) {
    return 'SSR';
  }

  if (requirements.interactivity && !requirements.seo) {
    return 'CSR';
  }

  return 'Hybrid';
};

2. Optimize Bundle Size

// next.config.js
module.exports = {
  experimental: {
    css: true,
  },
  webpack: (config) => {
    config.optimization.splitChunks.chunks = 'all';
    return config;
  }
};

3. Implement Progressive Enhancement

// Progressive enhancement example
function ProgressiveForm() {
  const [isClient, setIsClient] = useState(false);

  useEffect(() => {
    setIsClient(true);
  }, []);

  return (
    <form>
      <input type="text" name="name" required />
      <input type="email" name="email" required />

      {/* Enhanced features only on client */}
      {isClient && (
        <div>
          <AutoComplete />
          <RealTimeValidation />
        </div>
      )}

      <button type="submit">Submit</button>
    </form>
  );
}

4. Error Handling and Loading States

// Comprehensive error handling
function RobustSSR({ data, error }) {
  if (error) {
    return <ErrorComponent error={error} />;
  }

  return (
    <div>
      <h1>Robust SSR Page</h1>
      <p>{data?.message}</p>
    </div>
  );
}

export async function getServerSideProps() {
  try {
    const res = await fetch('https://api.example.com/data');

    if (!res.ok) {
      throw new Error('Failed to fetch data');
    }

    const data = await res.json();

    return {
      props: { data }
    };
  } catch (error) {
    return {
      props: {
        error: error.message
      }
    };
  }
}

Conclusion

Choosing between CSR and SSR in Next.js isn't about picking one over the other, it's about understanding your application's requirements and users needs. Here's a quick recap:

Use SSR for SEO-critical pages and better initial load performance
Use CSR for highly interactive applications where SEO isn't a priority

Next.js makes it easy to implement any of these strategies, and you can even mix them within the same application. The key is to profile your application, understand your users' journey, and choose the rendering strategy that provides the best user experience.

Remember: Performance is not just about fast loading, it's about the right content being available at the right time for your users.

📚 Further Reading: Server and Client Components

✨Mood-based Travel Poster Generator✈️

Khaled Saeed — Fri, 11 Jul 2025 22:27:13 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

What I Built

I built a Mood-based Travel Poster Generator, an AI-powered app that creates unique travel posters based on the user's current mood. I used this prompt in Google AI Studio:

"Build a web app that take the user current mood. Based on the mood, the app suggests a matching travel destination and generates a travel poster using Imagen. The image should reflect both the emotion and the destination’s essence (e.g., 'melancholic' → rainy Venice; 'curious' → ancient ruins in Peru). Include a 'Regenerate Poster' button to create a new variation. Add a simple UI with a text input and a dropdown of mood presets."

Demo

My Experience

This project was a great exercise in blending creativity and technical design. I learned how to:

Structure prompts for more stylized image outputs
Use the Imagen API effectively for emotion-to-visual mapping

Thanks to Google AI Studio and DEV for making this learning experience fun and creative!

Automatically Set Access Tokens in Postman After Login (No More Copy-Paste)

Khaled Saeed — Mon, 07 Jul 2025 08:44:20 +0000

Automatically Set Access Tokens in Postman After Login (No More Copy-Paste!)

If you're working with APIs that use access tokens (like JWTs), you've probably dealt with the annoying routine:

Send a POST /login request
Copy the access token from the response
Paste it into the Authorization header of every other request

😩 Repeating this every time the token expires gets old fast.

🚀 What if you could automate it?

This guide shows you how to extract the token automatically after login and set it as a dynamic environment variable in Postman. Then you can reuse it in any request, no manual copying needed!

📦 Step 1: Create or Select a Postman Environment

Click New Environment in the top right of Postman
Add a new environment (e.g., Local API)
Add a variable called accessToken, set the type to secret, and leave the initial value empty

🧪 Step 2: Add a Script to Your Login Request

In your POST /api/v1/auth/login request, go to the Scripts section, then select the Post-response tab and add this:

const res = pm.response.json();

if (res.success && res.data && res.data.accessToken) {
    pm.environment.set("accessToken", res.data.accessToken);
    console.log("✅ accessToken saved to environment");
} else {
    console.log("❌ Failed to extract accessToken");
}

💬 What does this script do?

It parses the JSON response returned from your login request.
It checks if the response contains a valid accessToken.
If so, it stores the token in your environment as accessToken, making it available across all your other API requests.
You’ll see a confirmation in the Postman console.

You can also save more fields if needed:

pm.environment.set("refreshToken", res.data.refreshToken);
pm.environment.set("userId", res.data.user.id);

🧷 Step 3: Use the Token in Other Requests

Once the accessToken is saved as an environment variable, you can inject it automatically into your other requests.

✅ Option 1: Use the Authorization Tab

In your API request, go to the Authorization tab
Select Bearer Token for the Auth Type
Set the token to {{accessToken}}

✅ Option 2: Set the Header Manually

Instead of using the Authorization tab, you can manually add a header:

Authorization: Bearer {{accessToken}}

That’s it! Now your token will automatically update after each login and be used wherever {{accessToken}} is referenced.

🎁 Bonus: Automate Token Refresh (Optional)

If your API provides a refreshToken flow (e.g., POST /refresh-token), you can automate that too!

Create a separate request for refreshing the token, and add a Post-response script:

const res = pm.response.json();

if (res.newAccessToken) {
    pm.environment.set("accessToken", res.newAccessToken);
    console.log("🔄 accessToken refreshed and updated");
}

Then you can call this request manually or as a pre-request step if a 401 is detected.

🧠 Summary

Here’s what you’ve accomplished:

✅ Automatically saved your accessToken from the login response

✅ Injected the token into future requests using dynamic variables

✅ Removed the need for manually copying and pasting tokens

✅ Optionally prepared for refresh token logic

🏁 Conclusion

This small but powerful automation trick can save you a lot of time, especially when working with authenticated APIs during development or testing.

No more expired tokens or constant back-and-forth between tabs!

Let me know if you’d like a follow-up guide on chaining token refresh logic or fully automating session flows in Postman and I’d love to hear how you’re using Postman in your workflow.

Happy testing! 🙌