DEV Community: Carlos Oliva Pascual

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

Hono vs Express vs Fastify (2026): Which Node.js Framework Is Actually Faster?

Carlos Oliva Pascual — Wed, 12 Aug 2026 08:08:58 +0000

Choosing a Node.js backend framework in 2026 means choosing between three tools with very different priorities. Express optimizes for familiarity. Fastify optimizes for Node.js performance. Hono optimizes for portability across runtimes.

Performance: The Numbers That Matter

Framework	Throughput	Latency
Hono (Node.js)	~85,000 req/s	~0.5ms
Fastify	~75,000 req/s	~0.6ms
Express	~30,000 req/s	~1.4ms
Hono (Bun)	~130,000+ req/s	~0.3ms

Express is ~2-3x slower than Fastify and Hono. The gap is real but only meaningful at scale (10k+ req/s). For most apps, database query time dominates.

Express — The Incumbent

import express from 'express'
import { z } from 'zod'

const app = express()
app.use(express.json())

app.post('/users', async (req, res) => {
  const parsed = createUserSchema.safeParse(req.body)
  if (!parsed.success) return res.status(400).json({ errors: parsed.error.flatten() })

  const user = await db.user.create({ data: parsed.data })
  res.status(201).json(user)
})

No built-in TypeScript. No built-in validation. No built-in serialization. You bring everything. That's also why there's an Express middleware for virtually every use case.

Choose Express when: legacy codebase, team already knows it, or you need a specific middleware with no alternative.

Fastify — Best Throughput on Node.js

Fastify compiles a serializer from your JSON Schema at startup — 2-3x faster than JSON.stringify. TypeScript is first-class.

import Fastify from 'fastify'
import { Type } from '@sinclair/typebox'

const fastify = Fastify({ logger: true })

fastify.post('/users', {
  schema: {
    body: Type.Object({
      name: Type.String({ minLength: 1 }),
      email: Type.String({ format: 'email' })
    }),
    response: {
      201: Type.Object({ id: Type.String(), name: Type.String(), email: Type.String() })
    }
  }
}, async (request, reply) => {
  // request.body is fully typed from schema
  const user = await db.user.create({ data: request.body })
  reply.status(201).send(user)
})

The schema does two things: validates input at runtime AND compiles the response serializer. One definition, both benefits.

Plugin system with fastify-plugin:

import fp from 'fastify-plugin'

export const authPlugin = fp(async (fastify) => {
  fastify.decorate('authenticate', async (request, reply) => {
    const token = request.headers.authorization?.replace('Bearer ', '')
    if (!token) return reply.status(401).send({ error: 'Unauthorized' })
    request.user = verifyJWT(token)
  })
})

Choose Fastify when: staying on Node.js, schema-first development with TypeBox, need maximum throughput without leaving Node.

Hono — Runs Everywhere

Hono is built on web standards (Request, Response, Headers). The same code runs on Node.js, Bun, Cloudflare Workers, Deno, and AWS Lambda Edge.

import { Hono } from 'hono'
import { zValidator } from '@hono/zod-validator'
import { z } from 'zod'

const app = new Hono()

app.post(
  '/users',
  zValidator('json', z.object({ name: z.string(), email: z.string().email() })),
  async (c) => {
    const body = c.req.valid('json')  // fully typed
    const user = await db.user.create({ data: body })
    return c.json(user, 201)
  }
)

export default app  // same export on Node, Bun, or Cloudflare Workers

Built-in middleware that covers most APIs:

import { cors } from 'hono/cors'
import { logger } from 'hono/logger'
import { jwt } from 'hono/jwt'
import { rateLimiter } from 'hono-rate-limiter'

app.use('*', logger())
app.use('*', cors({ origin: 'https://myapp.com' }))
app.use('/api/*', jwt({ secret: process.env.JWT_SECRET! }))

RPC with end-to-end type safety (no code generation):

// server.ts
const routes = new Hono()
  .get('/users/:id', async (c) => c.json(await getUser(c.req.param('id'))))

export type AppType = typeof routes

// client.ts
import { hc } from 'hono/client'
const client = hc<AppType>('http://localhost:3000')

const user = await client.users[':id'].$get({ param: { id: '123' } })
// Fully typed response — no API schema file needed

Choose Hono when: multi-runtime (Cloudflare Workers, Bun, Deno), edge deployments, you want tRPC-like type safety without the setup, or you're on Bun and want maximum performance.

The Same Endpoint in All Three

// Express
app.post('/posts', async (req, res) => {
  const parsed = schema.safeParse(req.body)
  if (!parsed.success) return res.status(400).json({ error: parsed.error })
  const post = await db.post.create({ data: parsed.data })
  res.status(201).json(post)
})

// Fastify
fastify.post('/posts', {
  schema: { body: PostBody, response: { 201: PostResponse } }
}, async (request, reply) => {
  const post = await db.post.create({ data: request.body })
  reply.status(201).send(post)
})

