I thought Vercel's backend was just like another backend…

Lesson learned about Vercel vs. Traditional Backend On my journey to learn Next.js in-depth through projects, i tried to architect my Next.js backend server like normal golang’s backend (dependency injection). Turns out its not possible. I treat Vercel’s /api routes like a “mini Express server.” This is a fundamental architectural error. While both run Node.js, their underlying infrastructure (Serverless vs. Long-Running) dictates completely different rules. Then i dig further to understand why service model like Vercel are different from backend in common… Other services that work similar are Netlify, Cloudflare Pages / Workers, AWS Amplify. 1. Process Lifecycle: Ephemeral vs. Persistent Traditional Backend (Long-Running) The Concept: The process starts and stays alive until you manually stop it or it crashes. The “Global Root” is permanent. Memory is allocated once and remains available across thousands of different requests. Implication: You can rely on the server “remembering” things in its internal RAM for days or weeks. Vercel (Serverless) The Concept: The process is Ephemeral. It is “born” when a request arrives and “executed” (terminated or frozen) the millisecond the response is sent. The “Global Root” is destroyed frequently. Implication: Any internal state is wiped. You must treat every request as if the server just performed a “Cold Start.” 2. State Management: The Global Variable Trap Traditional Backend (Long-Running) Memory: Global variables are Shared. If User A updates a global counter, User B sees the updated value because they are hitting the same process. Garbage Collection: As long as the process lives, GC…

Continue reading →