DEV Community: Carlos Oliva Pascual

Claude Code for PR Reviews (2026): How to Get Real Feedback, Not Generic Slop

Carlos Oliva Pascual — Tue, 16 Jun 2026 11:02:46 +0000

The first time you ask Claude to review code: "This looks good overall. Consider adding error handling and making sure tests are comprehensive."

That's not a review. That's a fortune cookie with TypeScript keywords.

The fix is context, not a better prompt.

Full guide at stacknotice.com/blog/claude-code-pr-review-guide-2026

Why generic AI review fails

When you paste a diff and say "review this," Claude doesn't know your conventions, your stack, your constraints. It falls back to universal best practices: add error handling, write tests. True but useless.

CLAUDE.md changes everything

Claude Code reads your CLAUDE.md automatically. If it says "Zustand only, no React Context" and a PR adds a Context provider — Claude flags it every time. That's specific, actionable feedback.

Prompt structure that works

Three parts: what changed, what to focus on, what to ignore.

claude "Review the PR that adds Stripe webhook handling.

Context: handles payment_intent.succeeded and customer.subscription.deleted.

Focus on:
- Idempotency: can these handlers be called twice safely?
- Auth: are we validating the Stripe signature?
- Ownership: does the subscription belong to the right org?

Skip: style, naming, test coverage."

Focused prompt → focused feedback. When Claude flags 5 things, all 5 matter.

The diff review pattern

git diff main...HEAD | claude --print \
  "Review this diff. Check: auth before data access, Zod validation on inputs,
   correct optimistic updates. Output as numbered list with file:line.
   Skip anything that's not correctness or security."

The two-Claude pattern

Most underused review technique: fresh session, no context from the author.

# Session 1: write the feature
claude "implement the cart checkout flow"

# Session 2: fresh terminal, fresh session
claude "review src/lib/checkout/ against CLAUDE.md.
What would a senior dev flag? Be direct, don't soften issues."

The author session is biased. The reviewer session isn't.

GitHub Actions

- name: Claude review
  env:
    ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
  run: |
    claude --dangerously-skip-permissions --print \
      "Review this diff. Flag only real issues: missing auth checks,
       broken error handling, convention violations. Skip style.
       Format: file:line — issue — why it matters.
       DIFF: $(cat pr.diff)" > review.md

What Claude catches better than humans

Cross-file consistency — same error handling done 5 different ways across the diff
Ownership checks — mutation without verifying the record belongs to the user
Convention violations — anything in CLAUDE.md that the PR breaks
Missing validation — input going to DB without Zod

Humans catch: wrong approach, architectural problems, intent mismatch. Both are needed.

Full guide with prompt templates at stacknotice.com/blog/claude-code-pr-review-guide-2026

Claude Code --dangerously-skip-permissions: What It Does, When It's Safe, When It's Not

Carlos Oliva Pascual — Tue, 16 Jun 2026 08:39:20 +0000

You see --dangerously-skip-permissions in the docs, think "that sounds scary but also useful," and wonder whether to use it.

Here's the full breakdown.

Full guide at stacknotice.com/blog/claude-code-skip-permissions-guide-2026

What the permission system does by default

Claude Code asks before every action: write a file, run a command, read a directory. You approve or deny each one. It's your last line of defense against Claude doing something unintended.

--dangerously-skip-permissions removes all of that. Claude runs fully autonomously — no prompts, no pauses.

Three risk tiers

Tier 1 — Low risk:

# Read-only analysis in CI — appropriate
claude --dangerously-skip-permissions --print \
  "analyze TypeScript files and list type safety issues"

No writes, no commands, no state changes. If Claude makes a mistake, the output is just text.

Tier 2 — Medium risk (use with caution):

Running Claude locally with write access. Scope the task tightly:

# Too vague — don't use the flag
claude --dangerously-skip-permissions "improve the codebase"

# Scoped — more acceptable
claude --dangerously-skip-permissions \
  "add JSDoc comments to exported functions in src/utils/"

Tier 3 — Never:

Anything touching production
Tasks involving credentials or secrets
Unscoped tasks on main branch
Any environment you don't fully control

The right use case: CI/CD

- name: Run Claude review
  env:
    ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
  run: |
    claude --dangerously-skip-permissions --print \
      "Review this PR diff for security issues and convention violations.
       $(cat pr.diff)" > review.txt

Safe here because: isolated runner, read-only diff, no writes, runner is destroyed after the job.

Safer alternatives

Allowlist specific commands instead of skipping everything — add to CLAUDE.md:

Allowed bash commands (auto-approve):
- npm test
- npm run lint
- git status

Use --print for analysis tasks that don't need writes at all.

The rule

Anthropic named it "dangerously" deliberately. They could have called it --non-interactive. The word is in the name as a signal.

Use it in isolated, controlled, or read-only environments. Keep the prompts everywhere else.

Full guide with GitHub Actions setup at stacknotice.com/blog/claude-code-skip-permissions-guide-2026

Convex + Next.js Complete Guide (2026): Realtime Backend Without the Boilerplate

Carlos Oliva Pascual — Mon, 15 Jun 2026 10:58:36 +0000

The moment you need realtime in a Next.js app — other users see changes instantly, live feeds, collaborative editing — you face a wall of setup: websockets, pub/sub, cache invalidation, optimistic updates. Convex collapses all of that into one useQuery call that stays current automatically.

This guide covers the full Convex + Next.js App Router setup from schema to production.

Full guide at stacknotice.com/blog/convex-nextjs-complete-guide-2026

Convex vs Drizzle+Neon vs Supabase

	Convex	Drizzle + Neon	Supabase
Database	Document (TypeScript)	SQL (Postgres)	SQL (Postgres)
Realtime	Built-in, reactive	Manual	Subscriptions
Schema	TypeScript	TypeScript	SQL migrations
Self-hostable	No	Yes	Yes
Best for	Realtime, collaborative	Traditional CRUD	Firebase replacement

Choose Convex when your app needs live collaboration, activity feeds, or any data multiple users see simultaneously.

Choose Drizzle + Neon when you need SQL, complex joins, or cost optimization at scale.

Schema in TypeScript

// convex/schema.ts
import { defineSchema, defineTable } from 'convex/server'
import { v } from 'convex/values'

export default defineSchema({
  tasks: defineTable({
    title: v.string(),
    done: v.boolean(),
    userId: v.string(),
    priority: v.union(v.literal('low'), v.literal('medium'), v.literal('high')),
    createdAt: v.number(),
  })
    .index('by_user', ['userId'])
    .index('by_user_done', ['userId', 'done']),
})

No SQL migration files. Convex generates TypeScript types from this automatically — your editor knows the shape of every document instantly.

Server Functions

// convex/tasks.ts
import { query, mutation } from './_generated/server'
import { v } from 'convex/values'

export const list = query({
  args: {},
  handler: async (ctx) => {
    const identity = await ctx.auth.getUserIdentity()
    if (!identity) throw new Error('Unauthorized')

    return await ctx.db
      .query('tasks')
      .withIndex('by_user', (q) => q.eq('userId', identity.subject))
      .order('desc')
      .collect()
  },
})

export const create = mutation({
  args: {
    title: v.string(),
    priority: v.union(v.literal('low'), v.literal('medium'), v.literal('high')),
  },
  handler: async (ctx, args) => {
    const identity = await ctx.auth.getUserIdentity()
    if (!identity) throw new Error('Unauthorized')

    return await ctx.db.insert('tasks', {
      title: args.title,
      done: false,
      userId: identity.subject,
      priority: args.priority,
      createdAt: Date.now(),
    })
  },
})

export const toggle = mutation({
  args: { id: v.id('tasks'), done: v.boolean() },
  handler: async (ctx, args) => {
    const identity = await ctx.auth.getUserIdentity()
    if (!identity) throw new Error('Unauthorized')

    const task = await ctx.db.get(args.id)
    // Always verify ownership before mutating
    if (!task || task.userId !== identity.subject) {
      throw new Error('Not found or unauthorized')
    }

    await ctx.db.patch(args.id, { done: args.done })
  },
})

No await db.connect(), no connection pool, no SQL strings. Functions auto-deploy when you save.

Reactive Client Queries

'use client'
import { useQuery, useMutation } from 'convex/react'
import { api } from '@/convex/_generated/api'

export function TaskList() {
  const tasks = useQuery(api.tasks.list)
  const toggle = useMutation(api.tasks.toggle)

  if (tasks === undefined) return <div>Loading...</div>

  return (
    <ul>
      {tasks.map((task) => (
        <li key={task._id}>
          <input
            type="checkbox"
            checked={task.done}
            onChange={(e) => toggle({ id: task._id, done: e.target.checked })}
          />
          <span className={task.done ? 'line-through' : ''}>{task.title}</span>
        </li>
      ))}
    </ul>
  )
}

