Dlaczego wszystko budujemy na Next.js i na edge

Wypróbowaliśmy wiele stacków. Po zbudowaniu ponad 40 produkcyjnych witryn i aplikacji wybór domyślnie pada na Next.js wdrożone na edge. Poniżej logika tego wyboru wraz z uczciwie nazwanymi kompromisami.

Dlaczego Next.js

Next.js pozwala dobrać odpowiednią strategię renderowania dla każdej trasy z osobna — generowanie statyczne, renderowanie po stronie serwera albo renderowanie po stronie klienta — bez przesiadania się na inny framework.

Dla strony marketingowej większość podstron jest statyczna. Blog jest generowany statycznie. Endpoint formularza kontaktowego renderuje się po stronie serwera. Interaktywne demo renderuje się po stronie klienta. Jeden framework obsługuje wszystkie te scenariusze równolegle.

App Router (wprowadzony w v13, dojrzały od v15) wnosi React Server Components, co oznacza, że można pobierać dane na serwerze i wysyłać zerową liczbę bajtów JavaScriptu do klienta dla komponentów, które nie wymagają interaktywności. Strona z dużą ilością treści, która wcześniej wysyłała 200 KB JS, teraz wysyła 15 KB.

Dlaczego edge

Tradycyjne serwery pracują w jednym regionie. Użytkownik z Singapuru pukający do serwera w us-east-1 dokłada 200–300 ms opóźnienia sieciowego do każdego żądania, jeszcze zanim serwer cokolwiek policzy.

Runtime’y edge — Vercel Edge Functions, Cloudflare Workers — uruchamiają kod w 30+ lokalizacjach globalnie. Serwer jest zawsze blisko użytkownika. TTFB konsekwentnie poniżej 50 ms na całym świecie.

Kompromis: runtime’y edge są ograniczone. Brak dostępu do systemu plików, ograniczone API Node.js, niższe limity pamięci. To wymusza dyscyplinę architektoniczną — funkcje bezstanowe, dane pobierane z API lub baz danych cache’owanych na edge.

Pełny stack

• Framework: Next.js (App Router).
• Stylowanie: Tailwind CSS v4.
• Baza danych: Postgres na Neon (serverless, kompatybilny z edge) lub Supabase.
• Autoryzacja: Clerk albo next-auth, zależnie od poziomu złożoności.
• E-mail: Resend.
• Płatności: Stripe.
• CMS: pliki MDX w repozytorium dla serwisów contentowych; Sanity dla treści edytowalnych po stronie klienta.
• Wdrożenie: Vercel.

Czego nie używamy

Nie używamy renderowania po stronie klienta dla podstron, które tego nie wymagają. Nie używamy REST API tam, gdzie wystarczy server action albo pobranie danych w RSC. Nie dorzucamy frameworka backendowego, gdy route handlery Next.js wystarczają w zupełności.

Złożoność procentuje. Każdy dodatkowy serwis to kolejna rzecz, która może paść, kolejna warstwa autoryzacji, kolejny pipeline wdrożeniowy. Właściwy stack to najprostszy stack, który obsługuje wymagania biznesu.

Buduj pod wymagania, które masz dziś. Złożoność dokładaj dopiero wtedy, gdy faktycznie wyrośnie się z prostszego rozwiązania.