Next.js to mój domyślny wybór dla produktów webowych — nie dlatego, że jest modny. Jedna baza kodu TypeScript obejmuje to, co kiedyś wymagało trzech projektów: stronę marketingową, która ma dobrze wypadać w wyszukiwarce, aplikację za logowaniem i cienką warstwę API pomiędzy nimi. Ta strona jest małym przykładem: zlokalizowane trasy, generowane metadane, sitemap, obrazy Open Graph i trasa llms.txt — wszystko w jednym projekcie App Router.
Zaczynam od serwera. Strony i layouty są domyślnie Server Components: pobierają dane blisko bazy, wysyłają HTML zamiast pakietu JavaScript i przechowują sekrety po stronie serwera. „use client” umieszczam tylko na liściach drzewa, które potrzebują stanu, efektów lub API przeglądarki — w formularzu, menu rozwijanym czy mapie. Gdy całe drzewo zaczyna się od „use client”, zwykle pojawia się ciężki pakiet i cała klasa błędów.
Wybór trybu renderowania to decyzja produktowa, nie techniczna. Generowanie statyczne sprawdza się na stronach zmienianych przy wdrożeniu. ISR lub rewalidacja po tagach pasują do katalogów, ogłoszeń i blogów aktualizowanych w ciągu dnia: revalidateTag po zapisie, zamiast niezrozumiałego dla wszystkich timera. Renderowanie dynamiczne ze streamingiem Suspense stosuję w panelach i treściach osobistych: szkielet jest widoczny od razu, a wolniejsze dane dochodzą później. Przy każdej trasie zapisuję, dlaczego jest statyczna lub dynamiczna — ten jeden wiersz oszczędza tydzień pytań „czemu cena jest nieaktualna?”.
Do mutacji używam Server Actions w formularzach należących do strony, a Route Handlers wtedy, gdy aplikację ma wywołać coś z zewnątrz: webhook dostawcy płatności lub Telegrama, klient mobilny, zadanie cron. W obu przypadkach Zod waliduje dane wejściowe na serwerze, tam też sprawdzam uwierzytelnienie; klient nigdy nie rozstrzyga kwestii pieniędzy ani uprawnień. W większych produktach Next.js pozostaje frontendem i BFF, a główna logika domenowa działa w usłudze NestJS lub Node.js z własną bazą danych.
Wydajność i SEO należą do definicji ukończenia. Używam next/image z rzeczywistymi wymiarami, next/font, by uniknąć przesunięć układu, generateMetadata i danych strukturalnych na każdej publicznej stronie, dynamicznych importów ciężkich widgetów oraz sprawdzam Core Web Vitals na telefonie ze średniej półki, a nie na MacBooku. Wdrażam na Vercel, gdy zespół chce uniknąć obsługi infrastruktury, albo jako build standalone w Dockerze na AWS lub VPS, gdy liczą się koszt, lokalizacja danych lub długie zadania.
Nie akceptuję „use client” w głównym layoucie, pobierania tych samych danych w pięciu komponentach bez pomysłu na cache, ukrywania logiki biznesowej w middleware ani aktualizacji głównej wersji w piątek bez przeczytania codemodów. Jeśli aplikacja Next.js działa wolno lub jest krucha, wyślij mi repozytorium i dwie najwolniejsze strony. Powiem, co przeniósłbym na serwer, co zapisał w cache i co usunął.
Daj kolejnemu produktowi kogoś, kto zostanie.
Chcesz zacząć? Napisz do mnie — mogę rozpocząć od razu i zostać na dłużej. Długoterminowa współpraca, nie przekazanie projektu po dwóch tygodniach. Omówmy projekt, wymagania i najlepszy sposób realizacji.