When any other user calls toggle, every component using useQuery(api.tasks.list) re-renders instantly. No websocket code, no subscription management, no cache invalidation. tasks === undefined means loading (not null — Convex's convention).

Auth with Clerk

// app/providers.tsx
'use client'
import { ClerkProvider, useAuth } from '@clerk/nextjs'
import { ConvexProviderWithClerk } from 'convex/react-clerk'
import { ConvexReactClient } from 'convex/react'

const convex = new ConvexReactClient(process.env.NEXT_PUBLIC_CONVEX_URL!)

export function Providers({ children }: { children: React.ReactNode }) {
  return (
    <ClerkProvider>
      <ConvexProviderWithClerk client={convex} useAuth={useAuth}>
        {children}
      </ConvexProviderWithClerk>
    </ClerkProvider>
  )
}

ConvexProviderWithClerk handles token passing automatically. Your server functions call ctx.auth.getUserIdentity() to get the user — no manual JWT handling.

Server-Side Preloading (No Loading Spinner)

// app/dashboard/page.tsx
import { preloadQuery } from 'convex/nextjs'
import { api } from '@/convex/_generated/api'
import { auth } from '@clerk/nextjs/server'

export default async function DashboardPage() {
  const { getToken } = auth()
  const token = await getToken({ template: 'convex' })

  const preloadedTasks = await preloadQuery(api.tasks.list, {}, {
    token: token ?? undefined
  })

  return <TaskList preloadedTasks={preloadedTasks} />
}

Data arrives with the server-rendered HTML. The client component hydrates from it and stays reactive — no extra fetch, no loading state.

Scheduled Jobs (Built-in Cron)

// convex/crons.ts
import { cronJobs } from 'convex/server'
import { api } from './_generated/api'

const crons = cronJobs()

crons.daily(
  'send due date reminders',
  { hourUTC: 8, minuteUTC: 0 },
  api.notifications.sendDueDateReminders
)

export default crons

No external cron service, no separate worker. Scheduled functions are TypeScript alongside your other server functions.

Deploy

npx convex deploy

Atomic — either all functions deploy or none do. Set environment variables in Convex, not Vercel (except NEXT_PUBLIC_ vars):

npx convex env set RESEND_API_KEY re_...
npx convex env set CLERK_JWT_ISSUER_DOMAIN https://...

Convex changes the model: write a query, it stays current. The tradeoff is no SQL and no self-hosting. If either matters, Drizzle + Neon is the better call. For realtime, collaborative apps, or anything where "refresh to see new data" is unacceptable — Convex is the cleanest solution in the Next.js ecosystem right now.

Full guide with file storage, actions, pagination, and production checklist at stacknotice.com/blog/convex-nextjs-complete-guide-2026.

Claude Code for Teams: Shared CLAUDE.md, Hooks, and Preventing AI Drift (2026)

Carlos Oliva Pascual — Mon, 15 Jun 2026 08:13:44 +0000

Every tutorial about Claude Code assumes one developer. That's not how most software gets built.

When your entire team starts using Claude Code, a quiet problem surfaces: AI drift. Two developers ask Claude to add error handling to the same module and get incompatible implementations. One developer's Claude follows the Zod-everywhere convention, another's doesn't know about it. The junior developer's Claude makes architectural decisions that contradict what the senior dev established last week.

This is the problem no solo-dev tutorial addresses. Here's how to solve it.

Full guide at stacknotice.com/blog/claude-code-for-teams-2026

The Root Cause: Claude's Context is Per-Session

Claude Code doesn't share memory between developers. When your colleague opens a new session, their Claude knows nothing about the architectural decisions you made last Tuesday, the convention the team adopted last month, or the patterns you agreed to avoid.

The fix: make the shared context explicit and version-controlled.

The Team CLAUDE.md

Claude Code reads CLAUDE.md from multiple locations. For teams, the project-level CLAUDE.md (committed to the repo) is the key:

# Project: TaskApp — AI Conventions

## Architecture decisions (do not deviate without team discussion)
- State management: Zustand only. No Redux, no Context for global state.
- Data fetching: TanStack Query client-side, Next.js fetch for RSC.
- Validation: Zod everywhere — forms, API responses, environment variables.
- Database: Drizzle ORM with Neon. Never write raw SQL outside Drizzle.
- Auth: Clerk. Do not implement custom auth logic.

## Patterns we explicitly avoid
- No `any` types, not even temporary ones.
- No `console.log` in production — use the structured logger in src/lib/logger.ts.
- No inline styles — Tailwind only.
- No direct database access in route handlers — always go through the service layer.

## Before creating a new file, check
- Does a similar utility already exist in src/lib/?
- If adding a new dependency, confirm with the team first.

This isn't a style guide for humans — it's the instruction set every Claude session on this project reads automatically. Treat it with the same care as eslint.config.ts.

Module-Level CLAUDE.md for Critical Paths

Add CLAUDE.md in directories with high stakes:

# src/payments/CLAUDE.md

## CRITICAL — Read before touching any file here

This handles Stripe webhooks and subscription state. Mistakes cause billing failures.

## Invariants that must ALWAYS hold
- Every webhook handler MUST verify the Stripe signature before processing.
- idempotency_key is REQUIRED on every Stripe API call.
- Subscription state in DB is source of truth — never derive it from Stripe directly.

Shared PostToolUse Hook: TypeScript Check on Every Edit

Commit this to .claude/settings.json in the repo:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx tsc --noEmit 2>&1 | head -20"
          }
        ]
      }
    ]
  }
}

Every file edit triggers a TypeScript check. Claude sees the errors immediately and fixes them in the same response. Across the team, no one can merge code that breaks the type system — even if Claude generated it.

The Two-Claude Review Pattern

Most developers use Claude to write code. Teams that also use it to review catch a different class of bugs.

# Terminal 1 — Writer Claude
claude "Implement the subscription upgrade flow per docs/upgrade-flow.md.
Write tests as you go."

# Terminal 2 — Reviewer Claude (after Writer is done)
claude "A colleague just implemented the subscription upgrade flow:
$(git diff main...HEAD)

Review for correctness, security, and CLAUDE.md conventions.
Be critical. Find problems, don't approve."

The Reviewer Claude has no attachment to the Writer Claude's decisions. It reviews objectively. In practice, this catches 2-3 real issues per feature that the Writer Claude missed.

Keeping CLAUDE.md Current

Add a section Claude can update itself:

## Recent decisions (Claude may update this section)
- 2026-06-10: Switched email from Sendgrid to Resend
- 2026-06-05: Adopted Zod for all environment variables
- 2026-05-28: Drizzle transactions for all multi-table writes

## Refactors in progress
- [ ] Migrating Context to Zustand — 60% done (src/store/)
- [ ] Moving validation to Zod — 80% done

At the end of significant sessions: "Update CLAUDE.md with what we decided today." Over months, it becomes a living architecture decision record every new session inherits automatically.

The Rule: Decisions vs Preferences

Decisions (team CLAUDE.md — version controlled):

Which ORM to use
Error handling patterns
File naming conventions
Sensitive modules requiring extra care

Preferences (personal ~/.claude/CLAUDE.md):

How verbose you want explanations
Your preferred response format
Personal coding style within conventions

When everything goes into the team file, Claude starts following conflicting instructions. Keep the boundary clean.

The shift from "everyone uses Claude individually" to "the team uses Claude together" is about making implicit conventions explicit. Once the decisions live in CLAUDE.md, every developer's AI session starts from the same baseline — and AI drift stops.

Full guide with onboarding workflow, subagent parallelization, and team checklist at stacknotice.com/blog/claude-code-for-teams-2026.

next-intl: The Complete Next.js i18n Guide (2026)

Carlos Oliva Pascual — Fri, 12 Jun 2026 10:38:42 +0000

Adding a second language to an app sounds like a weekend task. In practice, most developers hit the same wall: the routing changes, the translation files become unmanageable, Server Components don't play nicely with i18n libraries, and the type safety disappears the moment you add a dynamic key.

This guide covers next-intl with the Next.js 15 App Router — the combination that solves all of these problems correctly.

The full guide with all code is at stacknotice.com/blog/nextjs-i18n-next-intl-guide-2026

Why next-intl Over the Alternatives

Library	App Router	Server Components	Type-safe keys	Middleware
next-intl	✅ Full support	✅ Native	✅	✅
next-i18next	❌ Pages Router	❌	❌	❌
i18next + react-i18next	⚠️ Manual config	❌	❌ opt-in	Manual

next-i18next is still widely referenced in older tutorials but it's fundamentally tied to Pages Router. If you're on App Router, it's a dead end. next-intl was designed for App Router from the ground up.

The Architecture: [locale] Routing

The App Router approach to i18n uses a [locale] dynamic segment at the root of the app/ directory:

app/
  [locale]/
    layout.tsx       ← sets lang attribute, wraps NextIntlClientProvider
    page.tsx
    about/
      page.tsx
middleware.ts        ← detects user locale, redirects if needed
messages/
  en.json
  es.json
  fr.json

When a user hits /, the middleware reads their Accept-Language header and redirects to /en/ or /es/. The locale is in the URL — shareable, SEO-friendly, and predictable.

Installation

npm install next-intl

