avg server response ms
Measured40-800 ms (warm-cold range)
Case Study
Updated: 2025-03-23YC Directory
A full‑stack Next.js application (App Router) that serves a small pitch-directory product where users can browse, search, submit, and view startup pitches. The UI is rendered primarily with Next.js Server Components and hydrated Client Com...
Scope: full stackFull-stack EngineerDuration: 1 monthsYear: 2025Architecture: platform
Repository Links:
Measured Performance & Outcomes
Empirical Resultsestimated throughput rps
Measured50-200 rps (depends on hosting and Sanity quotas)
error rate
Measured<1% (expected under normal load)
Architecture View
Processing state: architecture signal graph is initializing...
Architectural Decision Log
Trade-Off AnalysisUse Next.js App Router with Server Components
Simplifies data fetching (server-only clients) and reduces client bundle size; server actions allow safe server‑side writes without building separate REST endpoints.
Trade-off: Tight coupling to Next.js App Router and canary features (future breaking changes possible); reduces portability to non-Next runtimes.
Use Sanity as headless CMS and store authors in CMS
Fast iteration for editorial UX and built-in content APIs; NextStudio simplified embedding.
Trade-off: External dependency and rate limits; dependence on Sanity write token for mutations (server-only secret) introduces single point of failure if token is missing.
Server-only write client with token validation
Protects write operations to server-only contexts and avoids accidental client writes.
Trade-off: Build or startup fails early if env is missing; requires secure secret management in deployment.
Architecture Narrative
Challenge
Provides a lightweight platform to publish short startup pitches, discover and browse pitches by category or search, and increment content views while retaining an editorial experience via an embedded Sanity Studio.
Solution
Monolithic server-side rendered web application (single Next.js application) augmented by a headless CMS (Sanity) and external services (GitHub OAuth, Sentry). The app uses Server Components + Client Components and Server Actions (Next.js App Router patterns).
Result
Key measurable signals: avg_server_response_ms (40-800 ms (warm-cold range)), estimated_throughput_rps (50-200 rps (depends on hosting and Sanity quotas)), error_rate (<1% (expected under normal load)).
Trade-off Matrix
| Dimension | Selected Option | Impact | Compromise |
|---|---|---|---|
| Rendering model | Server Components + SSR with Server Actions | Small client bundles, secure server-side mutation paths, consistent SEO-friendly HTML | Dependent on Next.js App Router canary features; more complex debugging and ties to Vercel/serverless model |
| Content storage | Sanity (SaaS headless CMS) | Fast editorial iteration, built-in Studio and live preview, GROQ queries | External service dependency, rate limits, cost per write; write token must be protected and managed carefully |
Failure Modes & Resilience Analysis
Degradation ProtocolFailure Path & Recovery Invariants
Missing SANITY_WRITE_TOKEN => write-client.ts throws at startup (see explicit guard). This prevents writes and may fail builds or server startup. Malformed remote image URLs or unreachable HEAD checks (validation.ts) => form submission validation fails; user...
What I'd Do Differently & Evolution
+
Sanitize markdown and restrict allowed HTML/SVG: Replace raw markdown-it -> markdown-it + strict sanitizer (DOMPurify or sanitize-html) and remove dangerouslyAllowSVG: true unless strictly required.
+
Add resilient write patterns: implement idempotency keys for form submissions, add retry with exponential backoff for write operations, and change view counting to buffered/aggregate updates to avoid per-render writes.