Structured data tells search engines what a page actually contains — an article, its author, its publish date — instead of leaving them to infer it from markup. In Google it is what makes a result eligible for rich treatment: the author line, the date, the breadcrumb trail. The format Google recommends is JSON-LD, placed inside a `script` tag in the page head.

## What to Add

For a blog, three schema types cover most of the value:

- `BlogPosting` on each article
- `BreadcrumbList` on any nested page
- `Person` or `Organization` once, for the site owner

## The Article Payload

```typescript
function articleJsonLd(post: Post) {
  return {
    '@context': 'https://schema.org',
    '@type': 'BlogPosting',
    headline: post.title,
    description: post.excerpt,
    datePublished: post.createdAt,
    dateModified: post.updatedAt,
    author: { '@type': 'Person', name: 'Your Name' },
    mainEntityOfPage: `https://example.com/blog/${post.slug}`,
  };
}
```

## Rendering It

In the Pages Router, render it inside `next/head`. Serialize with a helper that escapes any opening angle bracket in the JSON string, so a value containing markup cannot terminate the script tag early:

```tsx
// escape "<" as its unicode form before injecting
const toSafeJson = (data: object) =>
  JSON.stringify(data).replaceAll('<', String.fromCodePoint(0x5c) + 'u003c');

<Head>
  <script
    type="application/ld+json"
    dangerouslySetInnerHTML={{ __html: toSafeJson(articleJsonLd(post)) }}
  />
</Head>
```

In the App Router, render the same script tag directly in the server component.

## Verifying

- Rich Results Test — paste the URL, confirm the type is detected with no errors
- Search Console, Enhancements — which structured-data types Google found, and any warnings

## Common Mistakes

- Dates not in ISO 8601 (`2026-08-24T11:35:00Z`)
- A `headline` longer than 110 characters — Google truncates it
- Structured data describing content that is not visible on the page — a policy violation

## Conclusion

A few hundred bytes of JSON-LD per page is one of the highest-leverage SEO changes for a blog: cheap to add, easy to validate, and it directly affects how results are displayed.

Adding JSON-LD Structured Data to a Next.js Blog

Short answer: yes, but "legacy" does not mean "dead." The Pages Router is still supported, still receives bug fixes, and still runs a large share of production Next.js apps. What it does not get is new features — those all land in the App Router.

## What "Legacy" Actually Means

- No forced migration, no deprecation date
- New APIs (Server Components, Server Actions, partial prerendering) are App Router only
- The official docs now frame the migration guide as something you do "when you're ready"

## When to Stay

- The app is stable and the team is productive
- Nothing on the roadmap needs an App-Router-only feature
- `getServerSideProps` / `getStaticProps` cover your data-fetching needs

Rewriting a working Pages Router app for its own sake is rarely worth the regression risk.

## When to Move

- You want React Server Components to cut client-side JavaScript
- You need streaming or nested layouts that persist across navigation
- You are starting a new section of the app anyway

## The Incremental Path

`app/` and `pages/` coexist in the same project. A route in `app/` wins over the same route in `pages/`. Migrate leaf pages first, keep authentication and complex legacy flows in `pages/`, and move shared layouts last.

The most common App Router pain in 2026 is not instability — it is the caching model. Multiple cache layers interact differently depending on fetch options and rendering mode, and that is the part worth learning before you start.

## Conclusion

Treat the Pages Router like a stable dependency you are slowly paying down, not an emergency. New surfaces in `app/`, existing ones migrated on their own schedule.

Is the Next.js Pages Router Legacy in 2026?

Bun is a JavaScript runtime built on JavaScriptCore, with a bundler, test runner, and package manager built in. As of Bun 1.4 it runs most NestJS apps unmodified, install times drop sharply, and request throughput on I/O-heavy endpoints is meaningfully higher.

## What Works

- **`bun install`** reads the same `package.json`, produces `bun.lockb`, and is an order of magnitude faster on a cold cache
- **Running the app**: `bun run start:dev` works with no code changes on a CLI-generated project
- **TypeScript execution**: Bun runs `.ts` directly, so `ts-node` is no longer needed for seed and migration scripts
- **`@nestjs/platform-express` and `@nestjs/platform-fastify`** both boot

## What Doesn't (Yet)

- Native addons with a `binding.gyp` can fail to load — check anything doing image processing, crypto, or native DB drivers
- `@nestjs/testing` still pulls in Jest; `bun test` is not a drop-in replacement for the full Nest testing setup
- A few Express middleware packages assume Node internals and throw at startup

## Dockerfile

```dockerfile
FROM oven/bun:1-alpine
WORKDIR /app
COPY package.json bun.lockb ./
RUN bun install --frozen-lockfile --production
COPY . .
RUN bun run build
USER bun
CMD ["bun", "dist/main.js"]
```

The resulting image is roughly 25–40% smaller than the Node equivalent and starts faster.

## Where the Win Is

The gains show up in process startup and I/O-bound request handling — API gateways, proxies, endpoints that mostly wait on a database. CPU-bound work sees little difference. Benchmark the endpoints that actually matter for your service before committing.

## Conclusion

For a standard NestJS REST API, moving to Bun is mostly a CI and Dockerfile change. Run it on a lower-stakes service first and validate every native dependency.

Running NestJS on Bun: What Works and What Doesn't

When you put an LLM behind your own API, you almost always want to stream the response — waiting 20 seconds for a full completion makes the UI feel broken. Server-Sent Events (SSE) are the simplest transport: one-way, text-based, and supported by every browser through `EventSource`. It is also what the Claude and OpenAI APIs use natively.

## Why SSE Instead of WebSockets

- LLM output is one-directional — the client sends nothing mid-stream
- Runs over plain HTTP, no upgrade handshake
- `EventSource` reconnects automatically

## The Controller

NestJS has first-class SSE support through the `@Sse()` decorator, which returns an `Observable`:

```typescript
import { Sse, MessageEvent, Query } from '@nestjs/common';
import { Observable } from 'rxjs';