Type Safety for Translation Keys

This is the part most tutorials skip:

// global.d.ts
import en from './messages/en.json'

type Messages = typeof en

declare global {
  interface IntlMessages extends Messages {}
}

From this point, t('nav.home') autocompletes, and t('nav.typo') is a type error. You can't ship a broken translation key.

Middleware for Locale Detection

// middleware.ts
import createMiddleware from 'next-intl/middleware'

export default createMiddleware({
  locales: ['en', 'es', 'fr'],
  defaultLocale: 'en',
  localePrefix: 'always',
})

export const config = {
  matcher: ['/((?!_next|_vercel|.*\\..*).*)',]
}

The middleware handles Accept-Language negotiation, cookie-based persistence, and path prefixing automatically.

Translations in Server Components

No hooks, no providers — just getTranslations:

// app/[locale]/page.tsx
import { getTranslations } from 'next-intl/server'

export default async function HomePage() {
  const t = await getTranslations('home.hero')

  return (
    <main>
      <h1>{t('title')}</h1>
      <p>{t('subtitle')}</p>
    </main>
  )
}

For SEO-critical metadata:

export async function generateMetadata({ params: { locale } }) {
  const t = await getTranslations({ locale, namespace: 'home.hero' })
  return {
    title: t('title'),
    description: t('subtitle'),
  }
}

Every page gets a translated <title> tag. That's proper multilingual SEO.

Translations in Client Components

'use client'
import { useTranslations } from 'next-intl'

export function NavBar() {
  const t = useTranslations('nav')
  return (
    <nav>
      <a href="/">{t('home')}</a>
      <a href="/about">{t('about')}</a>
    </nav>
  )
}

The messages travel with the server-rendered HTML — no extra fetch on the client.

Pluralization and Interpolation

next-intl uses ICU message format:

{
  "features": {
    "count": "{count, plural, =0 {No features yet} one {# feature} other {# features}}"
  },
  "auth": {
    "welcome": "Welcome, {name}!"
  }
}

t('features.count', { count: 0 })  // "No features yet"
t('features.count', { count: 1 })  // "1 feature"
t('features.count', { count: 5 })  // "5 features"
t('auth.welcome', { name: user.name }) // "Welcome, Alice!"

Locale Switcher Component

'use client'
import { useLocale } from 'next-intl'
import { useRouter, usePathname } from 'next/navigation'
import { useTransition } from 'react'

export function LocaleSwitcher() {
  const locale = useLocale()
  const router = useRouter()
  const pathname = usePathname()
  const [isPending, startTransition] = useTransition()

  function switchLocale(newLocale: string) {
    const segments = pathname.split('/')
    segments[1] = newLocale
    startTransition(() => router.replace(segments.join('/')))
  }

  return (
    <div>
      {['en', 'es', 'fr'].map((code) => (
        <button
          key={code}
          onClick={() => switchLocale(code)}
          disabled={isPending || code === locale}
        >
          {code.toUpperCase()}
        </button>
      ))}
    </div>
  )
}

Date and Number Formatting

import { useFormatter } from 'next-intl'

const format = useFormatter()

format.number(29.99, { style: 'currency', currency: 'USD' })
// en: "$29.99"  fr: "29,99 $US"

format.relativeTime(createdAt)
// "3 days ago" | "hace 3 días"

No moment.js, no Intl.DateTimeFormat boilerplate.

Testing Translation Completeness

Catch missing keys before production:

// __tests__/translations.test.ts
import en from '@/messages/en.json'
import es from '@/messages/es.json'

function getKeys(obj, prefix = '') {
  return Object.entries(obj).flatMap(([k, v]) =>
    typeof v === 'object' && v !== null
      ? getKeys(v, `${prefix}${k}.`)
      : [`${prefix}${k}`]
  )
}

it('es has all keys that en has', () => {
  expect(getKeys(es).sort()).toEqual(getKeys(en).sort())
})

Add a string to English, forget to translate it to Spanish — the test fails immediately.

hreflang for SEO

export async function generateMetadata() {
  return {
    alternates: {
      languages: {
        'en': 'https://yoursite.com/en',
        'es': 'https://yoursite.com/es',
        'x-default': 'https://yoursite.com/en',
      }
    }
  }
}

Next.js renders <link rel="alternate" hreflang="..."> tags automatically.

next-intl is the library that finally makes i18n in Next.js App Router feel like a first-class feature. Type-safe keys, Server Component support, and middleware-based locale detection — three hard problems solved out of the box.

Full guide at stacknotice.com/blog/nextjs-i18n-next-intl-guide-2026.

T3 Stack Complete Guide 2026: Next.js 15, tRPC v11, Drizzle + Neon

Carlos Oliva Pascual — Fri, 12 Jun 2026 09:11:27 +0000

The T3 Stack was created to solve one specific problem: full-stack TypeScript apps where the type safety falls apart at the API boundary. You define types on the server, you redefine them on the client, and when they drift apart you get runtime bugs that TypeScript never caught.

tRPC eliminates that boundary. You call server functions from the client like local functions, and TypeScript knows the exact input and output types of every call. Combined with Drizzle ORM (typed queries from your database schema) and Neon (serverless Postgres with a free tier), you get a stack where types flow from the database all the way to the UI component.

The full guide with complete code is at stacknotice.com/blog/t3-stack-complete-guide-2026

What the Modern T3 Stack Looks Like in 2026

The original T3 Stack defaulted to Prisma + PlanetScale. PlanetScale dropped their free tier in 2024, and Prisma has meaningful overhead in serverless environments. Most new projects now use:

Next.js 15 App Router (not Pages Router)
tRPC v11 with React Query integration
Drizzle ORM (not Prisma — faster, lighter, SQL-first)
Neon (not PlanetScale — free tier still alive, serverless HTTP driver)
Clerk for auth (not NextAuth — simpler, fewer sessions to manage)

Bootstrap With create-t3-app

npm create t3-app@latest my-app

Select:

