DotFusion
Intelligent Integration
Wróć do bloga
DevelopmentOpublikowano 30 maja 2026· 1 min czytania

Next.js App Router w produkcji — 6 miesięcy doświadczeń

Migrowaliśmy trzy projekty klientów z Pages Router na App Router. Oto co nas zaskoczyło, co poszło lepiej niż oczekiwaliśmy i czego żałujemy.

App Router jest teraz domyślny w Next.js i powoli przestaje być "nowym". Po sześciu miesiącach produkcyjnych wdrożeń mamy wyrobione zdanie.

Next.js App Router w produkcji — 6 miesięcy doświadczeń

# Co działa świetnie

**Server Components** to największa zmiana mentalna i największa nagroda. Komponenty które nie potrzebują stanu klienta renderują się na serwerze — mniej JS w bundle, szybszy FCP, prostszy data fetching bez useEffect.

**Layouts i nested routing** — nareszcie. Zagnieżdżone layouty które nie re-renderują całej strony przy nawigacji. Prosta rzecz, ogromna różnica w UX.

**Streaming i Suspense** — ładowanie sekcji strony niezależnie od siebie. Wolne API nie blokuje szybkich elementów.

# Co nas zaskoczyło (negatywnie)

**Caching jest mylący.** Cztery niezależne mechanizmy cachowania (Request Memoization, Data Cache, Full Route Cache, Router Cache) z różnymi sposobami invalidacji. Spędziliśmy za dużo czasu debugując dlaczego dane są stale.

**"use client" granica.** Gdy masz komponent biblioteki zewnętrznej który nie ma "use client", a używa hooków — debugging jest frustrujący. Ekosystem nadrabia ale jeszcze nie jest idealny.

# Rekomendacja

Dla nowych projektów — App Router bez wątpienia. Dla migracji istniejących projektów — oceń ile komponentów korzysta z patterns które są trudne do migracji (getServerSideProps, getStaticProps, custom _app.js). Duże projekty warto migrować inkrementalnie.

Wróć do blogaZacznij projekt →