@Sse('chat')
chat(@Query('prompt') prompt: string): Observable<MessageEvent> {
  return this.llmService.streamReply(prompt);
}
```

## The Service

Wrap the Anthropic SDK's stream in an RxJS `Observable`:

```typescript
import Anthropic from '@anthropic-ai/sdk';

@Injectable()
export class LlmService {
  private client = new Anthropic();

  streamReply(prompt: string): Observable<MessageEvent> {
    return new Observable((subscriber) => {
      const stream = this.client.messages.stream({
        model: 'claude-opus-5',
        max_tokens: 4096,
        messages: [{ role: 'user', content: prompt }],
      });

      stream.on('text', (chunk) => subscriber.next({ data: chunk }));
      stream.on('end', () => subscriber.complete());
      stream.on('error', (err) => subscriber.error(err));

      return () => stream.abort(); // runs when the client disconnects
    });
  }
}
```

## Consuming It

```typescript
const source = new EventSource(`/llm/chat?prompt=${encodeURIComponent(input)}`);
source.onmessage = (e) => appendToOutput(e.data);
source.onerror = () => source.close();
```

## Things to Watch

- Keep `max_tokens` bounded — a runaway generation holds a connection open
- Abort the upstream stream on disconnect (the cleanup function above)
- Rate-limit the endpoint; every open stream consumes a connection and a provider quota slot

## Conclusion

The `@Sse()` decorator plus an `Observable` wrapper gives you token-by-token delivery in about 30 lines, with cancellation and backpressure handled by RxJS.

Streaming Claude Responses Through NestJS with Server-Sent Events

TypeORM has been the default ORM for NestJS since the beginning, but Drizzle has overtaken it in new projects — it passed Prisma in weekly npm downloads in early 2026. Drizzle is a SQL-first query builder with full TypeScript inference and no decorators or metadata reflection.

## Why Teams Are Switching

- Schema is plain TypeScript — no decorators, no `reflect-metadata`
- Queries are typed end to end; the result type is inferred from the query itself
- Migrations are generated as readable SQL you can edit
- Smaller runtime and faster cold starts — relevant for serverless and edge

## Defining a Schema

```typescript
import { pgTable, uuid, varchar, text, boolean, timestamp } from 'drizzle-orm/pg-core';

export const posts = pgTable('posts', {
  id: uuid('id').defaultRandom().primaryKey(),
  title: varchar('title').notNull(),
  slug: varchar('slug').notNull().unique(),
  content: text('content').notNull(),
  published: boolean('published').default(false).notNull(),
  createdAt: timestamp('created_at').defaultNow().notNull(),
});
```

## Wiring It Into NestJS

Expose the Drizzle instance as an injectable provider:

```typescript
import { drizzle } from 'drizzle-orm/node-postgres';
import { Pool } from 'pg';

export const DrizzleProvider = {
  provide: 'DB',
  useFactory: () => {
    const pool = new Pool({ connectionString: process.env.DATABASE_URL });
    return drizzle(pool, { schema });
  },
};
```

## Querying

```typescript
@Injectable()
export class BlogService {
  constructor(@Inject('DB') private db: NodePgDatabase<typeof schema>) {}

