Statyczny Next.js na Cloudflare Workers

Ta strona jest zbudowana w Next.js i React, ale nigdzie nie działa serwer Node.js. Każda publiczna strona jest generowana do statycznego HTML podczas budowania i serwowana z brzegu sieci Cloudflare. Mały Worker zajmuje się tymi kilkoma rzeczami, które naprawdę wymagają serwera. Oto dlaczego i jak to się łączy.

#Najpierw statycznie

Prawie wszystko na stronie portfolio i demo to stabilne treści: opisy demo, artykuły, case studies, strony narzędzi. Nic z tego nie zmienia się dla każdego gościa, więc renderowanie przy każdym zapytaniu dodawałoby opóźnienie i koszt bez korzyści.

Z output: "export" Next.js renderuje każdą trasę — także dynamiczne, jak /demos/[slug], wyliczane przez generateStaticParams — do zwykłych plików HTML. Efekt:

• Szybkie pierwsze wyświetlenie — HTML przychodzi kompletny, bez czasu renderowania na serwerze.
• Minimum JavaScriptu — komponenty serwerowe nie wysyłają kodu klienta; ożywają tylko elementy interaktywne (filtry, kalkulatory, przeglądarka demo).
• Niemal zerowy koszt — pliki statyczne na Cloudflare są serwowane z cache.
• Proste awarie — nie ma serwera aplikacji, który mógłby paść.

#Gdzie serwer nadal jest potrzebny

Trzy rzeczy nie mogą być statyczne:

1. Panel administracyjny musi być chroniony zanim zostanie wysłana jakakolwiek treść.
2. Statystyki i raporty błędów potrzebują punktu odbioru.
3. Funkcje komercyjne muszą być odrzucane po stronie serwera, a nie tylko ukryte.

Worker stoi przed plikami statycznymi tylko dla /admin i /api/*. Sprawdza podpisane ciasteczko sesji na trasach panelu, ogranicza próby logowania, zapisuje liczbę wyświetleń w Durable Object bez ciasteczek i adresów IP i zwraca 403 dla każdego endpointu komercyjnego, chyba że ustawiono jawną flagę po stronie serwera. Każde inne zapytanie trafia prosto do plików statycznych.

#Szkice nigdy nie trafiają do sieci

Treści mają status: szkic, podgląd, opublikowane lub zarchiwizowane. Budowanie generuje strony tylko dla opublikowanych i podglądów; podglądy mają noindex i są pominięte w listach i mapie strony. Szkice w ogóle nie stają się plikami, więc nie ma czego wyciec.

#Nagłówki bezpieczeństwa z pliku

Pliki statyczne na Workers obsługują plik _headers, więc nagłówki bezpieczeństwa deklaruje się raz: ścisła polityka bezpieczeństwa treści, która w ramkach dopuszcza tylko źródło renderera demo, X-Content-Type-Options, ostrożna polityka referera i polityka uprawnień wyłączająca czujniki, których strona nigdy nie używa.

#Prawdziwe 404

Konfiguracja plików statycznych serwuje wygenerowany 404.html z prawdziwym kodem 404 dla nieznanych ścieżek, więc wyszukiwarki nie indeksują stron soft-404.

#Kompromisy

• Brak personalizacji na zapytanie. Wszystko dynamiczne musi działać w przeglądarce lub w Workerze.
• Publikacja wymaga przebudowy. Zmiana treści to build i wdrożenie. Dla strony zmienianej kilka razy w tygodniu to zaleta: każda zmiana jest przeglądana i wersjonowana.
• Brak wbudowanej optymalizacji obrazów. Zrzuty ekranu są konwertowane do WebP przy tworzeniu i serwowane w stałych rozmiarach.

Dla strony pokazowej te kompromisy łatwo się opłacają: wynik jest szybki, tani, domyślnie bezpieczny i prosty do zrozumienia.