TypeScript: Yes
tRPC: Yes
Drizzle: Yes (not Prisma)
Auth: No (we'll add Clerk manually)
Tailwind: Yes

Drizzle Schema as Your Source of Truth

// src/server/db/schema.ts
import { pgTable, text, boolean, timestamp } from 'drizzle-orm/pg-core'

export const tasks = pgTable('tasks', {
  id: text('id').primaryKey().$defaultFn(() => crypto.randomUUID()),
  title: text('title').notNull(),
  done: boolean('done').notNull().default(false),
  userId: text('user_id').notNull(),
  createdAt: timestamp('created_at').defaultNow().notNull(),
  updatedAt: timestamp('updated_at').defaultNow().notNull(),
})

// TypeScript type inferred from the schema — no duplication
export type Task = typeof tasks.$inferSelect
export type NewTask = typeof tasks.$inferInsert

The $inferSelect and $inferInsert types eliminate the separate interface you'd write with Prisma. Change a column, the type changes everywhere.

Database Connection with Neon HTTP Driver

// src/server/db/index.ts
import { drizzle } from 'drizzle-orm/neon-http'
import { neon } from '@neondatabase/serverless'
import * as schema from './schema'

const sql = neon(process.env.DATABASE_URL!)
export const db = drizzle(sql, { schema })

The Neon HTTP driver works in Edge Runtime and serverless functions without a connection pool to manage. For long-running Node.js servers, use the WebSocket driver instead.

tRPC Router with Authentication

// src/server/api/trpc.ts
import { initTRPC, TRPCError } from '@trpc/server'
import { auth } from '@clerk/nextjs/server'

const t = initTRPC.context<{ userId: string | null }>().create()

// Only authenticated users can call protected procedures
const enforceUserIsAuthed = t.middleware(({ ctx, next }) => {
  if (!ctx.userId) {
    throw new TRPCError({ code: 'UNAUTHORIZED' })
  }
  return next({ ctx: { ...ctx, userId: ctx.userId } })
})

export const createTRPCRouter = t.router
export const publicProcedure = t.procedure
export const protectedProcedure = t.procedure.use(enforceUserIsAuthed)

// src/server/api/routers/tasks.ts
import { z } from 'zod'
import { createTRPCRouter, protectedProcedure } from '../trpc'
import { db } from '@/server/db'
import { tasks } from '@/server/db/schema'
import { eq, and } from 'drizzle-orm'

export const tasksRouter = createTRPCRouter({
  list: protectedProcedure.query(async ({ ctx }) => {
    return db.select().from(tasks).where(eq(tasks.userId, ctx.userId))
  }),

  create: protectedProcedure
    .input(z.object({ title: z.string().min(1).max(200) }))
    .mutation(async ({ ctx, input }) => {
      const [task] = await db
        .insert(tasks)
        .values({ title: input.title, userId: ctx.userId })
        .returning()
      return task!
    }),

  toggle: protectedProcedure
    .input(z.object({ id: z.string(), done: z.boolean() }))
    .mutation(async ({ ctx, input }) => {
      const [task] = await db
        .update(tasks)
        .set({ done: input.done, updatedAt: new Date() })
        .where(and(eq(tasks.id, input.id), eq(tasks.userId, ctx.userId)))
        .returning()
      return task!
    }),

  delete: protectedProcedure
    .input(z.object({ id: z.string() }))
    .mutation(async ({ ctx, input }) => {
      await db
        .delete(tasks)
        .where(and(eq(tasks.id, input.id), eq(tasks.userId, ctx.userId)))
    }),
})

Notice the ownership check in toggle and delete: and(eq(tasks.id, input.id), eq(tasks.userId, ctx.userId)). Never trust the client's claim that a task belongs to them — always filter by both ID and userId.

Client Component with Optimistic Updates

'use client'

import { api } from '@/trpc/react'
import { useState } from 'react'

export function TaskList() {
  const utils = api.useUtils()
  const { data: tasks, isLoading } = api.tasks.list.useQuery()

  const toggle = api.tasks.toggle.useMutation({
    onMutate: async ({ id, done }) => {
      await utils.tasks.list.cancel()
      const previous = utils.tasks.list.getData()

      utils.tasks.list.setData(undefined, (old) =>
        old?.map((t) => (t.id === id ? { ...t, done } : t))
      )
      return { previous }
    },
    onError: (_, __, ctx) => {
      utils.tasks.list.setData(undefined, ctx?.previous)
    },
    onSettled: () => utils.tasks.list.invalidate(),
  })

  if (isLoading) return <div>Loading...</div>

  return (
    <ul>
      {tasks?.map((task) => (
        <li key={task.id}>
          <input
            type="checkbox"
            checked={task.done}
            onChange={(e) => toggle.mutate({ id: task.id, done: e.target.checked })}
          />
          <span className={task.done ? 'line-through opacity-50' : ''}>
            {task.title}
          </span>
        </li>
      ))}
    </ul>
  )
}

The onMutate → onError → onSettled pattern gives you instant UI feedback with automatic rollback if the server rejects the mutation.

Server-Side Prefetching

For pages that need data immediately (no loading spinner on first paint):

// app/dashboard/page.tsx
import { HydrateClient, api } from '@/trpc/server'
import { TaskList } from './_components/TaskList'

export default async function DashboardPage() {
  // Prefetch on the server — data is ready when the component mounts
  void api.tasks.list.prefetch()

  return (
    <HydrateClient>
      <TaskList />
    </HydrateClient>
  )
}

HydrateClient serializes the prefetched data into the HTML. The client-side TaskList component finds the data already in the React Query cache when it mounts — no loading state, no extra fetch.

Summary

The T3 Stack in 2026 is cleaner than it's ever been:

Drizzle gives you SQL-native queries with TypeScript types inferred from the schema
Neon gives you serverless Postgres that works in Edge Runtime
tRPC v11 with protectedProcedure gives you auth at the API layer without middleware duplication
Optimistic updates with onMutate/onError/onSettled give you fast UI without complexity

The full guide with environment setup, migrations, form validation with Zod + React Hook Form, and deployment is at stacknotice.com/blog/t3-stack-complete-guide-2026.

AWS S3 File Uploads in Next.js 15: Presigned URLs, Progress & CloudFront (2026)

Carlos Oliva Pascual — Thu, 11 Jun 2026 14:04:26 +0000

UploadThing is fast to set up but at scale you're paying per GB stored and transferred. At 10k MAU uploading profile photos, you're looking at $50–200/month for a service that wraps S3 — when S3 itself costs $2–5/month for the same data.

This guide covers direct S3 uploads from Next.js using presigned URLs: no file touching your server, real progress tracking, file type/size validation, multiple file uploads, and CloudFront CDN.

Full guide: stacknotice.com/blog/aws-s3-nextjs-file-upload-2026

How Presigned URLs Work

Client → POST /api/upload/presign → Server generates signed S3 URL
Client → PUT [presigned URL] → S3 directly (server never touches bytes)
Client → POST /api/upload/confirm → Server saves key to database

Your server generates a temporary, signed URL. The client uploads directly to S3. Zero bytes through your server.

Setup

npm install @aws-sdk/client-s3 @aws-sdk/s3-request-presigner

// lib/s3.ts
import { S3Client } from '@aws-sdk/client-s3'

export const s3 = new S3Client({
  region: process.env.AWS_REGION!,
  credentials: {
    accessKeyId: process.env.AWS_ACCESS_KEY_ID!,
    secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY!,
  },
})

export const S3_BUCKET = process.env.S3_BUCKET_NAME!
export const CDN_DOMAIN = process.env.CLOUDFRONT_DOMAIN!

export const s3KeyToCdnUrl = (key: string) => `${CDN_DOMAIN}/${key}`

S3 CORS Config

Without this, browser uploads are blocked:

[{
  "AllowedHeaders": ["*"],
  "AllowedMethods": ["GET", "PUT", "POST", "DELETE"],
  "AllowedOrigins": ["https://yourapp.com", "http://localhost:3000"],
  "ExposeHeaders": ["ETag"],
  "MaxAgeSeconds": 3000
}]

Presign API Route

// app/api/upload/presign/route.ts
import { PutObjectCommand } from '@aws-sdk/client-s3'
import { getSignedUrl } from '@aws-sdk/s3-request-presigner'
import { s3, S3_BUCKET } from '@/lib/s3'
import { auth } from '@/lib/auth'
import { randomUUID } from 'crypto'

const ALLOWED_TYPES: Record<string, string> = {
  'image/jpeg': 'jpg', 'image/png': 'png', 'image/webp': 'webp',
  'application/pdf': 'pdf',
}
const MAX_FILE_SIZE = 10 * 1024 * 1024 // 10MB

export async function POST(request: Request) {
  const session = await auth()
  if (!session) return Response.json({ error: 'Unauthorized' }, { status: 401 })

  const { fileName, fileType, fileSize, folder = 'uploads' } = await request.json()

  if (!ALLOWED_TYPES[fileType])
    return Response.json({ error: 'File type not allowed' }, { status: 400 })

  if (fileSize > MAX_FILE_SIZE)
    return Response.json({ error: 'File too large (max 10MB)' }, { status: 400 })

  // Key: folder/userId/uuid.ext — scoped to user, no collisions
  const key = `${folder}/${session.userId}/${randomUUID()}.${ALLOWED_TYPES[fileType]}`

  const command = new PutObjectCommand({
    Bucket: S3_BUCKET,
    Key: key,
    ContentType: fileType,
    ContentLength: fileSize,
  })

  const presignedUrl = await getSignedUrl(s3, command, { expiresIn: 900 })

  return Response.json({ presignedUrl, key })
}

Upload Hook with Progress Tracking

fetch() doesn't expose upload progress — XHR does:

// hooks/useS3Upload.ts
export function useS3Upload() {
  const [state, setState] = useState({
    progress: 0,
    status: 'idle' as 'idle' | 'uploading' | 'success' | 'error',
    key: null as string | null,
    error: null as string | null,
  })

  const upload = async (file: File, folder = 'uploads') => {
    setState({ progress: 0, status: 'uploading', key: null, error: null })

    try {
      const res = await fetch('/api/upload/presign', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ fileName: file.name, fileType: file.type, fileSize: file.size, folder }),
      })
      if (!res.ok) throw new Error((await res.json()).error)

      const { presignedUrl, key } = await res.json()

      // XHR for real progress events
      await new Promise<void>((resolve, reject) => {
        const xhr = new XMLHttpRequest()
        xhr.upload.onprogress = (e) => {
          if (e.lengthComputable)
            setState((p) => ({ ...p, progress: Math.round((e.loaded / e.total) * 100) }))
        }
        xhr.onload = () => xhr.status < 300 ? resolve() : reject(new Error(`S3 error ${xhr.status}`))
        xhr.onerror = () => reject(new Error('Network error'))
        xhr.open('PUT', presignedUrl)
        xhr.setRequestHeader('Content-Type', file.type)
        xhr.send(file)
      })

      setState({ progress: 100, status: 'success', key, error: null })
      return key as string
    } catch (err) {
      const error = err instanceof Error ? err.message : 'Upload failed'
      setState({ progress: 0, status: 'error', key: null, error })
      return null
    }
  }

  return { upload, state, reset: () => setState({ progress: 0, status: 'idle', key: null, error: null }) }
}

Upload Component

export function FileUpload({ folder, onUploadComplete }: {
  folder?: string
  onUploadComplete?: (url: string, key: string) => void
}) {
  const inputRef = useRef<HTMLInputElement>(null)
  const { upload, state, reset } = useS3Upload()

  const handleFile = async (e: React.ChangeEvent<HTMLInputElement>) => {
    const file = e.target.files?.[0]
    if (!file) return
    const key = await upload(file, folder)
    if (key) onUploadComplete?.(s3KeyToCdnUrl(key), key)
  }

  return (
    <div>
      <button onClick={() => inputRef.current?.click()} disabled={state.status === 'uploading'}>
        {state.status === 'uploading' ? `${state.progress}%` : 'Upload file'}
      </button>
      <input ref={inputRef} type="file" onChange={handleFile} className="hidden" />
      {state.status === 'uploading' && (
        <div className="h-1 bg-gray-200 rounded">
          <div className="h-full bg-blue-500 rounded transition-all" style={{ width: `${state.progress}%` }}/>
        </div>
      )}
      {state.error && <p className="text-red-500 text-sm">{state.error} <button onClick={reset}>Retry</button></p>}
    </div>
  )
}

