Kodėl viską statome su Next.js ir edge runtime

Esame išbandę daug stackų. Po to, kai sukūrėme daugiau nei 40 produkcinių svetainių ir aplikacijų, susitelkėme ties Next.js, diegiamu į edge infrastruktūrą, kaip mūsų numatytąjį pasirinkimą. Štai logika, įskaitant ir kompromisus.

Kodėl Next.js

Next.js suteikia galimybę pasirinkti tinkamą atvaizdavimo strategiją kiekvienam maršrutui — statinis generavimas, serverio atvaizdavimas ar kliento atvaizdavimas — nekeičiant frameworko.

Marketinginei svetainei dauguma puslapių yra statiniai. Tinklaraštis generuojamas statiškai. Kontaktų formos endpoint’as renderinamas serveryje. Interaktyvi demonstracija renderinama kliento pusėje. Vienas frameworkas tvarko visa tai.

App Router (pristatytas v13 versijoje, brandus nuo v15) atneša React Server Components, o tai reiškia, kad galite imti duomenis serveryje ir į klientą siųsti nulį JavaScript komponentams, kuriems nereikia interaktyvumo. Turiniu apkrautas puslapis, anksčiau atsiunčiantis 200 KB JS, dabar atsiunčia 15 KB.

Kodėl edge

Tradiciniai serveriai veikia viename regione. Vartotojas Singapūre, kreipiantis į serverį us-east-1 regione, prie kiekvienos užklausos prideda 200–300 ms tinklo latencijos dar prieš tai, kai serveris ką nors apdoroja.

Edge runtime’ai — Vercel Edge Functions, Cloudflare Workers — paleidžia Jūsų kodą daugiau nei 30 vietų visame pasaulyje. Serveris visada yra arti vartotojo. TTFB nuosekliai išlieka po 50 ms visame pasaulyje.

Kompromisas: edge runtime’ai turi apribojimų. Nėra prieigos prie failų sistemos, riboti Node.js API, mažesnės atminties ribos. Tai priverčia laikytis architektūrinės disciplinos — funkcijos be būsenos, duomenys imami iš API arba edge-cache’inamų duomenų bazių.

Visas stackas

• Framework: Next.js (App Router)
• Stiliai: Tailwind CSS v4
• Duomenų bazė: Postgres ant Neon (serverless, edge-suderinama) arba Supabase
• Autentifikacija: Clerk arba next-auth, priklausomai nuo sudėtingumo
• El. paštas: Resend
• Mokėjimai: Stripe
• CMS: MDX failai repozitorijoje turiniu apkrautoms svetainėms; Sanity, kai turinį turi redaguoti klientas
• Diegimas: Vercel

Ko nenaudojame

Nenaudojame kliento atvaizdavimo puslapiams, kuriems jis nereikalingas. Nenaudojame REST API ten, kur paprasčiau pasitarnauja server action arba RSC duomenų paėmimas. Nepridedame backend frameworko, kai Next.js route handler’iai padaro užduotį.

Sudėtingumas susikaupia. Kiekviena papildoma paslauga — dar vienas dalykas, kuris gali sugesti, dar vienas autentifikacijos sluoksnis, dar vienas diegimo konvejeris. Teisingas stackas yra paprasčiausias, kuris dengia reikalavimus.

Kompromisai, apie kuriuos verta žinoti

Edge runtime ne visada tinka. Jeigu Jūsų aplikacijai reikia ilgai veikiančių užklausų, didelės atminties arba prieigos prie failų sistemos, Node.js serveris vis dar yra tinkamas pasirinkimas. Mums tokie atvejai yra išimtis, ne taisyklė.

Server Components irgi turi mokymosi kreivę. Komandos, įpratusios prie kliento puses pasaulio, pirmiausia susiduria su keistais hidratacijos klausimais. Tai atsiperka, bet nesitikėkite, kad pirma savaitė bus sklandi.

Statykite pagal turimus reikalavimus. Pridėkite sudėtingumo tik tada, kai išaugote iš paprastesnio sprendimo. Tai vienintelė taisyklė, kurios laikomės nesvyruodami.