DEV Community: Carlos Oliva Pascual

The Developer Skills AI Can't Replace in 2026 (And the Ones It Already Has)

Carlos Oliva Pascual — Thu, 24 Sep 2026 07:35:45 +0000

The question "will AI replace developers?" is the wrong question. The right one: which parts of development are already automated, which are becoming automated, and which require human judgment for the foreseeable future?

The honest answer is more nuanced than either the doom camp or the optimism camp admits.

What AI Has Already Replaced

Boilerplate and scaffolding. CRUD endpoints, form validation, database migrations, component scaffolding — all faster and often better when generated. A developer who spends three hours hand-writing a REST API in 2026 is not being thorough. They're not using their time well.

Implementing known patterns. Authentication flows, payment integrations, file uploads, rate limiting — these are solved problems. AI has read all the docs and can produce working code faster than any developer can look them up and type.

Writing tests for existing code. Describing a function's behavior and asking Claude to generate a test suite is one of the highest-ROI uses of AI tools. The tests are often better than what a pressed developer writes in a hurry.

Explaining unfamiliar code. Dropping an unfamiliar codebase into Claude and asking it to explain what a function does — this works. Not perfect, but dramatically faster than reading code cold.

What AI Has Not Replaced

Knowing what to build

This is the most underrated skill in software development, and AI doesn't touch it.

A business says they need a "dashboard." AI can build a dashboard. But whether a dashboard is actually what the business needs — that requires understanding context that exists only in human conversation and business knowledge.

The developer who can hear "we need to track user engagement better" and translate it into three concrete, buildable features with an ROI estimate is doing something AI cannot do. The business context doesn't exist in the codebase.

Architecture with long-term consequences

AI will help you design a system. It will reason through trade-offs and explain implications. What it doesn't have is skin in the game.

An experienced developer knows the "clever" solution is usually wrong three months later. They've been in the meeting where a technical decision from two years ago is now costing the company six figures to unwind. That scar tissue informs judgment in a way no training data replicates.

Ask Claude to design a multi-tenant architecture — it gives you valid options. Ask a senior developer who has run multi-tenant SaaS in production — they pick one and tell you exactly what will go wrong in 18 months and why it's still the right choice. Different thing.

Debugging novel failures

This is the clearest dividing line.

AI is excellent at debugging known patterns — N+1 queries, race conditions in Promise.all, stack overflows in recursion. These have signatures in training data.

AI struggles with failures it hasn't seen before. The production bug that only manifests under a specific combination of load, timezone, and third-party API behavior. The memory leak that takes six hours to appear and disappears when you add logging.

These require forming and testing hypotheses in an environment you can observe but AI cannot. Holding five competing explanations, designing a minimal test case for each, systematically eliminating them. That remains fundamentally human.

Evaluating AI output

Here's the recursive skill: using AI tools effectively requires the ability to evaluate what they produce.

A developer who can't tell whether Claude's output is correct, secure, and idiomatic is in a worse position than someone who doesn't use AI at all — they're shipping bugs faster.

The developers who get the most out of AI coding tools are the ones with enough experience to catch the 10% that's subtly wrong. Junior developers who rely on AI without the ability to evaluate the output are building on a foundation they don't understand.

Security threat modeling

AI knows the OWASP top 10. It will tell you to sanitize inputs and use parameterized queries.

What it doesn't know is your threat model. Who are your adversaries? What's the actual value of the data you're protecting? Which attack vectors are realistic given your deployment context? Those are judgment calls that depend on business context AI doesn't have.

The Shift in What Matters

Skills becoming less valuable:

Raw typing speed
Memorizing API signatures
Writing boilerplate from scratch
Basic algorithmic problem-solving

Skills becoming more valuable:

Problem decomposition — breaking ambiguous requirements into buildable specs
System thinking — how components interact at scale
Evaluation — reading code and knowing if it's right
Communication — translating between business requirements and technical constraints
Taste — knowing what good software feels like, not just what works today

That last one is hard to define but easy to recognize. A developer with taste looks at a system and sees the decisions that will cause pain in 18 months. They choose the boring technology that will still be maintainable when they're gone. They push back on features that solve the wrong problem.

That judgment isn't in the training data.

What This Means

The developers struggling in 2026 are the ones who defined their value by output speed. AI has compressed that advantage.

The developers doing well defined their value by outcomes — whether the right thing got built, in a way that lasts, solving a real problem. AI makes them faster at execution without touching their core value.

Using AI tools effectively isn't about replacing your judgment. It's about spending less time on parts that don't require it, so you have more capacity for parts that do.

AI has replaced the parts of development that were always commodities — the typing, the boilerplate, the lookups. It hasn't replaced the judgment that made good developers valuable in the first place.

What's changed is that the commodity work is now visibly commodity. There's no longer anywhere to hide behind volume. The freed-up time either becomes room for higher-leverage work, or it becomes visible slack that's hard to justify.

The developers using that time to get better at architecture, system design, and product thinking are compounding their advantage.

Full article: stacknotice.com/blog/developer-skills-ai-cant-replace-2026

Spec-Driven Development with Claude Code (2026): Write the Spec, Ship the Code

Carlos Oliva Pascual — Mon, 07 Sep 2026 14:04:50 +0000

There's a pattern separating developers who get consistently good output from Claude Code and those who keep fighting it: the ones who get good output write the spec first.

Not a prompt. A spec. There's a difference.

A prompt is "build me a user authentication system with email and password." A spec is a structured document describing what the system needs to do, what it connects to, what the edge cases are, and what done looks like. One produces a generic scaffold. The other produces code that fits your actual project.

Why Prompting Alone Breaks Down

When you prompt without context, Claude fills the gaps with assumptions. Reasonable ones — but not yours.

"Add a checkout flow" produces Stripe integration. But maybe you're on Paddle. Maybe checkout needs to hit three internal services. Maybe you have a custom pricing model. Claude doesn't know.

The result: three rounds of corrections steering output toward what you actually wanted. Fix the input, not the output.

What a Spec Looks Like

# Feature: User Subscription Management

## What it does
Users can subscribe to plans (free, pro, enterprise), upgrade/downgrade,
and cancel. Billing through Stripe. Upgrades take effect immediately,
downgrades at end of billing period.

## Data model
- User has one active Subscription
- Subscription: planId, status, stripeSubscriptionId, currentPeriodEnd
- Existing: users table (Drizzle + Postgres), auth via Better Auth

## Business rules
- Free plan: no credit card required
- Cancellation: user keeps access until currentPeriodEnd
- Webhook events: checkout.session.completed, subscription.updated, subscription.deleted
- Failed payments: email after 3 attempts, downgrade to free

## What NOT to build
- No trial periods (adding later)
- No team/seat billing (separate feature)
- No invoice history UI (use Stripe portal)

## Done looks like
- Free → pro in under 30 seconds
- Webhook handles duplicate events without duplicate records
- Cancel shows when access expires, not just "cancelled"

This takes 20-30 minutes to write. It saves 2-3 hours of iteration.

The Workflow

Step 1: Spec in CLAUDE.md or specs/[feature].md

For project-wide context, CLAUDE.md. For a specific feature, a dedicated spec file you reference explicitly.

Step 2: Plan Mode before any code

/plan

Read specs/subscription-management.md and tell me:
1. What files you'll create or modify
2. What the webhook handler will look like
3. What migrations are needed
4. What you'll skip and why

