Edge Functions as
Your Backend
The "backend" is everything behind the scenes — processing payments, checking logins, saving data. Edge functions let you handle all of it without managing a server or hiring an engineering team.
A traditional server is a full-time salaried cook standing in the kitchen 24/7, whether there are orders or not. An edge function is a line cook who clocks in when there is an order, cooks the dish, clocks out. At 3am when nobody is ordering, you are not paying anyone.
What Happens Behind the Scenes
When someone taps "Subscribe" in your app, a lot happens they never see. Verify the user is logged in. Create a checkout session with your payment processor. Wait for confirmation. Update the database with their new plan. Grant access to premium features. Send a confirmation email. All in about two seconds.
All of that invisible work is your backend. In a traditional company, a whole engineering team builds and maintains this. As a solo builder, edge functions are how you handle it — without a server, without DevOps, without a team.
Everything that happens behind the scenes. Processing payments, checking passwords, reading and writing data, talking to external APIs. The kitchen where the food gets made — as opposed to the dining room where customers eat.
A small piece of backend logic that runs in the cloud only when triggered. Sleeps when nobody calls it. Wakes up, does its job, goes back to sleep. You pay for usage, not uptime. "Edge" means it runs close to the user geographically — fast response times worldwide.
What an Edge Function Actually Looks Like
It is just a file that receives a request and returns a response. That is it.
An edge function is a single file. It receives an incoming request (someone tapped a button, a webhook fired, a scheduled job triggered). It does something with that request (check the database, call an API, calculate a value). It returns a response (success with data, or an error with a message). The cloud provider handles everything else — the server, the scaling, the uptime.
// This function does ONE thing: return a user's profile
export default async function handler(request) {
// Step 1: Who is asking?
const authToken = request.headers.get('Authorization');
const user = await verifyToken(authToken);
// Step 2: Are they allowed?
if (!user) {
return new Response('Unauthorized', { status: 401 });
}
// Step 3: Get what they asked for
const profile = await database
.from('users')
.select('name, email, plan_tier, created_at')
.eq('id', user.id);
// Step 4: Send it back
return new Response(JSON.stringify(profile), {
status: 200,
headers: { 'Content-Type': 'application/json' }
});
}That is the entire function. Four steps: authenticate, authorize, fetch, respond. Every edge function you will ever write follows some variation of this pattern. The complexity is never in the structure — it is in the details of what happens between "receive request" and "send response."
You do not need to memorize syntax. You need to understand the flow: request comes in → verify who is asking → do the thing → send back the result. When you ask AI to write a function, describe the flow in those terms and it will generate the code correctly.
One Function Per Job — The Split Architecture
Each function owns one area completely. When one breaks, the others keep running.
auth-handler
Login, signup, token refresh, password reset, account deletion. Nothing else. This is the most security-critical function in your app. It touches credentials, tokens, and sessions. Keeping it isolated means a bug in payments can never accidentally expose auth data.
core-handler
Your product's primary functionality. For a fitness app: workout logging, program retrieval, progress tracking. For a booking app: availability checks, reservation creation, calendar sync. The reason your product exists — isolated so a payment bug never breaks the core experience.
payment-handler
Checkout sessions, subscription management, plan upgrades and downgrades. Talks to Stripe, Apple IAP, or whatever payment processor you use. Money functions live alone — when you are debugging payment logic at 2am, you do not want to accidentally break login.
webhook-receiver
Incoming events from external services — payment confirmations from Stripe, delivery notifications, scheduled job triggers. Receives, never sends. External services push data here. Your function validates, processes, and stores it. This is where silent failures happen most — more on that in Chapter 17.
Start Split or Start Together?
This is the single most impactful architectural decision for a solo builder.
Path A: One Big Function (Monolith)
All your backend logic in one file. Simple to start — one file, one deployment, one thing to think about. Works great for months. But at ~500 lines, it becomes a nightmare to debug. A bug in the payment section breaks authentication. A change to the user profile query accidentally affects the subscription check. Splitting mid-flight is painful — you are refactoring while users are using the product.
Path B: Split From Day One
Separate files for separate jobs. More files, more deployments. Feels like overkill when your entire backend is 200 lines. But when one function breaks, the others keep running. When you need to debug the payment webhook at 2am, you are reading 80 lines of focused payment logic — not searching through 600 lines of everything. You never do a painful mid-flight split.
Webhooks — When the Outside World Talks to You
Your app calls APIs. Webhooks are APIs calling you back.
When a user pays through Stripe, your app does not sit there waiting for the payment to process. Instead, Stripe sends a webhook — an automatic HTTP request to your server — when the payment succeeds, fails, or gets refunded. Your webhook receiver catches these events and updates your database accordingly.
Webhooks are how the outside world notifies you of events you care about. Payment processors send them when charges succeed. Shipping providers send them when packages deliver. Calendar services send them when events change. Your job is to build a function that receives these notifications and acts on them.
// Step 1: Verify the webhook is real (not a fake request)
const signature = request.headers.get('stripe-signature');
const event = verifyWebhookSignature(body, signature, secret);
// Step 2: What happened?
if (event.type === 'checkout.session.completed') {
// Someone just paid! Activate their subscription.
const session = event.data.object;
await database.from('subscriptions').update({
status: 'active',
plan_tier: session.metadata.plan,
}).eq('user_id', session.metadata.user_id);
}
if (event.type === 'invoice.payment_failed') {
// Payment failed — notify the team, flag the account
await sendAlert('payment-failed', session.customer_email);
}
// Step 3: Always return 200 so the sender knows you received it
return new Response('ok', { status: 200 });Your webhook should return 200 (success) only after the database update completes. If you return 200 before the update and the update fails, the payment processor thinks everything is handled — but the user never gets access. This is the most common webhook bug. Always: process first, respond second.
Error Handling — The Part AI Skips
AI writes the happy path. You need to demand the sad paths.
When you ask AI to write an edge function, it will write the version where everything goes right. The user is logged in. The database responds. The external API returns data. The payment succeeds. This is called the "happy path" and it is maybe 50% of what your function needs to handle.
The other 50% is what happens when things go wrong. What if the user is not logged in? What if the database is temporarily unreachable? What if the external API returns an error? What if the payment processor is down? What if the request body is malformed? What if someone sends a request without the required fields?
Every function you write — or ask AI to write — needs a try/catch wrapper around the main logic. This is the safety net that catches unexpected errors and returns a useful error message instead of a cryptic crash.
export default async function handler(request) {
try {
// All your logic goes inside the try block
const user = await verifyAuth(request);
if (!user) return errorResponse(401, 'Not authenticated');
const data = await doTheThing(user.id);
return successResponse(data);
} catch (error) {
// If ANYTHING unexpected happens, you land here
console.error('Function failed:', error.message);
await sendAlertToDiscord('function-name', error.message);
return errorResponse(500, 'Something went wrong');
}
}When you ask AI to write a function, always include this in your prompt: "Wrap the entire function in a try/catch. Handle missing auth, invalid input, and database failures. Send errors to a monitoring channel. Return user-friendly error messages, never stack traces." This one prompt addition prevents 80% of production issues.
Secrets and Environment Variables
Your function needs API keys. Those keys must never appear in your code.
Your edge functions talk to external services — payment processors, databases, AI APIs, email services. Each of these requires an API key or secret. These keys are like the password to your bank account. If someone gets your Stripe secret key, they can issue refunds, view customer data, and create charges.
Never put API keys directly in your code. Instead, store them as environment variables — values that exist in your hosting environment but never appear in your source code. Your code reads them at runtime: const stripeKey = process.env.STRIPE_SECRET_KEY. If someone reads your code, they see the variable name but never the actual key.
Every hosting platform (Vercel, Netlify, AWS, your database provider) has a dashboard where you set environment variables. The process is: create the variable in the dashboard, give it a name and value, and reference the name in your code. The platform injects the value at runtime.
Maintain separate environment variables for staging and production. Your staging functions should use test API keys. Your production functions should use live API keys. Mixing them up — test keys in production or live keys in staging — causes real problems. Stripe test keys process fake payments. Stripe live keys charge real credit cards. You do not want to learn this distinction by accidentally charging a test user $29.99 for real.
The Deployment Workflow
Write → test in staging → verify → deploy to production. Never skip steps.
Write & Test Locally
Write the function. Test it against your staging database with test data. Verify the happy path works. Verify the error paths work. Check that it handles missing fields, bad auth, and unexpected input.
Deploy to Staging
Deploy the function to your staging environment. Hit it with real HTTP requests using a tool like Postman or curl. Check the logs. Verify the database was updated correctly. Run through the user flow in your staging app.
Verify Before Production
Before deploying to production: check that all environment variables are set for production (not staging). Verify the function points to the production database. Confirm the correct API keys are in place. This checklist takes 60 seconds and prevents the most common deployment disasters.
Deploy & Monitor
Deploy to production. Watch the logs for the first 15 minutes. Check your monitoring channel (Chapter 14) for any alerts. Have the previous version ready to rollback if something goes wrong. A deployment is not done until you have verified it works with real traffic.
The most dangerous deployment is the one where you skip verification because "it is a small change." Small changes cause big outages when they hit an edge case you did not test.
Common Edge Function Patterns
These five patterns cover 90% of what you will build.
| Pattern | Triggered By | What It Does | Example |
|---|---|---|---|
| CRUD Handler | User action (button tap) | Create, read, update, or delete data in your database | Save a new workout, fetch user profile, delete an old draft |
| Webhook Receiver | External service | Process incoming event notifications | Stripe payment confirmed, shipping status updated |
| API Proxy | User action | Call an external API on behalf of the user (hiding your API keys) | Generate AI response, fetch weather data, translate text |
| Scheduled Job | Cron schedule | Run automatically at set intervals | Daily digest email, expired subscription cleanup, usage reports |
| Auth Middleware | Every request | Verify the user is who they say they are before proceeding | Check JWT token, validate session, enforce permissions |
Security Basics for Edge Functions
Validate every input. Never trust data from the client. If your function expects a user ID, verify it is a valid format before querying the database. If it expects a number, confirm it is actually a number. Malicious users send garbage data to see what breaks.
Verify webhook signatures. When Stripe sends a webhook, it includes a cryptographic signature. Verify that signature before processing the event. Without verification, anyone can send a fake "payment succeeded" event to your webhook URL and get free access.
Rate limit sensitive endpoints. Login attempts, password resets, and API-heavy endpoints need rate limiting — a maximum number of requests per time window. Without it, an attacker can try thousands of passwords per minute or burn through your API credits with automated requests.
Never return internal errors to users. When something breaks, return a generic "Something went wrong" message. Log the real error internally. Detailed error messages reveal your tech stack, database structure, and potential vulnerabilities to anyone watching.
Use HTTPS for everything. Every edge function platform provides HTTPS by default. Never disable it. Never create HTTP-only endpoints. Authentication tokens sent over HTTP are visible to anyone on the network.
Debugging Edge Functions
When something breaks, logs are your only witness.
Edge functions run in the cloud. You cannot set a breakpoint and step through the code like a desktop application. Your debugging tools are: logs, error messages, and monitoring alerts.
Log generously during development. At the start of every function, log what came in: console.log('Request received:', request.method, request.url). Before every database call, log what you are about to query. After every external API call, log the response status. When debugging, these logs tell the story of what happened.
Log strategically in production. Remove the verbose development logs before deploying. Keep: errors, warnings, and business-critical events (payments, signups, subscription changes). Too many logs in production create noise that hides real problems. Too few logs leave you guessing when things break.
Test with real-shaped data. The most common edge function bugs come from data that is shaped differently than expected. A field that is sometimes null. A number that arrives as a string. An array that is empty instead of missing. Test with messy data, not just perfect data.
What Changes at Scale
Edge functions scale automatically — that is the point. But "automatically scales" does not mean "handles everything gracefully." Here is what to watch for as your user count grows.
Cold starts. When a function has not been called in a while, the first request takes longer (200-500ms extra) because the cloud has to spin up a new instance. This matters for latency-sensitive operations like real-time features. If cold starts become a problem, some platforms offer "always warm" options at extra cost.
Database connection limits. Each function invocation opens a database connection. At 100 concurrent users, that is 100 connections. Most database plans cap connections at 50-200. Use connection pooling — a shared pool of connections that functions draw from instead of each creating their own. Most database providers offer this as a feature you enable.
Execution time limits. Most platforms limit function execution to 10-30 seconds. If your function does heavy processing — generating reports, processing images, bulk data operations — it might hit this limit. Break long operations into smaller chunks or use a background job queue.
Cost at scale. Edge functions are cheap at low volume but costs add up. A function that costs $0.0001 per invocation is free at 1,000 calls/month ($0.10). At 1,000,000 calls/month it is $100. Track your invocation counts and know your per-function costs. The monitoring setup in Chapter 14 includes alerts for API credit balances — this applies to your function hosting costs too.
For every piece of important data, decide: which system is the boss? Payment status → your payment processor is the boss. User profiles → your database is the boss. AI configurations → your AI provider is the boss. When two systems disagree, the boss wins. Every other system follows.