Full-Stack Architectures with Vercel
Common architectures
| Architecture | Frontend | Backend and data |
|---|---|---|
| All-in-one Next.js | Vercel | route handlers + hosted Postgres/Redis |
| Frontend + Python API | Vercel | Flask/FastAPI on Render, Railway or Fly.io |
| Static marketing site | Vercel | forms to an API route or third-party form service |
| Headless CMS site | Vercel | content from a CMS, revalidated on publish webhooks |
Connecting a separate API
- Call the API from server code where possible, so tokens stay on the server.
- For browser calls, configure CORS on the API for your exact domains (production and the preview URL pattern), and use cookies with
SameSiteandSecureset appropriately, or short-lived tokens. - Keep the API URL in an environment variable per environment, so previews talk to a staging API.
Choosing regions
Place functions in the same region as your database to avoid slow cross-region round trips; the edge network still serves cached pages globally.
Launch checklist
- [ ] Custom domain, HTTPS, canonical redirect
- [ ] Secrets only in server-side variables, separate per environment
- [ ] Security headers configured
- [ ] Forms and APIs validated and rate-limited
- [ ] Database connections pooled; functions in the database's region
- [ ] Previews protected and on test data
- [ ] Error tracking and Web Vitals monitoring
- [ ] Rollback procedure known
Final project
Launch a production site for a small business: Next.js on Vercel with a custom domain, server-rendered service pages, a contact form posting to a route handler with validation and rate limiting, content revalidation, protected previews for client review, and a Flask API on Render for bookings called from server components. Document the architecture and the rollback steps.
Check yourself
- Why call APIs from server code when possible?
- How should CORS be configured for previews?
- Why match function region to database region?
Seu progresso fica salvo apenas neste navegador.
Enviar para revisão (10 pontos)