Saving to Database

// app/api/upload/confirm/route.ts
export async function POST(request: Request) {
  const session = await auth()
  if (!session) return Response.json({ error: 'Unauthorized' }, { status: 401 })

  const { key, fileName, fileType, fileSize } = await request.json()

  // Validate ownership: key = folder/userId/uuid.ext
  if (key.split('/')[1] !== session.userId)
    return Response.json({ error: 'Forbidden' }, { status: 403 })

  const [file] = await db.insert(userFiles)
    .values({ userId: session.userId, s3Key: key, fileName, fileType, fileSize, url: s3KeyToCdnUrl(key) })
    .returning()

  return Response.json({ file })
}

CloudFront CDN

Files served directly from S3 are slow for users outside your bucket's region. CloudFront caches at 400+ edge locations — 10–50ms vs 200–500ms.

CloudFront → Create distribution → Origin: your S3 bucket
Restrict bucket access to CloudFront only
Update bucket policy to allow CloudFront's ARN

Now s3KeyToCdnUrl() returns CloudFront URLs — bucket stays private, files serve globally fast.

S3 vs UploadThing

	S3 direct	UploadThing
Setup	~2 hours	~20 min
Cost at scale	$0.023/GB/month	$0.10/GB + fees
Progress	Custom (XHR)	Built-in
Self-hosted	✅	❌

Use UploadThing when moving fast. Switch to direct S3 when your storage bill exceeds $20/month.

Full guide with multiple file uploads, delete endpoint, CloudFront setup, and env checklist: stacknotice.com/blog/aws-s3-nextjs-file-upload-2026

Claude Code TDD: Force Red-Green-Refactor with Hooks & CLAUDE.md (2026)

Carlos Oliva Pascual — Thu, 11 Jun 2026 11:31:19 +0000

The problem with AI-assisted TDD isn't that Claude can't write tests — it's that without constraints, Claude writes implementation first, then writes tests that match that implementation. You get 100% test coverage and zero confidence the tests catch anything.

This guide shows how to configure Claude Code so TDD isn't a guideline you might forget — it's the only workflow available.

Full guide: stacknotice.com/blog/claude-code-tdd-workflow-2026

The Fix: CLAUDE.md Rules

## Development workflow — STRICT TDD (always follow this order)

1. **RED**: Write a failing test first. Run `npm test` — confirm it FAILS.
   Do NOT write implementation before this step.

2. **GREEN**: Write the minimum code to make the test pass.
   Run `npm test` — confirm ALL tests pass.

3. **REFACTOR**: Clean up without changing behavior.
   Run tests after every change.

**Rules:**
- Never write implementation without a failing test first.
- Never write more implementation than the current test requires.
- One cycle at a time: RED → GREEN → REFACTOR before the next feature.

Hooks: Auto-Run Tests After Every Write

// .claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npm test -- --reporter=verbose 2>&1 | tail -20"
          }
        ]
      }
    ]
  }
}

Every time Claude writes a file, your test suite runs automatically. Claude immediately sees whether the test is red or green — no manual npm test needed.

A Real TDD Cycle

Prompt:

Build a `validatePassword` function. Follow TDD per CLAUDE.md:
write the test first, confirm RED, then implement.

Requirements: 8+ chars, 1 uppercase, 1 number.
Returns { valid: boolean, errors: string[] }

Claude writes the test first:

// src/lib/password.test.ts
describe('validatePassword', () => {
  it('returns valid for a strong password', () => {
    expect(validatePassword('SecurePass1')).toEqual({ valid: true, errors: [] })
  })

  it('fails when too short', () => {
    const result = validatePassword('Sh0rt')
    expect(result.valid).toBe(false)
    expect(result.errors).toContain('Password must be at least 8 characters')
  })

  it('fails when no uppercase', () => {
    const result = validatePassword('lowercase1')
    expect(result.errors).toContain('Password must contain at least one uppercase letter')
  })

  it('fails when no number', () => {
    const result = validatePassword('NoNumbers')
    expect(result.errors).toContain('Password must contain at least one number')
  })
})

Hook fires → test output in context: RED (module not found).

Claude writes minimum implementation:

// src/lib/password.ts
export function validatePassword(password: string) {
  const errors: string[] = []

  if (password.length < 8) errors.push('Password must be at least 8 characters')
  if (!/[A-Z]/.test(password)) errors.push('Password must contain at least one uppercase letter')
  if (!/[0-9]/.test(password)) errors.push('Password must contain at least one number')

  return { valid: errors.length === 0, errors }
}

Hook fires → GREEN. All 4 tests pass.

Testing React Components

// src/components/PasswordInput.test.tsx
describe('PasswordInput', () => {
  it('renders input with label', () => {
    render(<PasswordInput label="Password" />)
    expect(screen.getByLabelText('Password')).toBeInTheDocument()
  })

  it('toggles password visibility', async () => {
    const user = userEvent.setup()
    render(<PasswordInput label="Password" />)

    const input = screen.getByLabelText('Password')
    expect(input).toHaveAttribute('type', 'password')

    await user.click(screen.getByRole('button', { name: /show password/i }))
    expect(input).toHaveAttribute('type', 'text')
  })

  it('shows strength indicator', async () => {
    const user = userEvent.setup()
    render(<PasswordInput label="Password" />)

    await user.type(screen.getByLabelText('Password'), 'StrongPass1')
    expect(screen.getByText('Strong')).toBeInTheDocument()
  })
})

Write test → confirm RED → implement → GREEN. Same cycle, same discipline.

Where TDD Proves Its Value: Regressions

Three weeks later, add a special character requirement:

Add: at least one special character. Write the failing test first.

Claude adds one test → it fails → Claude adds one line to the validator → all 5 tests pass. The existing tests are a regression net. If the new code breaks the uppercase check, you see it immediately.

Handling Claude Skipping TDD

If mid-session Claude writes implementation before tests:

Stop. You wrote implementation before the test.
Delete `src/lib/feature.ts`. Write the test first, confirm RED, then implement.

Explicit course corrections work reliably. If it keeps happening, /compact to clear context.

Pre-commit Hook

Block commits when tests fail:

# .husky/pre-commit
#!/bin/sh
npm test -- --run

Commit your .claude/settings.json alongside CLAUDE.md — every team member gets the same TDD enforcement automatically.

Full guide with Route Handler testing, component testing patterns, and multi-step examples: stacknotice.com/blog/claude-code-tdd-workflow-2026

Inngest + Next.js: The Complete Guide (2026)

Carlos Oliva Pascual — Wed, 10 Jun 2026 15:21:47 +0000

Serverless functions have a time limit. Vercel gives you 60 seconds on Pro. None of that is enough to send a welcome email sequence, process an uploaded CSV, or run any workflow with multiple external API calls.

Inngest solves this by turning your Next.js API routes into reliable, retryable, observable background jobs — without Redis, without a worker process, without any separate queue infrastructure.

Read the full guide with all code examples at stacknotice.com

How It Works

You define functions that run in response to events. When an event fires, Inngest calls your function via HTTP. If the function fails, Inngest retries it. If the function has multiple steps, Inngest checkpoints each step so a failure halfway through doesn't restart from scratch.

Setup

npm install inngest

// lib/inngest/client.ts
import { Inngest } from 'inngest'

export const inngest = new Inngest({ id: 'my-app' })

// app/api/inngest/route.ts
import { serve } from 'inngest/next'
import { inngest } from '@/lib/inngest/client'
import { welcomeSequence } from '@/lib/inngest/functions/welcome'

export const { GET, POST, PUT } = serve({
  client: inngest,
  functions: [welcomeSequence],
})

Welcome Email Sequence

export const welcomeSequence = inngest.createFunction(
  { id: 'welcome-email-sequence', retries: 3 },
  { event: 'user/signed-up' },
  async ({ event, step }) => {
    const { userId, email, name } = event.data

    // Each step is independently retried
    await step.run('send-welcome-email', async () => {
      await resend.emails.send({
        from: 'hello@yourapp.com',
        to: email,
        subject: `Welcome, ${name}!`,
        html: `<p>Thanks for signing up...</p>`,
      })
    })

    await step.sleep('wait-2-days', '2 days')

    await step.run('send-tips-email', async () => {
      await resend.emails.send({
        from: 'hello@yourapp.com',
        to: email,
        subject: 'Top 5 tips to get the most out of the app',
        html: `<p>Here are the tips...</p>`,
      })
    })

    await step.sleep('wait-5-more-days', '5 days')

    const user = await step.run('check-user-plan', async () => {
      return db.query.users.findFirst({ where: eq(users.id, userId) })
    })

    if (user?.plan === 'free') {
      await step.run('send-upgrade-email', async () => {
        await resend.emails.send({
          from: 'hello@yourapp.com',
          to: email,
          subject: "You've been on the free plan for a week...",
          html: `<p>Here's what Pro unlocks...</p>`,
        })
      })
    }
  }
)