  findPublished() {
    return this.db.query.posts.findMany({
      where: eq(posts.published, true),
      orderBy: desc(posts.createdAt),
    });
  }
}
```

## Migrating From TypeORM

There is no automatic converter. The practical path:

1. Recreate entities as Drizzle schema files
2. Run `drizzle-kit introspect` against the existing database and diff it against your hand-written schema
3. Replace repository calls service by service — both ORMs can share the same connection pool during the transition

## Conclusion

Drizzle trades TypeORM's Active Record convenience for explicit SQL and stronger inference. For a new NestJS service, or one where the query layer has become hard to reason about, it is the current default.

Drizzle ORM with NestJS: Migrating Away from TypeORM

shadcn/ui is not a component library in the traditional sense. Instead of installing a package and importing components, you copy the source code directly into your project. This means you own every component and can customize it freely.

## Why shadcn/ui

- No version lock-in — components live in your codebase
- Built on Radix UI primitives for accessibility out of the box
- Styled with Tailwind CSS, fully themeable via CSS variables
- Works seamlessly with Next.js and TypeScript

## Installation

Initialize shadcn/ui in a Next.js project:

```bash
npx shadcn@latest init
```

This sets up Tailwind, adds a `components/ui/` directory, and configures the `cn()` utility.

## Adding Components

Add only what you need — each component is added individually:

```bash
npx shadcn@latest add button
npx shadcn@latest add dialog
npx shadcn@latest add input
```

Each command writes the component source into `components/ui/`.

## Usage

Components are used like any local React component:

```typescript
import { Button } from "@/components/ui/button"
import { Input } from "@/components/ui/input"

export function LoginForm() {
  return (
    <form>
      <Input placeholder="Email" type="email" />
      <Button type="submit">Sign In</Button>
    </form>
  )
}
```

## Theming

Colors, radius, and fonts are controlled via CSS variables in `globals.css`. Switching between light and dark mode is a single class toggle on the root element.

## Conclusion

shadcn/ui shifts the ownership model — you get production-ready, accessible components without sacrificing control. It pairs especially well with Next.js and TypeScript projects where long-term maintainability matters.

Building UI Components with shadcn/ui

Next.js offers multiple data-fetching strategies. Choosing the right one significantly impacts performance, SEO, and user experience.

## getServerSideProps

Runs on every request — ideal for dynamic, user-specific, or frequently updated data:

```typescript
export const getServerSideProps: GetServerSideProps = async (context) => {
  const data = await fetchFromAPI();
  return { props: { data } };
};
```

## getStaticProps

Runs at build time — ideal for content that rarely changes:

```typescript
export const getStaticProps: GetStaticProps = async () => {
  const posts = await fetchPosts();
  return { props: { posts }, revalidate: 60 };
};
```

## When to Use Which

- **getServerSideProps**: authenticated pages, real-time data, personalized content
- **getStaticProps**: blogs, docs, marketing pages — anything cacheable
- **Client-side fetch**: user interactions, dashboards, data that loads after render

## CORS Consideration

When using getServerSideProps, the fetch runs on the Node.js server — not the browser. This means CORS headers are irrelevant for server-side calls, and you can hit internal APIs directly without exposing them publicly.

## Conclusion

Combining SSR and SSG in the same Next.js app lets you optimize each page independently — static where possible, dynamic where necessary.

Server-Side Rendering with Next.js

JWT (JSON Web Token) is a compact, stateless authentication mechanism widely used in REST APIs. NestJS makes it straightforward to implement with its built-in Guards and Passport integration.

## Installation

```bash
npm install @nestjs/jwt @nestjs/passport passport passport-jwt
npm install -D @types/passport-jwt
```

## Setting Up the Auth Module

Configure JwtModule with a secret and expiration:

```typescript
JwtModule.register({
  secret: process.env.JWT_SECRET,
  signOptions: { expiresIn: '7d' },
})
```

## JWT Strategy

The strategy validates the token and extracts the payload on every protected request:

```typescript
@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
  constructor() {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
      secretOrKey: process.env.JWT_SECRET,
    });
  }

  async validate(payload: { sub: string; email: string }) {
    return { id: payload.sub, email: payload.email };
  }
}
```

## Protecting Routes

Apply the JwtAuthGuard to any controller or route that requires authentication:

```typescript
@UseGuards(JwtAuthGuard)
@Get('profile')
getProfile(@Request() req) {
  return req.user;
}
```

## Conclusion

NestJS + JWT provides a clean, decorator-driven authentication layer that scales well across large APIs.

JWT Authentication with NestJS

Using Docker Compose to set up PostgreSQL in a development environment greatly simplifies version management and portability.

## docker-compose.yml

```yaml
version: '3.8'
services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: myapp
    ports:
      - '5432:5432'
    volumes:
      - postgres_data:/var/lib/postgresql/data
volumes:
  postgres_data:
```

## Advantages

- Different PostgreSQL versions for different projects
- Start/stop with a single command
- Data persistence with volumes

## Connection

While the container is running, you can connect via `localhost:5432`.

Setting Up PostgreSQL with Docker

NestJS is a powerful backend framework for Node.js. Combined with TypeORM, database operations become extremely clean and type-safe.

## Installation

```bash
npm install @nestjs/typeorm typeorm pg
```

## Defining Entities

In TypeORM, an entity represents a table in the database. Thanks to decorators, schema definition is done directly on TypeScript classes.

## Repository Pattern

In NestJS, you use TypeORM repositories by injecting them. This isolates the service layer from database details and makes testing easier.

## Conclusion

The NestJS + TypeORM combination provides a solid foundation for large-scale backend applications.

Blog