Un site Next.js static pe Cloudflare Workers

Acest site e făcut cu Next.js și React, dar nicăieri nu rulează un server Node.js. Fiecare pagină publică e generată ca HTML static la build și servită de la marginea rețelei Cloudflare. Un Worker mic se ocupă de puținele lucruri care chiar au nevoie de server. Iată de ce și cum se leagă piesele.

#Întâi static

Aproape tot ce e pe un site de portofoliu și demo-uri e conținut stabil: descrieri de demo-uri, articole, studii de caz, pagini de instrumente. Nimic din ele nu se schimbă de la un vizitator la altul, deci generarea la fiecare cerere ar adăuga întârziere și cost fără beneficiu.

Cu output: "export", Next.js generează fiecare rută — inclusiv cele dinamice ca /demos/[slug], enumerate cu generateStaticParams — ca fișiere HTML simple. Rezultatul:

• Afișare inițială rapidă — HTML-ul vine complet, fără timp de randare pe server.
• JavaScript minim — componentele de server nu trimit cod clientului; se activează doar piesele interactive (filtre, calculatoare, vizualizatorul de demo).
• Cost aproape zero — fișierele statice de pe Cloudflare se servesc din cache.
• Defecțiuni simple — nu există server de aplicație care să cadă.

#Unde mai e nevoie de server

Trei lucruri nu pot fi statice:

1. Zona de administrare trebuie protejată înainte să se trimită vreun conținut.
2. Statisticile și rapoartele de erori au nevoie de un endpoint care să le primească.
3. Funcțiile comerciale trebuie refuzate pe server, nu doar ascunse.

Un Worker stă în fața fișierelor statice doar pentru /admin și /api/*. Verifică un cookie de sesiune semnat pentru rutele de administrare, limitează încercările de autentificare, înregistrează numărul de vizualizări într-un Durable Object fără cookie-uri sau adrese IP și răspunde 403 la orice endpoint comercial dacă nu e setat explicit un flag pe server. Orice altă cerere merge direct la fișierele statice.

#Ciornele nu ajung niciodată online

Conținutul are un status: ciornă, previzualizare, publicat sau arhivat. Build-ul generează pagini doar pentru publicate și previzualizări; previzualizările au noindex și lipsesc din liste și din harta site-ului. Ciornele nu devin niciodată fișiere, deci nu are ce să se scurgă.

#Antete de securitate dintr-un fișier

Fișierele statice pe Workers suportă un fișier _headers, așa că antetele de securitate se declară o singură dată: o politică strictă de securitate a conținutului care permite în cadre doar originea randatorului de demo-uri, X-Content-Type-Options, o politică de referrer prudentă și o politică de permisiuni care dezactivează senzorii pe care site-ul nu-i folosește.

#404 corecte

Configurarea fișierelor statice servește 404.html generat cu un cod real 404 pentru căile necunoscute, așa că motoarele de căutare nu indexează pagini soft-404.

#Compromisuri

• Fără personalizare per cerere. Orice e dinamic trebuie să ruleze în browser sau în Worker.
• Publicarea cere rebuild. Schimbările de conținut cer build și implementare. Pentru un site care se schimbă de câteva ori pe săptămână e un avantaj: fiecare schimbare e verificată și versionată.
• Fără optimizare de imagini inclusă. Capturile de ecran sunt convertite în WebP la creare și servite la mărimi fixe.

Pentru un site de prezentare, compromisurile merită din plin: rezultatul e rapid, ieftin, sigur din start și ușor de înțeles.