Trigger from a Route Handler — inngest.send() returns immediately:

await inngest.send({
  name: 'user/signed-up',
  data: { userId: user.id, email, name },
})

Steps: The Core Primitive

step.run() is checkpointed — if a later step fails, earlier steps don't re-run:

export const processUpload = inngest.createFunction(
  { id: 'process-csv-upload', retries: 2 },
  { event: 'file/uploaded' },
  async ({ event, step }) => {
    const rows = await step.run('parse-csv', async () => {
      const response = await fetch(event.data.fileUrl)
      return parseCSV(await response.text())
    })

    const { valid, invalid } = await step.run('validate-rows', async () => {
      return validateCSVRows(rows)
    })

    await step.run('insert-to-database', async () => {
      const batches = chunk(valid, 100)
      for (const batch of batches) {
        await db.insert(contacts).values(batch).onConflictDoNothing()
      }
    })

    await step.run('notify-user', async () => {
      await sendNotification(event.data.userId, {
        message: `Import complete: ${valid.length} added, ${invalid.length} skipped`,
      })
    })
  }
)

Fan-Out: Parallel Steps

const [salesReport, usageReport, churnReport] = await Promise.all([
  step.run('generate-sales', () => buildSalesReport(month, year)),
  step.run('generate-usage', () => buildUsageReport(month, year)),
  step.run('generate-churn', () => buildChurnReport(month, year)),
])
// Runs concurrently — waits for all three before continuing

Cron Jobs

export const weeklyDigest = inngest.createFunction(
  { id: 'weekly-digest', retries: 2 },
  { cron: '0 9 * * MON' }, // Every Monday at 9am UTC
  async ({ step }) => {
    const users = await step.run('get-users', async () => {
      return db.query.users.findMany({ where: eq(users.weeklyDigest, true) })
    })

    // Fan out to individual per-user events for large lists
    await inngest.send(
      users.map((user) => ({
        name: 'digest/send-to-user',
        data: { userId: user.id },
      }))
    )

    return { queued: users.length }
  }
)

waitForEvent: Human-in-the-Loop

Pause a function and wait for an external event to resume it:

export const approvalWorkflow = inngest.createFunction(
  { id: 'content-approval-workflow' },
  { event: 'content/submitted' },
  async ({ event, step }) => {
    await step.run('notify-reviewer', async () => {
      await sendReviewRequest(event.data.reviewerId, event.data.contentId)
    })

    // Wait up to 48 hours for approval
    const approval = await step.waitForEvent('wait-for-approval', {
      event: 'content/reviewed',
      match: 'data.contentId',
      timeout: '48h',
    })

    if (!approval) {
      await step.run('escalate', () => escalateToAdmin(event.data.contentId))
      return { status: 'escalated' }
    }

    if (approval.data.approved) {
      await step.run('publish', () => publishContent(event.data.contentId))
      return { status: 'published' }
    }
  }
)

Type-Safe Events

type Events = {
  'user/signed-up': {
    data: { userId: string; email: string; name: string; plan: 'free' | 'pro' }
  }
  'file/uploaded': {
    data: { fileUrl: string; userId: string; fileName: string }
  }
}

export const inngest = new Inngest({
  id: 'my-app',
  schemas: new EventSchemas().fromRecord<Events>(),
})
// inngest.send() now type-checks event names and data shapes

Error Handling

import { NonRetriableError } from 'inngest'

// Retryable error — just throw
throw new Error('External API failed')

// Non-retryable — use NonRetriableError
throw new NonRetriableError('Invalid email — will not retry')

Inngest vs Trigger.dev

Feature	Inngest	Trigger.dev
Step functions	`step.run()`	`task()`
waitForEvent	✅ Built-in	Manual polling
Self-host	❌	✅ Open-source
Free tier	50k runs/month	50k runs/month

Choose Inngest for human-in-the-loop workflows. Choose Trigger.dev for self-hosting.

Local Dev

npx inngest-cli@latest dev

Visual dashboard at http://localhost:8288 — trigger test events, inspect step-by-step execution. No cloud account needed for local dev.

Full guide with deployment config, advanced retries, and fan-out patterns: stacknotice.com/blog/inngest-nextjs-complete-guide-2026

Elysia.js + Bun: The Complete Guide (2026)

Carlos Oliva Pascual — Wed, 10 Jun 2026 12:07:49 +0000

Elysia.js is a Bun-native HTTP framework that handles over 500,000 requests per second in benchmarks. That number is real — it comes from Bun's native HTTP server combined with Elysia's zero-overhead routing. But raw speed isn't the reason to use it. The reason is Eden Treaty: end-to-end type safety between your server and client with zero code generation.

Read the full article with all code examples at stacknotice.com

Setup

bun create elysia my-api
cd my-api
bun run dev

Minimum working server:

// src/index.ts
import { Elysia } from 'elysia'

const app = new Elysia()
  .get('/', () => 'Hello Elysia')
  .listen(3000)

// This export is what enables Eden Treaty
export type App = typeof app

Routing with TypeBox Validation

import { Elysia, t } from 'elysia'

const app = new Elysia()
  .get('/users', () => getUsers())
  .get('/users/:id', ({ params }) => getUserById(params.id))
  .post('/users', ({ body }) => createUser(body), {
    body: t.Object({
      name: t.String({ minLength: 1 }),
      email: t.String({ format: 'email' }),
      role: t.Union([t.Literal('admin'), t.Literal('user')]),
    }),
  })
  .delete('/users/:id', ({ params }) => deleteUser(params.id))

The t namespace is TypeBox — one schema for both runtime validation and TypeScript types.

Route Groups as Plugins

// src/routes/users.ts
export const usersRouter = new Elysia({ prefix: '/users' })
  .get('/', () => UserService.getAll())
  .get('/:id', ({ params }) => UserService.getById(params.id))
  .post('/', ({ body }) => UserService.create(body), {
    body: t.Object({
      name: t.String(),
      email: t.String({ format: 'email' }),
    }),
  })

// src/index.ts
const app = new Elysia()
  .use(usersRouter)
  .use(productsRouter)
  .listen(3000)

export type App = typeof app

Auth Middleware with `derive`

export const authPlugin = new Elysia({ name: 'auth' })
  .derive({ as: 'scoped' }, async ({ headers, error }) => {
    const token = headers['authorization']?.slice(7)
    if (!token) throw error(401, 'Missing token')

    const payload = await verifyJWT(token)
    if (!payload) throw error(401, 'Invalid token')

    return {
      user: {
        id: payload.sub as string,
        email: payload.email as string,
        role: payload.role as 'admin' | 'user',
      },
    }
  })

// Apply to protected routes
export const protectedRouter = new Elysia({ prefix: '/api' })
  .use(authPlugin)
  .get('/me', ({ user }) => user) // `user` is fully typed

{ as: 'scoped' } means the derived context only applies to this instance — not to parent or sibling routes.

Eden Treaty — The Killer Feature

On your client, import the App type and create a typed client:

// client/api.ts
import { treaty } from '@elysiajs/eden'
import type { App } from '../server/src/index'

export const api = treaty<App>('http://localhost:3000')

Now you have a typed client that mirrors your API structure:

// Fully typed — no codegen, no schema files
const { data: users } = await api.users.get()
const { data: user } = await api.users({ id: '123' }).get()
const { data: newUser } = await api.users.post({
  name: 'Alice',
  email: 'alice@example.com',
})

// TypeScript error — body doesn't match schema
// @ts-expect-error
await api.users.post({ name: 123 }) // must be string

When you change a route's input shape on the server, TypeScript errors appear at every client call site that's now wrong. Zero manual type updates.

Drizzle ORM Integration

// src/plugins/database.ts
import { Elysia } from 'elysia'
import { db } from '../db'

export const databasePlugin = new Elysia({ name: 'database' })
  .decorate('db', db)

// src/routes/posts.ts
export const postsRouter = new Elysia({ prefix: '/posts' })
  .use(databasePlugin)
  .use(authPlugin)
  .get('/', async ({ db }) => {
    return db.select().from(posts).orderBy(desc(posts.publishedAt))
  })
  .post('/', async ({ db, body, user }) => {
    const [post] = await db.insert(posts)
      .values({ ...body, authorId: user.id })
      .returning()
    return post
  }, {
    body: t.Object({
      title: t.String({ minLength: 1 }),
      content: t.String({ minLength: 1 }),
    }),
  })

Common Plugins

bun add @elysiajs/cors @elysiajs/swagger @elysiajs/bearer

const app = new Elysia()
  .use(cors({ origin: ['http://localhost:3000'] }))
  .use(swagger()) // Auto-generated Swagger UI at /swagger
  .use(bearer())  // Extracts Bearer token to context.bearer

