The backend is everything behind the scenes. Edge functions let you handle all of it without a server or an engineering team.
Edge functions are pieces of code that run on a server you don't manage. You write the logic, deploy it, and it sits there waiting for requests. No server maintenance, no scaling configuration, no uptime monitoring. The platform handles all of that.
RESTAURANT: Edge functions are your kitchen stations. Each station handles one category of work — grill station, sauté station, pastry station. When an order comes in, it goes to the right station. The station handles it and sends back the plate. You don't need one chef who does everything. You need specialized stations that each do their job well.
DEF: Edge function — A small piece of server-side code that runs on demand. "Edge" means it runs close to the user geographically. "Function" means it does one thing and returns a result. You don't maintain the server. You just write the logic.
The mistake most solo founders make is putting all their backend logic in one function. One massive file that handles authentication, payments, conversations, drilling, and webhooks. That works until it doesn't — and when it breaks, everything breaks at once.
The better approach: split handlers. Each handler owns one domain:
auth-handler — Login, signup, token refresh, account management. Nothing else.
conversation-handler — Eligibility checks, session pre-registration, conversation memory. Nothing else.
dashboard-handler — User stats, progress data, activity history. Nothing else.
drilling-handler — Practice questions, scoring, spaced repetition. Nothing else.
webhook-receiver — Incoming webhooks from Stripe, ElevenLabs, and other services. Nothing else.
Each handler has both a production and a sandbox variant. The sandbox version has -sandbox appended to its name. They share the same database but use different API keys.
NOTE: Never put authentication logic and payment logic in the same function. When your auth function deploys with a bug, you don't want it to also break payments. Isolation is insurance.
Inside each handler, requests include an action field that routes to the right logic. The handler itself is a router — it reads the action, calls the right internal function, and returns the result.
This means adding a new capability to your backend is: write a new internal function, add a case to the router, deploy. No new endpoints, no new infrastructure, no configuration changes.
Every edge function should return a consistent response shape. Success or failure, the structure is the same. Your frontend code doesn't need to guess what format the response will be in.
Log errors with enough context to debug them later: the action that was attempted, the user ID, and the error message. Don't log sensitive data like passwords or full API keys. Do log enough to reproduce the problem.
If your edge functions are public-facing, add rate limiting. Without it, a single bad actor — or a bug in your own frontend — can hammer your functions and run up your API costs. Simple approaches include: per-user request limits (tracked via the auth token), per-IP limits for unauthenticated endpoints, and cooldown periods between expensive operations like AI calls.