// Hono
app.post('/posts', zValidator('json', schema), async (c) => {
  const post = await db.post.create({ data: c.req.valid('json') })
  return c.json(post, 201)
})

Fastify wins on compiled performance. Hono wins on portability and conciseness. Express requires the most boilerplate for equivalent safety.

Decision Framework

Situation	Choose
Legacy Express codebase	Express
New project, Node.js only, max throughput	Fastify
New project, multi-runtime or edge	Hono
Using Bun	Hono
Need RPC-style type safety	Hono
Specific Express middleware with no alternative	Express

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

OpenAI Codex CLI vs Claude Code (2026): Terminal Coding Agents Compared

Carlos Oliva Pascual — Tue, 11 Aug 2026 12:56:21 +0000

OpenAI entering the terminal-based AI coding agent space with Codex CLI puts two serious tools in direct comparison. Both are CLI agents that read your codebase, edit files, and run shell commands. Both are designed to replace a significant portion of manual coding work. The surface similarity is real. The philosophy is not.

The Foundational Difference

Codex CLI leans toward autonomy. In --full-auto mode, it reads files, makes changes, and runs commands without asking. The assumption is that you've scoped the task correctly and want execution without interruption.

Claude Code leans toward control. Its explicit permission model asks before consequential actions. You can whitelist trusted commands, but the default is to surface what it's about to do before doing it.

Model and API

# Codex CLI
codex --model gpt-4o "add input validation to the signup form"
codex --model o3 "analyze the architecture and suggest improvements"

# Claude Code
claude                              # Sonnet 4.6
claude --model claude-opus-4-6     # Opus — deeper reasoning

Both GPT-4o and Claude Sonnet 4.6 are strong for coding tasks. The model is less the differentiator than the tooling built around it.

Permission Models

Codex CLI: three modes

# Suggest only — show changes, don't apply
codex --approval-mode suggest "refactor the auth module"

# Auto-edit — edit files, ask before commands
codex --approval-mode auto-edit "refactor the auth module"

# Full auto — edit files AND run commands without asking
codex --approval-mode full-auto "refactor the auth module"

Full auto is genuinely different. It will run git commit, npm install, docker build without asking. The speed is real. The risk is also real: a wrong command runs before you see it. Codex mitigates this with a network sandbox in full auto mode.

Claude Code: explicit by default

# Every consequential action asks first:
# > Run command: git push origin main ? [y/n/always/never]

# Grant permanent permission for trusted commands:
claude config add-allowed-command "npm test"

You make trust decisions deliberately, not as a mode toggle. For production codebases, this is not friction — it's the point.

Context and Project Understanding

Codex CLI: git history + explicit files

codex "fix the failing tests" src/auth.ts src/__tests__/auth.test.ts
codex "what changed in the last three commits causing the 401 errors"

Context is session-scoped: what you pass in explicitly.

Claude Code: CLAUDE.md — persistent across sessions

# Project Context
## Stack
- Next.js 15, TypeScript strict, Drizzle ORM + Neon, Clerk, Bun
## Key files
- /src/lib/auth.ts — Clerk JWT validation
- /src/lib/db/schema.ts — Full Drizzle schema
## Constraints
- Never use `any`. Ask before installing packages.

Loads automatically every session. Set up once, works indefinitely.

Features Unique to Each

Codex CLI has:

MIT open source — inspect, fork, contribute, self-host
Full auto mode — zero-interruption execution
Network sandbox — blocks unintended network calls
o3 reasoning — OpenAI's deep reasoning model
Community extensions — growing open source ecosystem

Claude Code has:

Plan Mode — review approach before any code is written
Parallel subagents — multiple Claude instances on different parts of a task
Hooks system — run commands automatically on events
CLAUDE.md hierarchy — global + project + subdirectory context
Ultrathink — extended reasoning for the hardest problems
Headless mode — non-interactive execution for CI/automation

Plan Mode is the most significant daily differentiator. Before writing code, Claude produces a detailed plan of what it intends to do. You review and redirect before implementation — preventing the expensive failure mode of implementing the wrong approach across many files.

Open Source vs Proprietary

Codex CLI: MIT licensed. Audit the code, self-host, modify for internal use. For teams with security requirements around AI tooling, this matters.

Claude Code: Proprietary. Anthropic controls the implementation.

Decision Framework

Choose Codex CLI if:

Open source is a hard requirement
You want full auto mode for trusted environments
You want GPT-4o or o3 specifically
You want to contribute to or customize the agent itself

Choose Claude Code if:

You're already on Claude Max (no marginal cost per task)
Plan Mode is valuable — reviewing approach before implementation
You need subagents for parallel large-codebase work
The hooks system fits your automation needs
Persistent CLAUDE.md context across sessions matters

Both can coexist: Codex CLI for fast trusted dev, Claude Code for sensitive production work or complex reasoning tasks.

Full article at stacknotice.com/blog/openai-codex-vs-claude-code-2026