If Claude's plan doesn't match your mental model, the spec is underspecified. Fix the spec, not the code.

Step 3: Execute in sections

Implement the database schema from the spec.
Use Drizzle. Don't touch the API layer yet.

Review. Then add the endpoint. Review. Then the webhook. Section by section, not all at once.

Step 4: Use the spec as the test oracle

Generate Vitest tests from specs/subscription-management.md.
Each business rule should have at least one test.
Focus on webhook idempotency and cancel flow timing.

A Reusable Spec Template

# Feature: [Name]

## Context
[What exists, what this builds on, what the user need is]

## What it does
[Bullet list of capabilities from the user's perspective]

## Technical constraints
[Existing stack, services in use, things not to change]

## Data model
[New tables/fields, changes to existing]

## Business rules
[Non-obvious logic — edge cases, timing, error states]

## What NOT to build
[Explicit exclusions]

## Done looks like
[Observable, testable acceptance criteria]

Specs for Bugs Too

# Bug: Dashboard shows wrong totals with date filter

## Current behavior
"Last 30 days" totals don't match raw DB query. Off by ~3-5%.

## Expected behavior
Match: SELECT SUM(amount) FROM orders WHERE created_at >= NOW() - INTERVAL '30 days'

## What I've checked
- Query in analytics.ts line 84 looks correct
- Issue only with date filter, not "All time"
- Started after timezone migration on 2026-08-15
- Postgres: UTC, app: Europe/Madrid

## Hypothesis
Date filter applies timezone offset twice.

## What I need
Find where the double offset happens and fix it.
Don't change chart rendering logic — only query/date handling.

When Specs Don't Help

Genuine exploration — you don't know what you want yet. Free-form prompting is fine.
Trivial tasks under 10 minutes. Overhead isn't worth it.

My threshold: if implementing this wrong would cost more than an hour to fix, write a spec.

The cognitive shift: you're doing the hard thinking before code exists, not after. Claude is capable of building complex systems correctly. The limiting factor is usually underspecified input.

Specs fix the input.

Full article: stacknotice.com/blog/spec-driven-development-claude-code-2026

TanStack Start (2026): Full-Stack React Without Next.js

Carlos Oliva Pascual — Tue, 01 Sep 2026 09:21:31 +0000

Next.js has dominated the full-stack React space for years. TanStack Start is the first serious alternative built from scratch for the current era — type-safe routing, server functions with real TypeScript inference, and a deployment model that runs anywhere Nitro runs.

TanStack Start is built on three pieces: TanStack Router for client-side routing, Vinxi as the application bundler, and Nitro as the server engine.

Project Setup

npx create-tsrouter-app@latest my-app --template start-basic
cd my-app
npm install
npm run dev

Project structure:

app/
├── routes/
│   ├── __root.tsx          # Root layout
│   ├── index.tsx           # /
│   └── posts/
│       ├── index.tsx       # /posts
│       └── $postId.tsx     # /posts/:postId — typed param
├── client.tsx
├── router.tsx
└── ssr.tsx
app.config.ts               # Vinxi config — adapters, plugins

File-Based Routing — Typed Params

// app/routes/posts/$postId.tsx
import { createFileRoute } from '@tanstack/react-router'
import { fetchPost } from '../serverFunctions/posts'

export const Route = createFileRoute('/posts/$postId')({
  loader: ({ params }) => fetchPost(params.postId),  // params.postId is typed
  component: PostPage,
})

function PostPage() {
  const post = Route.useLoaderData()  // typed from loader return
  const { postId } = Route.useParams()  // typed, no casting

  return <article><h1>{post.title}</h1><p>{post.content}</p></article>
}

The key difference from Next.js: Route.useLoaderData() is typed from the loader's return type automatically.

Server Functions

Server functions run on the server but are callable from the client — with full TypeScript inference on both sides.

// app/serverFunctions/posts.ts
import { createServerFn } from '@tanstack/start'
import { z } from 'zod'

export const fetchPost = createServerFn({ method: 'GET' })
  .validator(z.object({ postId: z.string() }))
  .handler(async ({ data }) => {
    const post = await db.query.posts.findFirst({
      where: (posts, { eq }) => eq(posts.id, data.postId),
      with: { author: true }
    })
    if (!post) throw new Error('Post not found')
    return post
  })

export const createPost = createServerFn({ method: 'POST' })
  .middleware([requireAuth])
  .validator(z.object({ title: z.string().min(1), content: z.string().min(1) }))
  .handler(async ({ data, context }) => {
    return db.insert(posts).values({ ...data, authorId: context.user.id }).returning()
  })

Using in a component:

function NewPostPage() {
  const navigate = useNavigate()
  const create = useServerFn(createPost)

  async function handleSubmit(e: React.FormEvent<HTMLFormElement>) {
    e.preventDefault()
    const data = new FormData(e.currentTarget)
    const post = await create({
      data: { title: data.get('title') as string, content: data.get('content') as string }
    })
    navigate({ to: '/posts/$postId', params: { postId: post.id } })
  }

  return (
    <form onSubmit={handleSubmit}>
      <input name="title" required />
      <textarea name="content" required />
      <button type="submit">Publish</button>
    </form>
  )
}

Typed Search Params

const searchSchema = z.object({
  page: z.number().default(1),
  tag: z.string().optional(),
  sort: z.enum(['newest', 'popular']).default('newest'),
})

export const Route = createFileRoute('/posts/')({
  validateSearch: searchSchema,
  loader: async ({ search }) => {
    // search.page, search.tag, search.sort — all typed
    return fetchPosts({ data: { ...search } })
  },
  component: PostsList,
})

Contrast with Next.js useSearchParams() which returns URLSearchParams — strings only, no validation.

Streaming SSR

export const Route = createFileRoute('/dashboard')({
  loader: async () => {
    const [stats, activityPromise] = await Promise.all([
      fetchDashboardStats({ data: {} }),
      defer(fetchRecentActivity({ data: {} }))  // streams later
    ])
    return { stats, activityPromise }
  },
  component: Dashboard,
})

function Dashboard() {
  const { stats, activityPromise } = Route.useLoaderData()

  return (
    <div>
      <StatsPanel stats={stats} />  {/* Immediate */}
      <Suspense fallback={<ActivitySkeleton />}>
        <Await promise={activityPromise}>
          {(activity) => <ActivityFeed activity={activity} />}
        </Await>
      </Suspense>
    </div>
  )
}

Deployment

// app.config.ts
export default defineConfig({
  server: {
    preset: 'vercel',  // or 'cloudflare-pages', 'aws-lambda', 'bun', 'node-server'
  }
})

No vendor lock-in — switching deployment targets is a config change.

TanStack Start vs Next.js

	TanStack Start	Next.js App Router
Route param types	End-to-end typed	`Promise<{}>` — partial
Search param types	Zod schema, automatic	Manual casting
Server data fetching	Server functions	Server Components + Actions
Vendor lock-in	None (Nitro)	Vercel-optimized
Deploy targets	Anywhere Nitro runs	Vercel-optimized
Ecosystem maturity	Growing (2026 stable)	Mature

When TanStack Start wins:

Type safety is the top priority
Deploying to Cloudflare Workers or non-Vercel infrastructure
Already using TanStack Router and want the full-stack story
Want server-side data fetching without the React Server Components mental model

When Next.js is still right:

Heavy use of next/image, next/font, ISR, Vercel-specific features
Large existing codebase — not worth migrating
Team knows Next.js deeply

For new projects where type safety is a first-class requirement and you don't want to be tied to Vercel's infrastructure, TanStack Start is the serious alternative Next.js finally has.

Full article at stacknotice.com/blog/tanstack-start-complete-guide-2026

MongoDB vs PostgreSQL (2026): When Document Storage Actually Beats Relational

Carlos Oliva Pascual — Mon, 31 Aug 2026 19:59:23 +0000

The MongoDB vs PostgreSQL debate has a specific shape: people who chose MongoDB early often wish they had PostgreSQL for complex queries, and people who chose PostgreSQL often reach for JSONB when they need flexible schemas. Both communities have a point.

MongoDB is a document database — data lives in JSON-like documents, collections replace tables, and there's no enforced schema by default. PostgreSQL is a relational database with a strict schema, ACID transactions, and JSONB support that lets you store and query document-shaped data inside a relational model.

The question isn't which is universally better. It's which fits your access patterns.

The Data Model

MongoDB: Documents in Collections

// A MongoDB document — arbitrary nesting, no fixed schema
{
  _id: ObjectId("64abc123"),
  name: "Alice Chen",
  email: "alice@example.com",
  profile: {
    bio: "Full-stack developer",
    location: { city: "Berlin", country: "DE" },
    skills: ["TypeScript", "React", "Node.js"]
  },
  preferences: {
    theme: "dark",
    notifications: { email: true, push: false }
  },
  createdAt: ISODate("2026-01-15T10:30:00Z")
}

No migration needed to add a preferences field to some documents and not others. This is the actual value of schema flexibility — not that schemas are bad, but that evolving a schema during early product development costs zero friction.

PostgreSQL: Structured Rows with Optional JSONB

CREATE TABLE users (
  id          UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  name        TEXT NOT NULL,
  email       TEXT UNIQUE NOT NULL,
  city        TEXT,
  country     CHAR(2),
  skills      TEXT[] DEFAULT '{}',
  preferences JSONB DEFAULT '{}',
  metadata    JSONB DEFAULT '{}',
  created_at  TIMESTAMPTZ DEFAULT NOW()
);

-- Index into JSONB fields
CREATE INDEX users_preferences_theme_idx
  ON users ((preferences->>'theme'));

PostgreSQL doesn't force you to choose between structured and flexible — you can use both in the same table.

Queries: Where PostgreSQL Wins for Complex Data

The same query in both — users in Germany with TypeScript skill, ordered by post count:

// MongoDB aggregation pipeline
db.users.aggregate([
  { $match: { "profile.location.country": "DE", "profile.skills": "TypeScript" }},
  { $lookup: { from: "posts", localField: "_id", foreignField: "authorId", as: "posts" }},
  { $addFields: { postCount: { $size: "$posts" } }},
  { $sort: { postCount: -1 } },
  { $limit: 20 },
  { $project: { name: 1, email: 1, "profile.location.city": 1, postCount: 1 }}
])

-- PostgreSQL — standard SQL
SELECT u.id, u.name, u.email, u.city, COUNT(p.id) AS post_count
FROM users u
LEFT JOIN posts p ON p.author_id = u.id
WHERE u.country = 'DE' AND 'TypeScript' = ANY(u.skills)
GROUP BY u.id, u.name, u.email, u.city
ORDER BY post_count DESC
LIMIT 20;

The SQL is shorter, more readable, and the query planner optimizes it with standard indexes.

JSONB Queries in PostgreSQL

-- Find users who prefer dark theme AND have email notifications enabled
SELECT name, email, preferences
FROM users
WHERE
  preferences->>'theme' = 'dark'
  AND (preferences->'notifications'->>'email')::boolean = true;

-- Update a nested key without replacing the whole document
UPDATE users
SET preferences = jsonb_set(preferences, '{notifications, push}', 'true')
WHERE id = $1;

-- Aggregate over JSONB array elements
SELECT skill, COUNT(*) as developer_count
FROM users, jsonb_array_elements_text(metadata->'skills') AS skill
GROUP BY skill
ORDER BY developer_count DESC;

This is the nuance most comparisons miss: PostgreSQL with JSONB is not a pure relational database. It handles document-shaped data well when you need it.

Transactions

MongoDB added multi-document ACID transactions in v4.0, but they're not the default and come with overhead. The document model encourages embedding related data to avoid transactions entirely.

// MongoDB: embed to avoid multi-document transactions
await db.orders.insertOne({
  customerId: ObjectId("..."),
  status: "pending",
  items: [  // embedded — one atomic write
    { productId: ObjectId("..."), name: "Keyboard", price: 89.99, qty: 1 },
    { productId: ObjectId("..."), name: "Mouse", price: 49.99, qty: 2 }
  ],
  total: 189.97,
  createdAt: new Date()
})

-- PostgreSQL: transactions are the default, always available
BEGIN;
INSERT INTO orders (customer_id, status, total) VALUES ($1, 'pending', $2) RETURNING id INTO order_id;
INSERT INTO order_items (order_id, product_id, price, quantity) VALUES (order_id, $3, $4, $5);
UPDATE inventory SET quantity = quantity - $qty WHERE product_id = ANY($product_ids) AND quantity >= $qty;
COMMIT;

TypeScript Integration

Both have mature TypeScript support.

// MongoDB with Mongoose
const userSchema = new Schema({
  name: { type: String, required: true },
  email: { type: String, required: true, unique: true },
  skills: [String]
})
type User = InferSchemaType<typeof userSchema>

// PostgreSQL with Drizzle
const users = pgTable('users', {
  id: uuid('id').primaryKey().defaultRandom(),
  name: text('name').notNull(),
  email: text('email').notNull().unique(),
  createdAt: timestamp('created_at').defaultNow()
})
// Fully typed — schema IS the type

Drizzle and Prisma both support MongoDB, so the TypeScript ergonomics are comparable.

Decision Framework

Choose MongoDB if:

Early product with rapidly changing data model
Data is genuinely document-shaped (deeply nested, no natural relational structure)
You need horizontal sharding at scale
Content management, product catalogs, or event logs with heterogeneous schemas

Choose PostgreSQL if:

Data has clear relational structure with known relationships
You need reliable multi-document transactions
Complex queries with multiple joins are core
Full-text search, geospatial queries, or analytical aggregations matter
You want one database that handles both structured and semi-structured data (JSONB)

The honest assessment: For most web applications built in 2026, PostgreSQL is the safer default. Its JSONB support handles most use cases where MongoDB's flexibility would have been the argument. MongoDB remains the right choice for genuinely document-shaped domains.

Full article at stacknotice.com/blog/mongodb-vs-postgresql-2026

GraphQL vs REST vs tRPC (2026): Choosing Your API Style

Carlos Oliva Pascual — Mon, 31 Aug 2026 08:02:36 +0000

Your API style determines how your team thinks about data, how clients evolve independently of servers, and how much friction exists between backend changes and frontend code.

The Same Resource, Three Ways

A user profile with recent posts:

// REST — two round trips, types maintained manually
const user = await fetch(`/api/users/${id}`).then(r => r.json())
const posts = await fetch(`/api/users/${id}/posts?limit=5`).then(r => r.json())

// GraphQL — one query, client controls the shape, no extra fields
const { data } = await client.query({
  query: gql`query { user(id: $id) { name, bio, recentPosts(limit: 5) { title, slug } } }`,
  variables: { id }
})

// tRPC — one call, fully typed from server return type, no schema
const { data } = trpc.users.getProfile.useQuery({ id, postLimit: 5 })
// data.user and data.posts are typed — TypeScript fails if server changes

Type Safety: The Spectrum

	REST	GraphQL	tRPC
Type source	Manual or OpenAPI codegen	Schema + codegen	Server return types, automatically
Sync required	After API change	After schema change	None — compiler fails immediately
Code generation	Optional	Required for full safety	Never needed

tRPC's key differentiator: change the server return type, TypeScript fails in the client at compile time. No schema to update, no generator to run.

Over-fetching

REST returns fixed shapes regardless of what the client needs. GraphQL solves this at the query level:

# Profile page needs everything
query ProfilePage($id: ID!) {
  user(id: $id) { name, bio, avatarUrl, recentPosts(limit: 5) { title, slug } }
}

# Comment list only needs name + avatar — no other user fields come back
query CommentList($postId: ID!) {
  comments(postId: $postId) {
    content
    author { name, avatarUrl }
  }
}

tRPC controls over-fetching through procedure design — you create separate procedures for different use cases. More explicit, but doesn't allow ad-hoc field selection.

Caching

REST maps to HTTP — CDNs, reverse proxies, and browsers cache GET responses automatically via headers.

GraphQL typically uses POST (even for reads), which HTTP caches ignore by default. Apollo Client and urql provide powerful client-side normalized caches, but CDN-level caching requires extra configuration.

tRPC uses React Query's client-side cache. CDN caching requires wrapping queries as GET requests.

// REST — cache built into every HTTP layer
res.set('Cache-Control', 'public, max-age=60, stale-while-revalidate=300')
// Cloudflare/Fastify caches this without any configuration

// GraphQL — CDN caching needs persisted queries + configuration
// tRPC — React Query cache (client-side, not CDN)

Client Flexibility

	REST	GraphQL	tRPC
Browser (fetch)	✅	✅	TS only
Mobile (Swift/Kotlin)	✅	✅	❌
Third-party integrations	✅	✅	❌
curl / Postman	✅	✅	Possible

If anyone other than your TypeScript frontend will consume this API, tRPC is not the right primary choice.

Decision Framework

Situation	Choose
Public API with external consumers	REST
Mobile + web + third-party clients	REST or GraphQL
Multiple frontends, different data shapes	GraphQL
CDN caching is critical	REST
Real-time subscriptions	GraphQL
Full-stack TypeScript, one frontend	tRPC
Monorepo, tightest type loop	tRPC
Non-TypeScript clients exist	REST or GraphQL

The practical heuristic: if someone outside your TypeScript frontend will consume the API, tRPC isn't the right primary choice. Multiple clients with different data shapes → GraphQL earns its complexity. One TypeScript frontend where type safety is the priority → tRPC wins on DX.

Hybrid approaches are common: REST for public webhooks and external consumers, tRPC for the internal dashboard, GraphQL for the mobile app — because the right choice depends on the consumer, not just the backend.

Full article at stacknotice.com/blog/graphql-vs-rest-vs-trpc-2026

Vercel AI SDK vs LangChain.js (2026): Two Ways to Build AI-Powered Apps

Carlos Oliva Pascual — Fri, 28 Aug 2026 11:15:48 +0000

Both let you build AI apps in TypeScript. The similarity ends there.

The AI SDK was designed for streaming AI responses into React UIs. It ships with useChat, useCompletion, and useObject hooks that handle streaming, loading states, and error handling automatically — React Query for AI responses.

LangChain.js was designed for orchestration. Chains, agents, memory, RAG, vector stores, tool calling — a framework for multi-step AI workflows where the AI reasons, retrieves, and acts before generating a final response.

Streaming Chat: AI SDK Wins Clearly

// AI SDK — 6 lines of UI logic handle everything
'use client'
import { useChat } from 'ai/react'

export function Chat() {
  const { messages, input, handleInputChange, handleSubmit, isLoading } = useChat({
    api: '/api/chat'
  })

  return (
    <form onSubmit={handleSubmit}>
      {messages.map(m => <div key={m.id}>{m.content}</div>)}
      {isLoading && <div>Thinking...</div>}
      <input value={input} onChange={handleInputChange} />
      <button disabled={isLoading}>Send</button>
    </form>
  )
}

// API route
import { streamText } from 'ai'
import { openai } from '@ai-sdk/openai'

export async function POST(req: Request) {
  const { messages } = await req.json()
  return streamText({ model: openai('gpt-4o'), messages }).toDataStreamResponse()
}

LangChain.js has no React hooks. You build streaming consumption and state management yourself — significantly more code for the same result.

Structured Output

// AI SDK — streamObject with useObject hook
const { object, submit, isLoading } = useObject({
  api: '/api/analyze',
  schema: ProductSchema  // Zod schema
})
// object arrives token-by-token — partial objects render in real-time

// LangChain.js — one-shot structured extraction
const structuredModel = new ChatOpenAI({ model: 'gpt-4o' }).withStructuredOutput(ProductSchema)
const result = await structuredModel.invoke(`Analyze: "${text}"`)
// No streaming for partial objects

RAG Pipeline: LangChain.js Wins

// LangChain.js — full RAG in ~20 lines
import { PDFLoader } from '@langchain/community/document_loaders/fs/pdf'
import { RecursiveCharacterTextSplitter } from 'langchain/text_splitter'
import { MemoryVectorStore } from 'langchain/vectorstores/memory'
import { createRetrievalChain } from 'langchain/chains/retrieval'

const docs = await new PDFLoader('docs.pdf').load()
const chunks = await new RecursiveCharacterTextSplitter({ chunkSize: 1000, chunkOverlap: 200 }).splitDocuments(docs)
const vectorStore = await MemoryVectorStore.fromDocuments(chunks, new OpenAIEmbeddings())
const chain = await createRetrievalChain({
  retriever: vectorStore.asRetriever({ k: 4 }),
  combineDocsChain: await createStuffDocumentsChain({ llm, prompt })
})

const result = await chain.invoke({ input: 'What is the refund policy?' })

AI SDK provides embedding primitives but no document loaders, text splitters, or vector store integrations. You assemble those pieces yourself.

Tool Calling

// AI SDK — clean tool definition with maxSteps for multi-turn
const { text } = await generateText({
  model: anthropic('claude-sonnet-4-6'),
  tools: {
    getWeather: tool({
      description: 'Get weather for a city',
      parameters: z.object({ location: z.string(), unit: z.enum(['celsius', 'fahrenheit']) }),
      execute: async ({ location, unit }) => weatherApi.getCurrent(location, unit)
    })
  },
  maxSteps: 5,  // allows model to call tools and see results before responding
  prompt: 'What is the weather in Paris right now?'
})

// LangChain.js — agent executor with built-in memory and step logging
const executor = new AgentExecutor({ agent, tools, verbose: true })
const result = await executor.invoke({ input: 'What is the weather in Paris?', chat_history: [] })

Both support multi-step tool use. LangChain's agent executor has more built-in patterns (ReAct, Plan-and-Execute). AI SDK's maxSteps is simpler for straightforward tool use.

Bundle Size and Edge Compatibility

	AI SDK	LangChain.js
Bundle size	~110kb	~800kb+
Edge deployment	✅ Works	❌ Too heavy
Cold start impact	Minimal	Significant

Decision Framework

Situation	Choose
Streaming chat UI in Next.js/React	AI SDK
useChat / useCompletion hooks needed	AI SDK
useObject — partial streaming objects	AI SDK
Edge deployment	AI SDK
RAG with document loaders	LangChain.js
Complex multi-step agents	LangChain.js
Vector store integrations	LangChain.js
Conversation memory	LangChain.js

Many production apps use both: AI SDK for the frontend streaming layer, LangChain.js for backend retrieval and agent logic.

Full article at stacknotice.com/blog/vercel-ai-sdk-vs-langchain-js-2026

PocketBase vs Supabase (2026): When the Single Binary Beats the Full Platform

Carlos Oliva Pascual — Thu, 27 Aug 2026 10:26:12 +0000

Both give you a database, auth, file storage, and real-time without building each piece manually. They are not interchangeable.

PocketBase is a single Go binary — download it, run it, full backend in under 2 minutes on a $6 VPS. SQLite, built-in admin UI, no Docker required. Supabase is a full platform built on PostgreSQL — scales to millions, Row-Level Security, JSONB, full-text search. The complexity is real, and so are the capabilities.

Setup Comparison

PocketBase: One Binary

wget https://github.com/pocketbase/pocketbase/releases/download/v0.22.0/pocketbase_0.22.0_linux_amd64.zip
unzip pocketbase_0.22.0_linux_amd64.zip
./pocketbase serve
# Admin UI: http://localhost:8090/_/
# API: http://localhost:8090/api/

For production — a systemd service and you're done. Backups are cp on the SQLite file.

Supabase: Docker or Hosted

# Hosted — point SDK to your project URL
npm install @supabase/supabase-js

# Self-hosted — 8+ Docker containers, needs 4GB RAM minimum
git clone https://github.com/supabase/supabase
cd supabase/docker && cp .env.example .env
docker compose up -d

Auth

Both include email/password, OAuth2 (Google, GitHub, Discord), and magic links.

// PocketBase
const pb = new PocketBase('http://localhost:8090')
const auth = await pb.collection('users').authWithPassword('user@example.com', 'password')
// Token stored in pb.authStore, auto-refreshed

// Supabase
const { data } = await supabase.auth.signInWithPassword({ email, password })
// Supabase adds Row-Level Security — policies enforced at DB level

Supabase's RLS is the key differentiator: access rules live in the database, not application code. Even a buggy query can't return data the user isn't allowed to see.

Real-Time

// PocketBase — SSE, any record change
pb.collection('posts').subscribe('*', (e) => {
  // e.action: 'create' | 'update' | 'delete'
  // e.record: the changed record
})

// Supabase — PostgreSQL logical replication, with filters + presence
supabase.channel('posts')
  .on('postgres_changes', {
    event: '*', schema: 'public', table: 'posts',
    filter: 'published_at=not.is.null'
  }, (payload) => console.log(payload))
  .subscribe()

// Supabase Presence — who's online
channel.on('presence', { event: 'sync' }, () => {
  const online = channel.presenceState()
})

Supabase's real-time is more capable for collaborative apps. PocketBase's SSE is simpler and sufficient for notifications/dashboards.

Data Modeling

// PocketBase — SQLite, relations work, but no JSONB/full-text/arrays
// Schema built in admin UI or Go code

// Supabase — full PostgreSQL
CREATE TABLE posts (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  tags TEXT[] DEFAULT '{}',           -- native arrays
  metadata JSONB DEFAULT '{}',         -- JSONB operators
  search_vector TSVECTOR              -- full-text search
);

-- RLS policy — users only see their own posts
CREATE POLICY "own posts" ON posts FOR ALL
  USING (auth.uid() = author_id);

Scale and Cost

Factor	PocketBase	Supabase
Database	SQLite	PostgreSQL
Practical scale	~50k active users	Millions
Self-hosted cost	~$6-10/month VPS	~$20-50/month (4GB RAM)
Managed	No official hosting	Free → $25/month Pro
Horizontal scaling	Single node	Multiple replicas

SQLite writes are serialized — high write concurrency degrades. For read-heavy apps (blog, docs, internal tool), this rarely matters. For apps with thousands of concurrent writers, PostgreSQL is necessary.

Decision Framework

Choose PocketBase if:

Side project, internal tool, or prototype
You want full ownership, no cloud dependency
Budget is a constraint — $6 VPS covers a lot
Your data model fits SQLite (no complex JSON queries, no full-text at scale)

Choose Supabase if:

Building for production scale from the start
Row-Level Security matters as a security layer
Your queries need PostgreSQL features: JSONB, full-text, geo (PostGIS), embeddings (pg_vector)
You want a managed database without server maintenance

PocketBase is genuinely impressive for its scope. A solo developer can ship a complete product in days on it. But it's a tool for a specific scale range — once you need horizontal scaling, complex SQL, or RLS as a security primitive, PostgreSQL is the right foundation.

Full article at stacknotice.com/blog/pocketbase-vs-supabase-2026

Zustand vs Jotai (2026): Store-Based vs Atomic State in React

Carlos Oliva Pascual — Tue, 25 Aug 2026 06:45:46 +0000

Both Zustand and Jotai are from the same creator and solve the same core problem: state management without Redux boilerplate. Both are ~3kb. Both work great with TypeScript. The difference is the mental model.

Zustand thinks in stores — centralized state with actions. Jotai thinks in atoms — small composable pieces that derive from each other.

Core Model

Zustand: Store + Selectors

// store/useCartStore.ts
export const useCartStore = create<CartStore>()(
  devtools(persist(
    (set, get) => ({
      items: [] as CartItem[],
      isOpen: false,

      addItem: (item) => set(state => {
        const existing = state.items.find(i => i.id === item.id)
        if (existing) {
          return { items: state.items.map(i => i.id === item.id ? { ...i, quantity: i.quantity + 1 } : i) }
        }
        return { items: [...state.items, { ...item, quantity: 1 }] }
      }),

      clearCart: () => set({ items: [] }),
      toggleCart: () => set(state => ({ isOpen: !state.isOpen }))
    }),
    { name: 'cart' }
  ))
)

// Components subscribe only to what they need
function CartButton() {
  const count = useCartStore(state => state.items.reduce((s, i) => s + i.quantity, 0))
  const toggle = useCartStore(state => state.toggleCart)
  return <button onClick={toggle}>Cart ({count})</button>
  // Only re-renders when count changes
}

Jotai: Atoms Compose

// store/cartAtoms.ts
export const cartItemsAtom = atomWithStorage<CartItem[]>('cart-items', [])
export const cartOpenAtom = atom(false)

// Derived atoms — auto-memoized, shared across all subscribers
export const cartCountAtom = atom(get =>
  get(cartItemsAtom).reduce((s, i) => s + i.quantity, 0)
)
export const cartTotalAtom = atom(get =>
  get(cartItemsAtom).reduce((s, i) => s + i.price * i.quantity, 0)
)

// Write atom for actions
export const addItemAtom = atom(null, (get, set, item: Omit<CartItem, 'quantity'>) => {
  const items = get(cartItemsAtom)
  const existing = items.find(i => i.id === item.id)
  set(cartItemsAtom, existing
    ? items.map(i => i.id === item.id ? { ...i, quantity: i.quantity + 1 } : i)
    : [...items, { ...item, quantity: 1 }]
  )
})

function CartButton() {
  const count = useAtomValue(cartCountAtom)
  const setOpen = useSetAtom(cartOpenAtom)
  return <button onClick={() => setOpen(p => !p)}>Cart ({count})</button>
}

Async State: The Biggest Practical Difference

Zustand — manual loading/error management

const useUserStore = create<UserStore>()((set) => ({
  user: null, loading: false, error: null,
  fetchUser: async (id) => {
    set({ loading: true, error: null })
    try {
      set({ user: await api.users.getById(id), loading: false })
    } catch (err) {
      set({ error: (err as Error).message, loading: false })
    }
  }
}))

Jotai — async atoms + Suspense

// The fetch IS the atom — no manual loading state
export const userQueryAtom = atomWithQuery(get => ({
  queryKey: ['user', get(userIdAtom)],
  queryFn: () => api.users.getById(get(userIdAtom)!),
  enabled: !!get(userIdAtom)
}))

// Component suspends until data resolves
function ProfileContent() {
  const [{ data: user }] = useAtom(userQueryAtom)
  return <Profile user={user!} />
}

// Suspense boundary handles the loading state
function Page() {
  return (
    <Suspense fallback={<Spinner />}>
      <ProfileContent />
    </Suspense>
  )
}

Derived State

Zustand selectors recompute on every render (use useShallow for complex objects). Jotai derived atoms are memoized automatically — all subscribers share the same cached computation.

// Zustand — manually memoize expensive selectors
const result = useCartStore(useShallow(state => ({
  items: state.items,
  total: state.items.reduce((s, i) => s + i.price * i.quantity, 0)
})))

// Jotai — memoization is built in, computed once per change
const expensiveItemsAtom = atom(get => get(cartItemsAtom).filter(i => i.price > 100))
const expensiveTotalAtom = atom(get =>
  get(expensiveItemsAtom).reduce((s, i) => s + i.price * i.quantity, 0)
)
// Multiple components using expensiveTotalAtom share the same result

Decision Framework

Situation	Choose
Coming from Redux	Zustand
State shared across many unrelated components	Zustand
Complex actions with side effects	Zustand
Redux DevTools matters	Zustand
Suspense-based async pattern	Jotai
Fine-grained, component-local state	Jotai
atomWithQuery (TanStack integration)	Jotai
Coming from Recoil	Jotai

For most React apps, Zustand is the lower-friction starting point. Its mental model (a bag of values with operations) maps to how most developers already think about state. Jotai becomes genuinely better when state is highly reactive, granular, and benefits from automatic memoization across derived views.

Full article at stacknotice.com/blog/zustand-vs-jotai-2026

Next.js 15 vs Remix (2026): Full-Stack React, Two Different Philosophies

Carlos Oliva Pascual — Mon, 24 Aug 2026 10:29:42 +0000

Both are full-stack React frameworks. Both handle routing, data loading, and server rendering. Both use TypeScript by default. The similarities end there.

Next.js is built by Vercel and optimized for their platform — edge caching, partial prerendering, incremental static regeneration. Remix is built around web standards — native Request/Response, HTML form actions, progressive enhancement. It runs anywhere Node.js runs with no vendor dependency.

Data Loading

Next.js: Server Components Fetch Directly

// app/dashboard/page.tsx — direct DB access, no API layer needed
export default async function Dashboard() {
  const [user, stats, recentOrders] = await Promise.all([
    db.user.findUnique({ where: { id: getCurrentUserId() } }),
    db.order.aggregate({ _count: true }),
    db.order.findMany({ take: 10, orderBy: { createdAt: 'desc' } })
  ])

  return (
    <div>
      <h1>Welcome, {user.name}</h1>
      <Stats data={stats} />
      <RecentOrders orders={recentOrders} />
    </div>
  )
}

Next.js deduplicates identical fetches across the component tree automatically.

Remix: Loaders Fetch, Components Consume

// app/routes/dashboard.tsx
export async function loader({ request }: LoaderFunctionArgs) {
  const userId = await getUserId(request)
  const [user, stats, recentOrders] = await Promise.all([
    db.user.findUnique({ where: { id: userId } }),
    db.order.aggregate({ _count: true }),
    db.order.findMany({ take: 10, orderBy: { createdAt: 'desc' } })
  ])
  return json({ user, stats, recentOrders })
}

export default function Dashboard() {
  const { user, stats, recentOrders } = useLoaderData<typeof loader>()
  return (/* same JSX */)
}

Explicit separation: loader is testable in isolation without rendering any UI.

Forms and Mutations

This is Remix's strongest differentiator.

Next.js: Server Actions (requires JavaScript)

'use server'
export async function createPost(formData: FormData) {
  const parsed = createPostSchema.safeParse(Object.fromEntries(formData))
  if (!parsed.success) return { error: parsed.error.flatten().fieldErrors }
  await db.post.create({ data: parsed.data })
  revalidatePath('/blog')
}

// Client component needed for pending state
'use client'
const [state, action, isPending] = useActionState(createPost, null)
return <form action={action}><button disabled={isPending}>Save</button></form>

Remix: Native Form Actions (progressive enhancement)

export async function action({ request }: ActionFunctionArgs) {
  const formData = await request.formData()
  const parsed = createPostSchema.safeParse(Object.fromEntries(formData))
  if (!parsed.success) return json({ errors: parsed.error.flatten().fieldErrors }, { status: 400 })
  await db.post.create({ data: parsed.data })
  return redirect('/blog')
}

export default function NewPost() {
  const actionData = useActionData<typeof action>()
  const { state } = useNavigation()

  return (
    // Works WITHOUT JavaScript — native HTML form, server processes, redirect
    <Form method="post">
      {actionData?.errors?.title && <p>{actionData.errors.title[0]}</p>}
      <button disabled={state === 'submitting'}>Save</button>
    </Form>
  )
}

Remix's <Form> submits as a native HTML form before hydration. Next.js Server Actions require JavaScript to intercept the submit event.

Caching

Next.js: Multiple caching layers (Vercel-optimized)

export const revalidate = 60          // ISR — regenerate every 60s
export const experimental_ppr = true  // Partial Prerendering

// On-demand revalidation
await revalidatePath('/blog')
await revalidateTag('posts')

ISR, PPR, and on-demand revalidation are first-class on Vercel. Significantly more work on other platforms.

Remix: Standard HTTP Cache Headers

export function headers() {
  return { 'Cache-Control': 'max-age=300, stale-while-revalidate=60' }
}

Works identically on every platform. No framework caching layer, no vendor dependency.

Deployment

Next.js: Optimized for Vercel. Self-hosting works but you lose ISR, edge middleware features, and on-demand revalidation without building it yourself.

Remix: Any Node.js server. One-line adapter swap between Express, Fastify, Cloudflare Workers, Fly.io, Vercel — same application code everywhere.

// Remix on Express
app.all('*', createRequestHandler({ build: require('./build') }))
// Change to Cloudflare adapter → same routes, same loaders, same actions

Decision Framework

Choose Next.js 15 if:

Deploying to Vercel and want ISR, PPR, or Edge Middleware
Existing Next.js codebase (migration cost isn't worth it)
You need the largest ecosystem: auth libraries, component libraries, tutorials
Building a content site or e-commerce where CDN caching matters

Choose Remix if:

Progressive enhancement matters — forms that work before JavaScript loads
Deploying to multiple platforms or need to avoid Vercel lock-in
You want explicit data loading: route requirements visible at the top of each file
Coming from Rails/Django — the loader/action mental model maps directly

The honest take: Next.js wins on ecosystem and CDN performance. Remix wins on web fundamentals and deployment flexibility. If you're unsure which you'll need more — ecosystem or portability — Next.js is the lower-risk starting point.

Full article at stacknotice.com/blog/nextjs-15-vs-remix-2026

Zod vs Valibot (2026): When Bundle Size Actually Matters for Validation

Carlos Oliva Pascual — Fri, 21 Aug 2026 12:05:40 +0000

Both Zod and Valibot solve the same problem: TypeScript types only exist at compile time, but you need to validate unknown data at runtime — API inputs, form data, environment variables. Both generate TypeScript types from schemas. Both work with tRPC, Hono, and React Hook Form. The differences are bundle size, API design, and ecosystem maturity.

The Bundle Gap

Library	Minified + Gzipped	Tree-shaking
Zod v3	~55kb	Limited
Valibot v1	~10-12kb total, ~1-2kb per schema	Full

For Node.js APIs, irrelevant. For Cloudflare Workers or browser bundles, it matters.

API: Method Chaining vs Function Pipeline

// Zod — chained methods
const CreateUserSchema = z.object({
  name: z.string().min(1).max(100),
  email: z.string().email(),
  role: z.enum(['USER', 'ADMIN']).default('USER'),
})
type CreateUser = z.infer<typeof CreateUserSchema>

const result = CreateUserSchema.safeParse(req.body)
if (!result.success) {
  const errors = result.error.flatten().fieldErrors
}

// Valibot — functional pipe()
import { object, string, pipe, minLength, maxLength, email, picklist, optional } from 'valibot'
const CreateUserSchema = object({
  name: pipe(string(), minLength(1), maxLength(100)),
  email: pipe(string(), email()),
  role: optional(picklist(['USER', 'ADMIN']), 'USER'),
})
type CreateUser = InferOutput<typeof CreateUserSchema>

const result = safeParse(CreateUserSchema, req.body)
if (!result.success) {
  const issues = result.issues  // Array<{ message, path }>
}

Zod reads more naturally. Valibot is fully tree-shakeable — bundlers drop functions you don't import.

Transforms and Coercion

// Query param coercion — Zod
const PaginationSchema = z.object({
  page: z.coerce.number().int().min(1).default(1),
  limit: z.coerce.number().int().min(1).max(100).default(20)
})

// Valibot equivalent
const PaginationSchema = object({
  page: optional(pipe(coerce(number(), Number), integer(), minValue(1)), 1),
  limit: optional(pipe(coerce(number(), Number), integer(), minValue(1), maxValue(100)), 20)
})

i18n Error Messages

Valibot's setGlobalConfig gives you a single translation layer for the whole app:

import { setGlobalConfig } from 'valibot'

setGlobalConfig({
  message: (issue) => {
    if (issue.type === 'min_length') return `Mínimo ${issue.requirement} caracteres`
    if (issue.type === 'email') return 'Email inválido'
    return 'Campo inválido'
  }
})
// Every schema picks this up automatically

Framework Integration

Both work with the same ecosystem:

// React Hook Form
import { zodResolver } from '@hookform/resolvers/zod'
import { valibotResolver } from '@hookform/resolvers/valibot'

// Same API, different resolver

// tRPC — Valibot supported since v11
.input(object({ name: string(), email: pipe(string(), email()) }))

// Hono
import { vValidator } from '@hono/valibot-validator'
app.post('/users', vValidator('json', schema), async (c) => { ... })

Decision Framework

Situation	Choose
Existing codebase, Node.js API	Zod
Cloudflare Workers, edge functions	Valibot
Browser bundle, size-sensitive app	Valibot
Need full i18n error messages	Valibot
Ecosystem maturity matters	Zod

They're interchangeable for most use cases. Migrating is a find-and-replace-plus-refactor, not a rearchitecture.

Full article at stacknotice.com/blog/zod-vs-valibot-2026

NestJS vs Fastify (2026): When Full Framework Beats Micro-Framework

Carlos Oliva Pascual — Thu, 13 Aug 2026 09:22:23 +0000

NestJS and Fastify are not competing for the same niche. Fastify is an HTTP framework — routing, request lifecycle, JSON serialization. NestJS is an application framework — all of that plus dependency injection, module encapsulation, decorators, and a strong opinion about how every file should be organized.

The comparison isn't really about performance numbers. It's about whether you want the framework to enforce architecture, or whether your team can enforce it themselves.

Architecture: Yours vs. Theirs

Fastify: You Own the Structure

// src/plugins/db.ts
export const dbPlugin = fp(async (fastify) => {
  const pool = new Pool({ connectionString: process.env.DATABASE_URL })
  fastify.decorate('db', drizzle(pool, { schema }))
  fastify.addHook('onClose', async () => pool.end())
})

// src/routes/users.ts
export const userRoutes: FastifyPluginAsync = async (fastify) => {
  fastify.post('/', {
    schema: {
      body: Type.Object({
        name: Type.String({ minLength: 1 }),
        email: Type.String({ format: 'email' })
      }),
      response: { 201: UserResponse }
    }
  }, async (request, reply) => {
    const existing = await fastify.db.query.users.findFirst({
      where: (u, { eq }) => eq(u.email, request.body.email)
    })
    if (existing) return reply.status(409).send({ error: 'Email already in use' })
    const [user] = await fastify.db.insert(users).values(request.body).returning()
    return reply.status(201).send(user)
  })
}

Clean for senior developers. The risk: on larger teams, architectural drift accumulates over months.

NestJS: Module → Controller → Service

// src/users/users.service.ts
@Injectable()
export class UsersService {
  constructor(
    @InjectRepository(User)
    private readonly userRepo: Repository<User>
  ) {}

  async create(dto: CreateUserDto): Promise<User> {
    const existing = await this.userRepo.findOne({ where: { email: dto.email } })
    if (existing) throw new ConflictException('Email already in use')
    return this.userRepo.save(this.userRepo.create(dto))
  }
}

// src/users/users.controller.ts
@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Post() @HttpCode(201) @UseGuards(JwtAuthGuard)
  create(@Body() dto: CreateUserDto) {
    return this.usersService.create(dto)
  }
}

A developer joining day one knows exactly where the business logic for any endpoint lives. That predictability has real value on a 10-person team.

Dependency Injection: The Real Differentiator

NestJS's DI container changes how you test:

// NestJS unit test — inject mocks without touching production code
describe('UsersService', () => {
  const mockRepo = {
    findOne: jest.fn(),
    create: jest.fn((dto) => dto),
    save: jest.fn((user) => ({ id: 'uuid-123', ...user }))
  }

  beforeEach(async () => {
    const module = await Test.createTestingModule({
      providers: [
        UsersService,
        { provide: getRepositoryToken(User), useValue: mockRepo }
      ]
    }).compile()
    service = module.get(UsersService)
  })

  it('throws ConflictException when email is taken', async () => {
    mockRepo.findOne.mockResolvedValueOnce({ id: 'existing' })
    await expect(service.create({ name: 'Test', email: 'taken@test.com' }))
      .rejects.toThrow(ConflictException)
  })
})

Mocking is natural. The DI container handles wiring — tests override what they need without changing anything else.

NestJS + Fastify Adapter

NestJS can run Fastify underneath instead of Express — you get both:

// main.ts
const app = await NestFactory.create<NestFastifyApplication>(
  AppModule,
  new FastifyAdapter({ logger: true })
)
app.useGlobalPipes(new ValidationPipe({ whitelist: true, transform: true }))
await app.listen(3000, '0.0.0.0')

Throughput improvement: ~30-50% more req/s on JSON-heavy routes. Verify Express-specific middleware compatibility before switching an existing app.

Performance

Setup	~Throughput
Fastify standalone	~75,000 req/s
NestJS + Fastify adapter	~50,000 req/s
NestJS + Express (default)	~28,000 req/s

Context: NestJS's DI resolves at startup, not per request. For most production APIs, database latency (5-50ms) dominates over framework overhead (0.1-0.5ms). The gap matters at 10k+ sustained req/s.

Auto-Generated Swagger

NestJS's killer feature for enterprise APIs:

export class CreateUserDto {
  @ApiProperty({ description: 'Full name', minLength: 1 })
  @IsString() @MinLength(1)
  name: string

  @ApiProperty({ format: 'email' })
  @IsEmail()
  email: string
}
// swagger-ui at /api — no separate spec file to maintain

Decision Framework

Choose Fastify if:

Small team (1-5 devs) with strong architectural discipline
Maximum throughput, minimal abstraction overhead
Microservice with a clear, bounded scope
Migrating from Express and want a familiar model with real performance gains

Choose NestJS if:

Team of 5+ with mixed experience levels
You need enforced architecture to prevent drift at scale
Enterprise features: microservices, GraphQL, WebSockets, gRPC out of the box
Coming from Spring Boot or Angular — mental model maps directly
Auto-generated Swagger without maintaining a spec

Choose NestJS + Fastify adapter if:

You want NestJS's structure but need better throughput than Express delivers

Full article at stacknotice.com/blog/nestjs-vs-fastify-2026

tRPC vs Hono RPC (2026): End-to-End Type Safety Without the Setup Tax

Carlos Oliva Pascual — Wed, 12 Aug 2026 15:10:40 +0000

The problem both tools solve is the same: you write an API in TypeScript and your frontend immediately knows the types — request shape, response shape, errors — without a code generation step, without an OpenAPI schema, without a shared types package you have to keep synchronized manually.

The implementation is very different.

tRPC builds on React Query and has deep Next.js integration. The client is a React Query wrapper — you get caching, background refetching, and optimistic updates automatically. Hono RPC is lighter. It generates a typed fetch client from your route definitions, works with any TypeScript consumer (React, Vue, Svelte, React Native, plain Node.js scripts), and runs on Cloudflare Workers, Bun, and Deno with zero changes.

The Core Model

tRPC: Procedures on a Router

// server/routers/users.ts
export const usersRouter = router({
  getById: publicProcedure
    .input(z.object({ id: z.string().cuid() }))
    .query(async ({ input }) => {
      const user = await db.user.findUnique({ where: { id: input.id } })
      if (!user) throw new TRPCError({ code: 'NOT_FOUND', message: 'User not found' })
      return user
    }),

  create: protectedProcedure
    .input(z.object({
      name: z.string().min(1).max(100),
      email: z.string().email(),
    }))
    .mutation(async ({ input, ctx }) => {
      const existing = await db.user.findUnique({ where: { email: input.email } })
      if (existing) throw new TRPCError({ code: 'CONFLICT', message: 'Email already in use' })
      return db.user.create({ data: { ...input, createdBy: ctx.session.userId } })
    }),
})

export type AppRouter = typeof appRouter

The AppRouter type carries the entire API contract to the client.

Hono RPC: Routes as Types

// server/routes/users.ts
const users = new Hono()
  .get('/:id', async (c) => {
    const user = await db.user.findUnique({ where: { id: c.req.param('id') } })
    if (!user) return c.json({ error: 'Not found' }, 404)
    return c.json(user)
  })
  .post(
    '/',
    requireAuth,
    zValidator('json', z.object({ name: z.string().min(1), email: z.string().email() })),
    async (c) => {
      const body = c.req.valid('json')
      const existing = await db.user.findUnique({ where: { email: body.email } })
      if (existing) return c.json({ error: 'Email already in use' }, 409)
      return c.json(await db.user.create({ data: body }), 201)
    }
  )

const app = new Hono().route('/users', users)
export type AppType = typeof app

Client Integration

tRPC: React Query Under the Hood

// components/UserList.tsx
export function UserList() {
  const utils = trpc.useUtils()
  const { data, isLoading } = trpc.users.list.useQuery({ page: 1, limit: 20 })

  const createUser = trpc.users.create.useMutation({
    onSuccess: () => utils.users.list.invalidate()
  })

  // Cache invalidation, loading states, background refetch — all free
}

Hono RPC: Typed Fetch, You Handle Caching

// lib/client.ts
export const client = hc<AppType>('http://localhost:3000')

// components/UserList.tsx — React Query wired manually
const { data } = useQuery({
  queryKey: ['users', 1],
  queryFn: async () => {
    const res = await client.users.$get({ query: { page: '1', limit: '20' } })
    return res.json()  // fully typed
  }
})

Non-React Clients

Hono RPC's clear advantage:

// Vue 3
const { data } = await useAsyncData('users', () =>
  client.users.$get({ query: { page: '1' } }).then(r => r.json())
)

// Node.js seeding script
const client = hc<AppType>('http://localhost:3000')
await client.users.$post({ json: { name: 'Seed', email: 'seed@example.com' } })

// Server-to-server microservice call
const user = await internalClient.users[':id'].$get({ param: { id } }).then(r => r.json())
// Fully typed response — no manual type assertions

Subscriptions

tRPC wins here — first-class support:

// tRPC — real-time with subscriptions
const notificationsRouter = router({
  onNewMessage: publicProcedure
    .input(z.object({ roomId: z.string() }))
    .subscription(async function* ({ input }) {
      for await (const message of subscribeToRoom(input.roomId)) {
        yield message
      }
    })
})

// Client
trpc.notifications.onNewMessage.useSubscription(
  { roomId: 'room-123' },
  { onData: (msg) => setMessages(prev => [...prev, msg]) }
)

Hono handles real-time via SSE separately from the RPC layer.

Decision Framework

Situation	Choose
Next.js app, React-heavy frontend	tRPC
Already using React Query	tRPC
Need real-time subscriptions	tRPC
Non-React clients (Vue, Svelte, React Native)	Hono RPC
Edge deployment (Cloudflare Workers, Bun)	Hono RPC
Server-to-server API calls	Hono RPC
Multi-runtime backend	Hono RPC

Both are better than maintaining an OpenAPI schema or a shared types package that drifts. The choice is about what already exists in your stack — not which API is more elegant.

Full article at stacknotice.com/blog/trpc-vs-hono-rpc-2026