The swagger() plugin reads your TypeBox schemas and generates OpenAPI docs automatically.

Elysia vs Alternatives

Use case	Best choice
Bun-only, need Eden Treaty	Elysia
Multi-runtime (Workers, Deno, Node)	Hono
Full Next.js stack	Next.js Route Handlers
tRPC-style type safety	tRPC + Next.js
Microservices in Bun	Elysia

Elysia makes the most sense when you're fully committed to Bun and want end-to-end type safety without tRPC's JSON-RPC overhead. If you need Cloudflare Workers or Deno Deploy, use Hono instead.

For the full guide with lifecycle hooks, global error handling, performance details, and deployment config: stacknotice.com/blog/elysiajs-bun-complete-guide-2026

Upstash Redis + Next.js: The Complete Guide (2026)

Carlos Oliva Pascual — Wed, 10 Jun 2026 09:21:52 +0000

Redis is fast. But self-hosting Redis on a serverless stack is a nightmare — cold starts, connection pool exhaustion, and managing a persistent server that your serverless functions keep hammering. Upstash solves this with an HTTP-based Redis API that scales to zero, charges per request, and works natively with Next.js App Router.

This guide covers the patterns that actually matter in production: cache-aside with proper TTLs, SWR (stale-while-revalidate), session storage, and pub/sub. Real code, real trade-offs.

Read the full article with all code examples at stacknotice.com

Why Upstash Over a Traditional Redis Instance

Standard Redis uses persistent TCP connections. Serverless functions don't maintain persistent connections — every invocation potentially opens a new one. At scale, you hit ECONNREFUSED or max connection errors that are annoying to debug and expensive to fix.

Upstash's @upstash/redis client talks over HTTP/REST. No connection pool, no connection limit headaches. Each request is stateless. This is exactly what Next.js Server Components and Route Handlers need.

Other advantages:

Pay per request — a cache that never gets hit costs $0
Global replication — low latency from any Vercel edge region
Native Edge Runtime support — works in Next.js middleware
Free tier — 10,000 commands/day, no credit card needed

Setup

npm install @upstash/redis

// lib/redis.ts
import { Redis } from '@upstash/redis'

export const redis = new Redis({
  url: process.env.UPSTASH_REDIS_REST_URL!,
  token: process.env.UPSTASH_REDIS_REST_TOKEN!,
})

Pattern 1: Cache-Aside

// lib/cache.ts
import { redis } from './redis'

export async function withCache<T>(
  key: string,
  fetcher: () => Promise<T>,
  options: { ttl?: number; prefix?: string } = {}
): Promise<T> {
  const { ttl = 300, prefix = 'cache' } = options
  const cacheKey = `${prefix}:${key}`

  const cached = await redis.get<T>(cacheKey)
  if (cached !== null) return cached

  const data = await fetcher()
  await redis.setex(cacheKey, ttl, JSON.stringify(data))
  return data
}

Usage in a Server Component:

// app/products/page.tsx
export default async function ProductsPage() {
  const products = await withCache(
    'products:all',
    () => db.query.products.findMany({ where: eq(products.active, true) }),
    { ttl: 60 * 5 }
  )
  return <ProductList products={products} />
}

Pattern 2: Key Namespacing

// lib/cache-keys.ts
export const CacheKeys = {
  userProfile: (userId: string) => `user:${userId}:profile`,
  products: () => 'products:all',
  productById: (id: string) => `product:${id}`,
  pricingPlans: () => 'pricing:plans',
}

// Deterministic invalidation
async function invalidateUserCache(userId: string) {
  await redis.del(CacheKeys.userProfile(userId))
}

Pattern 3: Stale-While-Revalidate

SWR solves the thundering herd problem — serves stale data immediately while refreshing in the background:

export async function withSWRCache<T>(
  key: string,
  fetcher: () => Promise<T>,
  options: { freshTtl: number; staleTtl: number }
): Promise<T> {
  const entry = await redis.get<{ data: T; cachedAt: number }>(key)

  if (entry !== null) {
    const age = (Date.now() - entry.cachedAt) / 1000
    if (age <= options.freshTtl) return entry.data

    // Stale — revalidate in background, return old data now
    revalidateInBackground(key, fetcher, options.staleTtl)
    return entry.data
  }

  const data = await fetcher()
  await redis.setex(key, options.staleTtl, JSON.stringify({ data, cachedAt: Date.now() }))
  return data
}

Pattern 4: Session Storage

// lib/sessions.ts
export async function createSession(data: Omit<Session, 'createdAt'>): Promise<string> {
  const sessionId = randomBytes(32).toString('hex')
  const session: Session = { ...data, createdAt: Date.now() }
  await redis.setex(`session:${sessionId}`, SESSION_TTL, JSON.stringify(session))
  return sessionId
}

export async function getSession(sessionId: string): Promise<Session | null> {
  return redis.get<Session>(`session:${sessionId}`)
}

Pattern 5: Rate Limiting

import { Ratelimit } from '@upstash/ratelimit'

export const apiRateLimit = new Ratelimit({
  redis,
  limiter: Ratelimit.slidingWindow(10, '10 s'),
  analytics: true,
})

// In a Route Handler:
const { success, limit, remaining } = await apiRateLimit.limit(ip)
if (!success) {
  return Response.json({ error: 'Too many requests' }, { status: 429 })
}

Pattern 6: Distributed Locks

export async function acquireLock(resource: string, ttl: number): Promise<string | null> {
  const lockId = crypto.randomUUID()
  const result = await redis.set(`lock:${resource}`, lockId, { nx: true, ex: ttl })
  return result === 'OK' ? lockId : null
}

What to Cache vs What Not to Cache

Cache: Database query results, external API responses, computed/aggregated data, feature flag states

Don't cache: Auth checks, financial transactions, real-time inventory, user-specific private data without scoping to user ID

Upstash Pricing

Tier	Price	Commands/day
Free	$0	10,000
Pay-as-you-go	$0.20/100K	Unlimited
Pro	$10/month	Unlimited

For the complete guide with all patterns, code examples, and Middleware-level caching: stacknotice.com/blog/upstash-redis-nextjs-complete-guide-2026

Best Tailwind CSS UI Libraries in 2026 (Beyond shadcn/ui)

Carlos Oliva Pascual — Tue, 09 Jun 2026 11:50:43 +0000

Everyone knows shadcn/ui at this point. But there are a dozen Tailwind-based component libraries worth knowing about in 2026, and some of them are a better fit for specific project types than shadcn.

This is a practical comparison with real code — not a list of library names and screenshots.

How I Evaluated These

A library makes this list if:

It actively works with Tailwind CSS v4 (or has a clear v4 migration path)
The components are accessible by default (keyboard nav, ARIA, screen reader tested)
It has TypeScript types and a React API that doesn't feel like an afterthought
There's real documentation with copy-paste examples

1. shadcn/ui — Still the Default

If you don't have a specific reason to use something else, use shadcn/ui. It's not a package you install — it's a collection of components you copy into your project. That single decision changes everything: you own the code, you can modify any component without fighting the library, and bundle size is exactly what you use.

npx shadcn@latest init
npx shadcn@latest add button card input form

import { Button } from "@/components/ui/button";
import { Card, CardContent, CardHeader, CardTitle } from "@/components/ui/card";

export function PricingCard({ plan, price }: { plan: string; price: number }) {
  return (
    <Card>
      <CardHeader>
        <CardTitle>{plan}</CardTitle>
      </CardHeader>
      <CardContent>
        <p className="text-3xl font-bold">${price}<span className="text-sm font-normal">/mo</span></p>
        <Button className="w-full mt-4">Get Started</Button>
      </CardContent>
    </Card>
  );
}

Best for: React projects, Next.js apps, any project where you want full control over component internals.

Not ideal for: Teams that want pre-packaged design systems without per-component customization work.

2. daisyUI v5 — Best for Rapid Prototyping

daisyUI adds semantic class names on top of Tailwind. Instead of writing bg-blue-500 text-white rounded-lg px-4 py-2, you write btn btn-primary. It ships with 35 built-in themes and a theme generator.

npm install daisyui@latest

// tailwind.config.js
export default {
  plugins: [require("daisyui")],
  daisyui: {
    themes: ["light", "dark", "cupcake"],
  },
};

<button class="btn btn-primary">Get Started</button>
<button class="btn btn-outline btn-secondary">Learn More</button>

<div class="card w-96 bg-base-100 shadow-xl">
  <div class="card-body">
    <h2 class="card-title">Pro Plan</h2>
    <p>$29/month</p>
    <div class="card-actions justify-end">
      <button class="btn btn-primary">Subscribe</button>
    </div>
  </div>
</div>

daisyUI v5 (released 2025) rewrote the internals to use CSS variables instead of Tailwind config, which means themes work without JavaScript and load faster.

Best for: Prototypes, internal tools, side projects where you need something that looks good quickly.

3. HeroUI v2 — Polished Defaults with Dark Mode

