Cloudflare Workers પર સ્ટેટિક Next.js સાઇટ
આ સાઇટ નાના Worker દ્વારા પીરસાતું સંપૂર્ણ સ્ટેટિક Next.js એક્સપોર્ટ કેમ છે: ઝડપી પાનાં, લગભગ શૂન્ય ખર્ચ, સર્વર પર એડમિન રક્ષણ અને સુરક્ષા હેડર.
3 મિનિટ વાંચનGryffin Forge
આ સાઇટ Next.js અને Reactથી બનેલી છે, પણ ક્યાંય કોઈ Node.js સર્વર ચાલતું નથી. દરેક જાહેર પાનું બિલ્ડ વખતે સ્ટેટિક HTML તરીકે બને છે અને Cloudflareના edge પરથી પીરસાય છે. એક નાનું Worker એ થોડાં કામો સંભાળે છે જેને ખરેખર સર્વર જોઈએ. કેમ, અને ભાગો કેવી રીતે જોડાય છે.
પહેલાં સ્ટેટિક
પોર્ટફોલિયો અને નમૂનાની સાઇટ પર લગભગ બધું સ્થિર સામગ્રી છે: નમૂનાનાં વર્ણન, લેખો, કેસ સ્ટડી, ટૂલ પાનાં. આમાંનું કંઈ મુલાકાતી મુજબ બદલાતું નથી, તેથી દરેક વિનંતી પર બનાવવું કોઈ ફાયદા વગર વિલંબ અને ખર્ચ ઉમેરત.
output: "export" સાથે Next.js દરેક રૂટ — generateStaticParamsથી ગણાયેલા /demos/[slug] જેવા ગતિશીલ રૂટ સહિત — સાદી HTML ફાઇલો તરીકે બનાવે છે. પરિણામ:
- ઝડપી પહેલું દર્શન — HTML પૂરું આવે છે, સર્વર રેન્ડર સમય વગર.
- ઓછામાં ઓછું JavaScript — સર્વર કમ્પોનન્ટ ક્લાયન્ટને કોડ મોકલતાં નથી; માત્ર ઇન્ટરેક્ટિવ ભાગો જાગે છે (ફિલ્ટર, કેલ્ક્યુલેટર, નમૂના વ્યૂઅર).
- લગભગ શૂન્ય ખર્ચ — Cloudflare પર સ્ટેટિક ફાઇલો કેશમાંથી પીરસાય છે.
- સરળ નિષ્ફળતાઓ — પડી શકે એવું કોઈ એપ સર્વર નથી.
સર્વર હજી ક્યાં જોઈએ
ત્રણ વસ્તુઓ સ્ટેટિક ન હોઈ શકે:
- એડમિન વિભાગ કોઈ પણ સામગ્રી મોકલાય તે પહેલાં સુરક્ષિત હોવો જોઈએ.
- આંકડા અને ભૂલ અહેવાલોને મેળવવા માટે એન્ડપોઇન્ટ જોઈએ.
- વ્યાપારી કાર્યો સર્વર પર નકારવાં જોઈએ, માત્ર છુપાવવાં નહીં.
એક Worker સ્ટેટિક ફાઇલોની આગળ માત્ર /admin અને /api/* માટે ઊભું છે. તે એડમિન રૂટ માટે સહી કરેલી સેશન કૂકી ચકાસે છે, લોગિન પ્રયાસો મર્યાદિત કરે છે, કૂકીઝ કે IP સરનામાં વગર Durable Objectમાં પાના-દર્શન ગણે છે, અને સર્વર પર સ્પષ્ટ ફ્લેગ ન હોય ત્યાં સુધી દરેક વ્યાપારી એન્ડપોઇન્ટને 403થી જવાબ આપે છે. બાકીની દરેક વિનંતી સીધી સ્ટેટિક ફાઇલોમાં જાય છે.
મુસદ્દા ક્યારેય ઓનલાઇન જતા નથી
સામગ્રીની એક સ્થિતિ હોય છે: મુસદ્દો, પ્રીવ્યૂ, પ્રકાશિત કે આર્કાઇવ. બિલ્ડ માત્ર પ્રકાશિત અને પ્રીવ્યૂનાં પાનાં બનાવે છે; પ્રીવ્યૂ noindex સાથે છે અને યાદીઓ તથા સાઇટમેપમાં નથી. મુસદ્દા ક્યારેય ફાઇલો બનતા નથી, તેથી લીક થવા જેવું કંઈ નથી.
એક ફાઇલમાં સુરક્ષા હેડર
Workers પર સ્ટેટિક ફાઇલો _headers ફાઇલને સમર્થન આપે છે, તેથી સુરક્ષા હેડર એક જ વાર જાહેર થાય છે: કડક સામગ્રી સુરક્ષા નીતિ જે ફ્રેમમાં માત્ર નમૂના રેન્ડરરના મૂળને મંજૂરી આપે છે, X-Content-Type-Options, સાવચેત રેફરર નીતિ અને પરવાનગી નીતિ જે સાઇટ ન વાપરે તે સેન્સર બંધ કરે છે.
સાચા 404
સ્ટેટિક ફાઇલોની ગોઠવણ અજાણ્યા માર્ગો માટે બનેલું 404.html અસલ 404 કોડ સાથે પીરસે છે, તેથી સર્ચ એન્જિન soft-404 પાનાં ઇન્ડેક્સ કરતાં નથી.
સમાધાન
- દરેક વિનંતી માટે વ્યક્તિગતકરણ નહીં. ગતિશીલ બધું બ્રાઉઝર કે Workerમાં ચાલવું જોઈએ.
- પ્રકાશન માટે ફરી બિલ્ડ. સામગ્રીના ફેરફારો માટે બિલ્ડ અને ડિપ્લોય જોઈએ. અઠવાડિયે થોડી વાર બદલાતી સાઇટ માટે એ ફાયદો છે: દરેક ફેરફાર ચકાસાય છે અને સંસ્કરણબદ્ધ થાય છે.
- અંદર બનેલું છબી ઓપ્ટિમાઇઝેશન નહીં. સ્ક્રીનશૉટ બનાવતી વખતે WebPમાં ફેરવાય છે અને નિશ્ચિત કદમાં પીરસાય છે.
પ્રદર્શન સાઇટ માટે આ સમાધાન સંપૂર્ણ યોગ્ય છે: પરિણામ ઝડપી, સસ્તું, શરૂઆતથી સુરક્ષિત અને સમજવામાં સરળ છે.