What is Serverless Functions?

What is a Serverless Function?

A serverless function is a stateless, event-driven unit of backend code that executes on demand without requiring you to provision or manage servers. The cloud provider (AWS Lambda, Vercel Functions, Cloudflare Workers, Google Cloud Functions) handles scaling, patching, and infrastructure automatically. AWS Lambda launched the model in November 2014, and by 2026 every major cloud and frontend platform supports some flavor of it. Functions typically respond to HTTP requests, queue messages, or scheduled cron triggers. Cold start latency — the delay when a function hasn't been invoked recently — ranges from ~50ms on Cloudflare Workers to 200-800ms on AWS Lambda with Node.js 20, depending on bundle size and runtime. We use serverless functions on virtually every Next.js project we ship, most commonly for API routes that handle form submissions, webhook ingestion, or third-party API proxying.

How it works

When a request hits a serverless function endpoint, the platform spins up an execution environment (if one isn't already warm), loads your handler code, runs it, and returns the response. The lifecycle looks like this:

1. Trigger — An HTTP request, a message on a queue, or a cron schedule fires.
2. Cold start (if needed) — The runtime initializes. The platform loads your function bundle, boots the runtime (Node.js, Python, Go, etc.), and runs any top-level initialization code.
3. Execution — Your handler function runs. It has access to the event payload and a context object with metadata like remaining execution time.
4. Response — The function returns a result. For HTTP triggers, this is a status code, headers, and body.
5. Freeze or teardown — The execution environment is either kept warm for subsequent invocations or destroyed after an idle timeout.

In Next.js App Router (v14+), any route.ts file inside app/api/ becomes a serverless function on Vercel by default:

// app/api/contact/route.ts
import { NextResponse } from 'next/server';

export async function POST(request: Request) {
  const body = await request.json();
  // validate, store, send email, etc.
  return NextResponse.json({ ok: true }, { status: 200 });
}

Each function is isolated — it doesn't share memory or filesystem state with other invocations. If you need shared state, you reach for an external store: a database, Redis, or KV namespace.

When to use it

Serverless functions are a strong default for most backend work in a Jamstack or Next.js architecture. We've shipped them on 50+ projects and here's our mental model:

Use serverless functions when:

• You need API endpoints for form handling, auth callbacks, or webhook receivers
• Traffic is spiky or unpredictable — you don't want to pay for idle servers
• You want zero-ops infrastructure with automatic scaling
• You're building a prototype or MVP and speed-to-deploy matters

Skip serverless functions when:

• You have long-running tasks (>30s on Vercel, >15min on Lambda) — use a queue + worker instead
• You need persistent WebSocket connections — use a dedicated server or Durable Objects
• Cold start latency is unacceptable for your use case — consider edge runtime or a long-running container
• You have heavy CPU/memory workloads like video transcoding — a dedicated compute instance is cheaper at scale

Serverless Functions vs alternatives

Our preferred stack at Social Animal is Next.js API routes deployed as serverless functions on Vercel for standard backend work, with Cloudflare Workers (edge runtime) for latency-critical middleware like geo-redirects or A/B test assignment.

Real-world example

On a recent e-commerce project, we needed to validate discount codes against a Shopify Storefront API before checkout. We built a single serverless function at /api/validate-discount in Next.js 15. It receives a POST with the code, calls Shopify's GraphQL endpoint, and returns validity + discount percentage. On Vercel's Pro plan (us-east-1), p50 response time was 120ms and p99 was 310ms. The function handles 0 to 12,000 invocations per hour during flash sales without any scaling configuration. Monthly cost: under $3 on Vercel's included usage tier. Before this, the client ran a $40/month Express server on Railway that sat idle 22 hours a day.