HeroUI (formerly NextUI) provides production-ready React components with built-in dark mode, smooth animations, and a design language that works for SaaS products without requiring a lot of customization.

npm install @heroui/react framer-motion

import { Button, Card, CardBody, CardHeader } from "@heroui/react";

export function FeatureCard({ title, description }: {
  title: string;
  description: string;
}) {
  return (
    <Card className="max-w-sm">
      <CardHeader className="pb-0">
        <h4 className="font-bold text-large">{title}</h4>
      </CardHeader>
      <CardBody className="overflow-visible py-2">
        <p className="text-default-500">{description}</p>
        <Button color="primary" className="mt-4">Learn More</Button>
      </CardBody>
    </Card>
  );
}

Best for: SaaS products, dashboards, apps targeting B2B users who expect clean professional UI.

4. Tremor v4 — Charts and Dashboards

Tremor is built specifically for dashboard interfaces. It has chart components (line, bar, donut, area), metric cards, and data display primitives that other libraries don't ship.

npm install @tremor/react

import { AreaChart, Card, Metric, Text } from "@tremor/react";

const data = [
  { date: "Jan 24", Revenue: 4200 },
  { date: "Feb 24", Revenue: 5800 },
  { date: "Mar 24", Revenue: 7200 },
  { date: "Apr 24", Revenue: 6900 },
  { date: "May 24", Revenue: 9100 },
];

export function RevenueDashboard() {
  return (
    <Card>
      <Text>Monthly Revenue</Text>
      <Metric>$33,200</Metric>
      <AreaChart
        data={data}
        index="date"
        categories={["Revenue"]}
        colors={["sky"]}
        className="mt-6 h-48"
      />
    </Card>
  );
}

Best for: Analytics dashboards, SaaS admin panels, anything with data visualization.

5. Headless UI v2 — Unstyled, Fully Accessible

Headless UI gives you complex interactive components (combobox, listbox, dialog, menu, switch) with complete accessibility built in — keyboard nav, ARIA attributes, focus management — but with zero visual styles. You bring all the Tailwind classes.

npm install @headlessui/react

import { Listbox } from "@headlessui/react";
import { CheckIcon, ChevronUpDownIcon } from "@heroicons/react/20/solid";

const plans = ["Starter", "Pro", "Enterprise"];

export function PlanSelect() {
  const [selected, setSelected] = useState(plans[0]);

  return (
    <Listbox value={selected} onChange={setSelected}>
      <div className="relative">
        <Listbox.Button className="relative w-full cursor-pointer rounded-lg bg-white py-2 pl-3 pr-10 text-left shadow-md focus:outline-none focus-visible:ring-2 focus-visible:ring-sky-500">
          <span className="block truncate">{selected}</span>
          <span className="pointer-events-none absolute inset-y-0 right-0 flex items-center pr-2">
            <ChevronUpDownIcon className="h-5 w-5 text-gray-400" />
          </span>
        </Listbox.Button>
        <Listbox.Options className="absolute z-10 mt-1 w-full rounded-md bg-white shadow-lg">
          {plans.map((plan) => (
            <Listbox.Option key={plan} value={plan}
              className={({ active }) =>
                `relative cursor-pointer select-none py-2 pl-10 pr-4 ${active ? "bg-sky-100" : "text-gray-900"}`
              }
            >
              {({ selected }) => (
                <>
                  {selected && (
                    <span className="absolute inset-y-0 left-0 flex items-center pl-3">
                      <CheckIcon className="h-5 w-5" />
                    </span>
                  )}
                  {plan}
                </>
              )}
            </Listbox.Option>
          ))}
        </Listbox.Options>
      </div>
    </Listbox>
  );
}

Best for: Teams with a custom design system who want the behavior layer handled correctly without any visual opinions.

6. Magic UI — Animation-First Components

Magic UI ships components specifically designed for marketing pages: animated gradients, number counters, particle effects, spotlight hover effects, and more. It uses shadcn/ui as the base and adds animation layers.

npx shadcn@latest add "https://magicui.design/r/animated-gradient-text"

import AnimatedGradientText from "@/components/ui/animated-gradient-text";

export function HeroSection() {
  return (
    <div className="flex flex-col items-center gap-4 py-20">
      <AnimatedGradientText>
        <span className="text-4xl font-bold">
          Build faster with Magic UI
        </span>
      </AnimatedGradientText>
      <p className="text-xl text-muted-foreground max-w-2xl text-center">
        Animated components for modern landing pages
      </p>
    </div>
  );
}

Best for: Landing pages, marketing sites, anywhere you want visual wow without writing Framer Motion from scratch.

7. Aceternity UI — 3D and Glassmorphism

Aceternity UI focuses on the high-end visual effects: 3D card tilt, wavy text, glowing borders, glassmorphism panels. It's built on top of Framer Motion and shadcn/ui.

npx shadcn@latest add "https://ui.aceternity.com/registry/3d-card-effect.json"

import { CardBody, CardContainer, CardItem } from "@/components/ui/3d-card";

export function ProductCard({ name, price }: { name: string; price: number }) {
  return (
    <CardContainer className="inter-var">
      <CardBody className="relative bg-gray-50 dark:bg-black rounded-xl p-6 w-auto sm:w-[30rem] h-auto">
        <CardItem translateZ="50" className="text-xl font-bold">
          {name}
        </CardItem>
        <CardItem translateZ="60" className="text-neutral-500 text-sm mt-2">
          Starting at ${price}/month
        </CardItem>
        <CardItem translateZ="100" className="w-full mt-4">
          <button className="w-full bg-black dark:bg-white text-white dark:text-black rounded-xl py-2">
            Get Started
          </button>
        </CardItem>
      </CardBody>
    </CardContainer>
  );
}

Best for: Premium landing pages, portfolio sites, product showcases where visual richness is the goal.

8. Flowbite React — Complete Component Set

Flowbite takes a different approach: it ships 60+ pre-built UI blocks (navbars, footers, forms, tables) as ready-to-use React components with Tailwind classes. Less flexible than shadcn/ui but much faster to assemble common page patterns.

npm install flowbite-react

import { Table, Button, TextInput, Label } from "flowbite-react";

export function UsersTable({ users }: { users: User[] }) {
  return (
    <div className="overflow-x-auto">
      <Table hoverable>
        <Table.Head>
          <Table.HeadCell>Name</Table.HeadCell>
          <Table.HeadCell>Email</Table.HeadCell>
          <Table.HeadCell>Plan</Table.HeadCell>
          <Table.HeadCell><span className="sr-only">Actions</span></Table.HeadCell>
        </Table.Head>
        <Table.Body className="divide-y">
          {users.map((user) => (
            <Table.Row key={user.id}>
              <Table.Cell className="font-medium">{user.name}</Table.Cell>
              <Table.Cell>{user.email}</Table.Cell>
              <Table.Cell>{user.plan}</Table.Cell>
              <Table.Cell>
                <Button size="xs" color="light">Edit</Button>
              </Table.Cell>
            </Table.Row>
          ))}
        </Table.Body>
      </Table>
    </div>
  );
}

Best for: Admin panels, internal tools, teams that want a full set of pre-styled components without design decisions.

9. Preline UI — Free Tailwind Components

Preline ships a large library of static Tailwind components (no package install required) that you copy directly into your project. Over 300 UI blocks including navbars, pricing sections, and hero layouts.

// No package install — just copy the classes
export function PricingCard() {
  return (
    <div className="flex flex-col border border-gray-200 rounded-2xl p-8 dark:border-neutral-700">
      <div className="flex items-center gap-x-4 mb-6">
        <h3 className="text-lg font-semibold text-gray-800 dark:text-neutral-200">Pro</h3>
        <span className="inline-flex items-center gap-1.5 py-1.5 px-3 rounded-full text-xs font-medium bg-blue-100 text-blue-800">
          Popular
        </span>
      </div>
      <p className="mt-2">
        <span className="text-4xl font-bold text-gray-800 dark:text-neutral-200">$29</span>
        <span className="text-sm font-medium text-gray-500">/month</span>
      </p>
    </div>
  );
}

Best for: Teams that want component inspiration with the option to take full ownership with zero library dependency.

10. Tailwind UI — Paid, Professional-Grade

Tailwind UI is the official premium component library from the Tailwind Labs team. One-time payment ($149 personal / $299 team) for 500+ components and templates.

Worth it when: you want professionally designed components that are guaranteed to work with the latest Tailwind CSS version, built by the people who wrote the CSS framework. The quality is genuinely higher than free alternatives.

Which One to Pick

Project type	Library
Next.js SaaS	shadcn/ui
Quick prototype	daisyUI
Dashboard with charts	Tremor
Marketing landing page	Magic UI or Aceternity UI
Custom design system	Headless UI
Admin panel	Flowbite React
Pro budget available	Tailwind UI

Tailwind CSS v4 changed how configuration works — if you're migrating, the Tailwind v4 migration guide covers what breaks and how to fix it.

For the full comparison of React component libraries beyond just Tailwind-specific ones, see Top React Component Libraries.

Originally published at stacknotice.com