"स्टैटिक वेबसाइट" का सिद्धांत बनाम व्यवहार
(utcc.utoronto.ca)- स्टैटिक·डायनेमिक वेबसाइटों के बीच का अंतर धुंधला हो गया है, इस राय के विपरीत, लंबे ऑपरेशन टाइमस्केल पर स्टैटिक फ़ाइल-आधारित वेबसाइटें अब भी अलग प्रकृति रखती हैं
- वेब की शुरुआत से चला आ रहा फ़ाइल डिप्लॉयमेंट तरीका और स्टैटिक फ़ाइल सर्विंग की दक्षता, स्टैटिक साइटों के लंबे समय तक टिके रहने की एक वजह है
- स्टैटिक वेबसाइटों में वेब सर्वर और कंटेंट के बीच फ़ाइलसिस्टम जैसी ज़िम्मेदारियों की स्पष्ट सीमा होती है, इसलिए दोनों पक्षों को एक-दूसरे के बारे में बहुत सीमित बातें जाननी पड़ती हैं
- डायनेमिक वेबसाइटों में वेब सर्वर और यूज़र कोड के बीच की सीमा छोटी और सरल बनाना मुश्किल होता है, और उस सीमा व API को एक साथ मानकीकृत करना भी कठिन है
- भेद का आधार काम की मात्रा या बदलाव की आवृत्ति नहीं, बल्कि यह है कि सीमा कहाँ है और हर पक्ष को किन बातों का ध्यान रखना पड़ता है
स्टैटिक वेबसाइट बहस की शुरुआत
- Wesley Aptekar-Cassels की There is no such thing as a static website यह मानती है कि स्टैटिक वेबसाइट और डायनेमिक वेबसाइट के बीच का अंतर सोच से कम है
- स्टैटिक वेबसाइटें दिखने से अधिक डायनेमिक और जटिल हैं
- डायनेमिक वेबसाइट बनाना और चलाना पहले से आसान हो गया है
- अलग-अलग तर्क प्रभावशाली ढंग से रखे गए हैं, लेकिन वे इस निष्कर्ष तक नहीं पहुँचते कि स्टैटिक और डायनेमिक वेबसाइटों का अंतर कम हो गया है
टिकाऊपन और ज़िम्मेदारी की सीमाएँ जो अंतर बनाती हैं
- लंबे समय के पैमाने पर स्टैटिक फ़ाइल-आधारित वेब कंटेंट ने उच्च टिकाऊपन दिखाया है
- भले ही ठोस वेब सर्वर और होस्ट बदल जाएँ, स्टैटिक फ़ाइलों और डायरेक्टरी ट्री में फ़ाइलें रखने का तरीका वेब की शुरुआत से चला आ रहा है
- स्टैटिक फ़ाइल सर्विंग डायनेमिक वेबसाइटों में भी आम तौर पर ज़रूरी और कुशल होती है, इसलिए सिर्फ़ स्टैटिक फ़ाइलों वाली साइटें भी इसी लाभ का उपयोग करती हैं
- अगर केवल स्टैटिक कंटेंट दिया जाए, तो साइट को लगातार चलाते रहना आसान और स्थिर होता है; ऐतिहासिक रूप से यह बात डायनेमिक वेबसाइटों पर लागू नहीं हुई है
- स्टैटिक वेबसाइट की मूल बात है ज़िम्मेदारियों की ऐसी सीमा जिसमें सरल और मज़बूत आइसोलेशन हो
- एक तरफ़ HTTPS certificate renewal जैसे डायनेमिक अपडेट्स तक शामिल करने वाली स्टैटिक वेब सर्वर की जटिलता होती है
- दूसरी तरफ़ स्टैटिक फ़ाइलें होती हैं, और इनके बीच फ़ाइलसिस्टम या फ़ाइलसिस्टम जैसी कोई चीज़ होती है
- दोनों पक्ष एक-दूसरे से बहुत सीमित अपेक्षाएँ रखते हैं
- डायनेमिक वेबसाइटों में वेब सर्वर और यूज़र कोड के बीच ऐसी छोटी और स्पष्ट सीमा रखना मुश्किल है
- इसे किसी एक सीमा और API से मानकीकृत कर पाने की संभावना भी कम है
- एक अर्थ में वेब को स्टैटिक फ़ाइलें सर्व करने के लिए डिज़ाइन किया गया था
- यही अंतर स्टैटिक फ़ाइल वेब सर्वर को डायनेमिक वेब सर्वर और execution environment की तुलना में संचालन और माइग्रेशन के लिहाज़ से अधिक फायदेमंद बनाता है
- स्टैटिक फ़ाइल वेब सर्वर आसानी से मिल जाते हैं
- अगर मौजूदा ऑपरेटर सेवा बंद भी कर दे, तब भी साइट को कहीं और ले जाना आसान होता है
- यह टिकाऊपन कम-से-कम उन मध्यम और छोटे आकार की स्टैटिक वेबसाइटों पर लागू होता है जो एक single server में समा सकती हैं
- स्टैटिक वेबसाइट और डायनेमिक वेबसाइट का भेद धुंधला नहीं है
- साइट बनाने और चलाने में लगने वाले काम की मात्रा, या HTTPS certificate renewal जैसे नियमित रूप से बदलने वाले तत्वों की मात्रा, इसका आधार नहीं है
- आधार यह है कि सीमा कहाँ है, और हर पक्ष को किन बातों की चिंता करनी है
- स्टैटिक वेबसाइटों में एक तेज़ और स्पष्ट सीमा होती है जिससे दोनों पक्षों को स्वतंत्र रूप से संभाला जा सकता है, जबकि डायनेमिक वेबसाइटों में ऐसी सीमा मूल रूप से नहीं होती, इसलिए ज़रूरत पड़ने पर कृत्रिम रूप से रेखा खींचनी पड़ती है
1 टिप्पणियां
Hacker News की राय
मैं एक content website से अपनी आजीविका चलाता हूँ, और इस साल Craft CMS से एक खुद बनाए गए static site generator पर शिफ्ट किया
अब मुझे server या CMS की चिंता नहीं करनी पड़ती, updates की ज़रूरत नहीं है, और भारी database व जटिल caching configuration भी हट गए हैं। अब यह बस एक static file server है, इसलिए ज़्यादा stable है और maintenance लगभग नहीं के बराबर है
सबसे अच्छी बात यह है कि offline काम किया जा सकता है। सिर्फ text editor चाहिए, इसलिए छोटा Macbook 12" भी बहुत तेज़ महसूस होता है
version control भी बहुत उपयोगी है, क्योंकि इससे changes review या revert किए जा सकते हैं, और पूरे content पर regex से find/replace किया जा सकता है। text files संभालना आसान होता है
यह बदलाव कैसा लगा और यह क्यों अच्छी तरह काम करता है, मैंने यहाँ लिखा है: https://nicolasbouliane.com/projects/ursus
बस अच्छा होगा अगर यह तकनीक उन लोगों के लिए भी ज़्यादा सुलभ हो जाए जो दोबारा compile और deploy नहीं कर सकते। यह तेज़ और सस्ता website बनाने का तरीका है, लेकिन Hugo जैसे मौजूदा tools user से काफ़ी assumptions करते हैं, इसलिए entry barrier बनता है
लेख भी मज़ेदार लगा। migration में इस्तेमाल किए गए html-to-markdown का मूल version मैंने बनाया था, और यह देखकर अच्छा लगा कि वह अब भी उपयोगी है
यह तेज़ है, ज़रूरी जानकारी अच्छी तरह देती है, और इसमें कोई फालतू चीज़ नहीं है
निजी तौर पर, मुझे अच्छा लगेगा अगर इसमें पुराने और मौजूदा Berlin की पृष्ठभूमि पर आधारित TV series और films का एक section हो, और साथ में यह भी एक छोटा rating हो कि वे असली Berlin को कितना realistically दिखाते हैं
पूरी websites में से 95% से अधिक के लिए शायद इतना काफ़ी होता कि लोकप्रिय content का 70% RAM में cache हो और बाकी 30% ऐसे SSD से serve हो जो 10,000 IOPS random reads कर सके
अगर आप site design से लगातार छेड़छाड़ नहीं कर रहे हैं, तो site और HTML generation local device पर होना चाहिए, और full build 1 second से कम में हो जाना चाहिए
लेकिन GitHub, version control, और text editor-केंद्रित तरीका अब भी technologists और programmers की तरफ़ झुका हुआ है। कुछ hosted WordPress जैसा, या पुराने Dreamweaver/Frontpage दौर के करीब कुछ चाहिए
जब कुछ खास implement करना हो, तो details तक गहराई में जा सकना अच्छा लगता है। उदाहरण के लिए, अगर मैं Favorite Git Aliases पोस्ट edit करूँ, तो उसे
.bash_aliasesfile में बदला जा सकता है, GitLab पर push किया जा सकता है, और GitHub पर mirror भी किया जा सकता हैजिसे दिलचस्पी हो, वह https://jdsalaro.com देख सकता है। stack या कारणों के बारे में मैंने अभी विस्तार से नहीं लिखा, लेकिन धीरे-धीरे document करने का इरादा है
फिलहाल मैंने Sphinx के लिए Markdown और Myst cheatsheet (https://jdsalaro.com/cheatsheet/sphinx-myst-cheat-sheet/) और
environment.pickleload करने का तरीका (https://jdsalaro.com/howto/sphinx-load-environment-pickle/) लिख रखा हैइसका मतलब यह भी है कि बिजली जैसी resources कम लगती हैं, छोटा hardware काफ़ी होता है, और सबसे बढ़कर security बेहतर होती है। static websites पर हमला करना ज़्यादा मुश्किल होता है, और संभावित flaws भी website code की बजाय web server तक सीमित रहते हैं
मैं आम तौर पर Hugo इस्तेमाल करता हूँ; इसमें features बहुत हैं और यह काफी polished है। मैंने multilingual websites भी बनाई हैं
static website में Turbo Hotwired integrate करने पर भी विचार किया जा सकता है। इससे navigation responsiveness बढ़ सकती है और server व client दोनों तरफ़ का load कम हो सकता है
ज़रूरत हो तो Turbo को Mercure के साथ integrate करके real-time page streaming भी की जा सकती है
static sites और dynamic sites के बीच सबसे बड़ा फ़र्क security attack surface है
static site web server को सबसे बुरी स्थिति में बस गलत file serve करने के लिए उकसाया जा सकता है, और इसे इस तरह कम किया जा सकता है कि server पर शुरू से केवल वही files रखी जाएँ जिन्हें serve करना स्वीकार्य है
dynamic site को code execute करने के लिए उकसाया जा सकता है, accessible database से गलत data return कराया जा सकता है, और data modify भी कराया जा सकता है
WordPress compromise तो हमेशा होते रहते हैं, लेकिन Nginx compromise वैसे नहीं होते
तकनीकी रूप से ऐसी कोई website नहीं होती जो code execute न करती हो। web server से लेकर file system driver और operating system तक, सब कुछ code है
यह सही है कि static files attack surface घटाती हैं, लेकिन ज़रूरी है कि हम गहराई से समझें कि ऐसा क्यों है, और static sites की सुरक्षा-विशेषताओं वाले समझदार dynamic systems design करें
आखिरकार, मूल बात input और उस input को कैसे handle किया जाता है, यही है। आप चाहे जितना complex code चलाएँ, अगर कोई input ही नहीं लेते तो उस पर attack नहीं किया जा सकता। बेशक, input न हो तो कौन-सा page दिखाना है यह भी पता नहीं चलेगा, इसलिए static sites में भी input होता है। महत्वपूर्ण फ़र्क यहीं है
मैं मानता हूँ कि static sites का attack surface छोटा होता है, लेकिन मेरे हिसाब से बड़ा कारण यह है कि nginx की औसत WordPress plugin combination की तुलना में कहीं ज़्यादा समीक्षा होती है और उसका development pace भी धीमा होता है
अगर आप अपना static web server खुद बनाएँ, तो उसका पहला version default WordPress install की तुलना में attack के लिए ज़्यादा vulnerable होने की संभावना है
static site को सिद्धांत रूप से शायद बिल्कुल updates की ज़रूरत ही न पड़े। जब तक HTML version जैसी target चीज़ें नहीं बदलतीं, update जैसी अवधारणा लगभग होती ही नहीं
aliasdirective वालेlocationblock के आखिर में slash लगाना भूल जाएँ, तो वह अपवाद हैडेवलपर के नज़रिए से, वेब जो abstraction देता है — यानी HTTP/S के ऊपर दी जाने वाली hypermedia — उसके आधार पर यह विभाजन काफ़ी साफ़ है
इस abstraction की semantics यह है कि किसी खास path पर headers और body के साथ request आती है, और headers व body के साथ response बाहर जाता है। TLS जैसी बीच की network details छिपी रहती हैं
वास्तव में, आधुनिक frameworks authentication sessions और request headers तक अपने-आप manage करते हुए डेवलपर से और भी ज़्यादा चीज़ें छिपा देते हैं। इस abstraction के भीतर “static request/state पर निर्भर नहीं होता, dynamic निर्भर होता है” वाला मानक विभाजन साफ़ दिखता है, लेकिन वह विभाजन abstraction द्वारा दी गई semantics पर टिका है
यह कुछ वैसा ही है जैसे TCP मूल रूप से packet-आधारित निचले ढांचे के ऊपर connection-oriented protocol की तरह काम करता है। TCP को उन applications में इस्तेमाल किया जा सकता है जिन्हें stream-type या packet-type data transfer चाहिए
यह कहा जा सकता है कि “असल में तो यह IP के ऊपर है, इसलिए कोई विभाजन नहीं है”, लेकिन वह abstraction की ग़लत layer से देखने जैसा है
इसका मतलब यह नहीं कि लेख का मुख्य तर्क ग़लत है। डेवलपर्स को “state-less website” के नीचे मौजूद statefulness को हमेशा ध्यान में रखना चाहिए, और जितना ज़रूरी लगता है उससे कुछ layers अधिक गहराई तक abstraction को समझना बेहतर है
व्यक्तिगत websites में static और dynamic अजीब तरह से मिले-जुले होते हैं। ज़्यादातर हिस्सा static है, लेकिन blog वाला भाग dynamic rendering है
blog URL पर पहुँचने पर disk से Markdown file लाई जाती है, उसे HTML में बदला जाता है, और फिर उस HTML को template में डालकर बाकी page और CSS आदि बनाए जाते हैं
फिर भी यह तेज़ और efficient है। पिछले हफ़्ते जब मेरी एक blog post HN पर #1 पर पहुँची, तो एक दोस्त ने message किया, “उम्मीद है Cloudflare configure किया होगा।” मैंने नहीं किया था, फिर भी 2-core 1GB memory VPS का load average 0.15 से ऊपर नहीं गया
यानी “ज़्यादातर HTML है, लेकिन इस file की इस line पर पहुँचने पर code चलाओ, किसी दूसरे format की file parse करो, और उसका result output में insert कर दो”
2001 में हर blog post के साथ comments section जैसी चीज़ जोड़ने वाली static website बनाना इसके लिए पूरी तरह उचित था। इस तरह का PHP इतना सस्ता पड़ता था कि आम ISP भी अक्सर इसे
/~userdir/में upload करके public internet पर expose करने की अनुमति दे देते थेअगर structure वाजिब हो और database पर बहुत ज़्यादा भारी निर्भरता न हो, तो एक छोटा VPS भी Hacker News से आने वाले traffic को आसानी से संभाल सकता है
अगर आप Threads जैसा कुछ launch कर रहे हैं, तो Facebook जैसी scaling की ज़रूरत पड़ेगी, लेकिन एक सामान्य read-only site के लिए ज़्यादा पैसे खर्च करने की बिल्कुल ज़रूरत नहीं है
dynamic content को template में डालना, या build time और complexity कम करना — ऐसे कारण दिमाग़ में आते हैं, लेकिन हो सकता है कोई और वजह भी हो जो मैं नहीं सोच पाया
wasm को थोड़ा-बहुत छूने वाले एक बाहरी व्यक्ति के नज़रिए से, यह समझ नहीं आता था कि सर्वर पर user code चलाकर “dynamic” web page बनाना एक साधारण file server से बेहतर क्यों है
dynamic हिस्से browser में चलें और server बस files serve करे, ऐसा ही काफी नहीं होना चाहिए? 90 के दशक के browser इस तरह के काम में बहुत खराब थे, यह अलग बात है
सादगी और scalability के मामले में CDN के सामने लगा साधारण file server से बेहतर कुछ नहीं
और यह भी अहम है कि कौन-सी technologies browser की बुनियादी सुविधाओं को खराब नहीं करतीं
वैसे, source code browse करते समय GitHub मेरे environment में आज भी लगभग 40% बार back button खराब कर देता है. मैं Chrome on OSX इस्तेमाल करता हूँ, और यह कैसे हो जाता है, समझ नहीं आता
मेरे अनुभव में, server side पर HTML generate करने वाली sites, client rendering पर निर्भर sites की तुलना में ज्यादा तेज़ और ज्यादा भरोसेमंद लगती हैं. Browser cache खाली होने पर, प्रति page 50 से ज़्यादा images वाले booru को खोलना भी, पहले से जगह-जगह cache हुई और कई दिनों से बदले नहीं गए सिर्फ text वाले GitHub page को खोलने से हमेशा तेज़ और ज्यादा सहज लगता है
उदाहरण के लिए, आप user-submitted content को database में store करना चाह सकते हैं, authentication की ज़रूरत हो सकती है, या कई GB के dataset पर full-text search देनी पड़ सकती है. Browser से जिन चीज़ों तक पहुँच नहीं है उनके लिए interface देना पड़ सकता है, या user input validate करना पड़ सकता है
इन सबके लिए server पर चलने वाला user code चाहिए. फिर server के data को एक अच्छी तरह परिभाषित transport protocol में बदलकर client तक भेजना होगा, वहाँ फिर बदलना होगा और HTML बनाना होगा
उल्टी दिशा में भी यही बात लागू होती है; अगर malicious custom clients को रोकना है, तो input validation client और server दोनों तरफ करनी होगी
या फिर server पर सीधे HTML बनाकर काम खत्म किया जा सकता है. काम बहुत कम पड़ता है, और ज़्यादातर applications में अनुभव भी लगभग वही मिलता है
अगर secret values हैं जिन्हें छिपाना ज़रूरी है, जैसे database password, API key, encryption key, तो उन्हें server पर मौजूद code ही संभाले. अगर सारा code client पर चले, तो attacker के उन secret values तक पहुँच जाने की संभावना हमेशा रहती है
client को छोटा और सीमित API देना attack surface कम करने के लिहाज़ से भी आसान होता है. अगर client को database से सीधे connect करने दिया जाए, तो permissions और security settings बिल्कुल सही होनी चाहिए और उनमें कोई गड़बड़ी नहीं होनी चाहिए; लेकिन अगर app सिर्फ अपनी किताबों या फ़िल्मों की सूची देता है, तो defense तोड़ना कहीं मुश्किल हो जाता है
कई बार initial load को तुरंत इस्तेमाल करने लायक data के एक chunk के रूप में देना site को ज्यादा responsive महसूस कराता है. चाहे application download करके loading indicator दिखाने, फिर data fetch कर उसे दिखाने वाले तरीके में कुल समय उतना ही लगे, user को पहला तरीका ज्यादा तेज़ लगता है
server आमतौर पर database और दूसरे ज़रूरी servers के पास होता है, इसलिए front end पर ज़रूरी चीज़ें लोड करने की बजाय वहीं से लाना तेज़ हो सकता है. ऐसे environment में network calls भी ज्यादा stable होते हैं. अगर सारा processing user side पर धकेल दिया जाए, तो ज्यादा धीमे और कम भरोसेमंद calls से निपटना पड़ता है
server, user के browser की तुलना में, आमतौर पर कहीं ज्यादा consistent platform होता है. Browser बेहतर हुए हैं, लेकिन अब भी उनमें कई सूक्ष्म अंतर हैं. Server पर ज़रूरी tools और runtime versions को ठीक-ठीक specify किया जा सकता है और updates भी ज्यादा deterministically किए जा सकते हैं
बेशक, यह हर बार पूरी तरह सही नहीं होता और exceptions भी हैं. मैं ज़्यादातर frontend applications पर काम करता हूँ, और उन अच्छे design वाले applications में भी बहुत value है जो ज़्यादातर या पूरा काम browser में करते हैं. बस आमतौर पर वे काफ़ी complex web apps होते हैं, या ऐसे मामले जहाँ वैसे भी browser में कुछ हद तक rendering चाहिए होती है
generation सिर्फ एक बार होती है और बहुत जल्दी खत्म हो जाती है. उसके बाद user के नज़रिए से static page के ढेरों फ़ायदे वैसे ही लागू रहते हैं
resource usage कई orders of magnitude कम होता है और page कहीं ज्यादा responsive होते हैं. User experience भी बहुत बेहतर होता है, बस पिछले 10 सालों में हमने उस पर खास ध्यान नहीं दिया
rsyncसे web server पर upload कर देता था. सारे page dynamically render होते थेउसका फ़ायदा यह था कि एक बार setup कर देने के बाद मुझे website की सचमुच दोबारा चिंता ही नहीं करनी पड़ती थी, और मैं बस अपनी पसंद का Markdown लिखता था
यह बहुत बढ़िया था. जब तक web hosting provider ने PHP हटाया नहीं था
इसी वजह से मुझे NextJS static page export बहुत पसंद है
build करके सिर्फ static
.html,.js,.cssको अपनी पसंद के CDN या static web server पर deploy कर देते हैं. अलग-अलग page और routes build के दौरान पहले से render हो जाते हैं, इसलिए initial load बहुत तेज़ होता है और search engine indexing भी हो जाती हैNextJS जिस तरह
.jscode को chunks में बाँटता है और pre-load करता है, वह भी तेज़ loading experience में योगदान देता है. अगर rich features चाहिए हों, तो अपनी पसंद की REST API से जोड़कर इसे जितना चाहें dynamic बनाया जा सकता हैMDX plugin इस्तेमाल करें तो उसी project के अंदर पूरी तरह static sections या content-centric sites भी आसानी से बनाई जा सकती हैं
लेकिन v13 app router आने के बाद ऐसा लगता है कि static export feature पर पर्याप्त ध्यान नहीं दिया जा रहा. Page router में जो features थे, जैसे shallow routing, static rewrites/redirects, वे static export से गायब हैं
static export इस्तेमाल करें तो commercial Vercel product की ज़रूरत ही नहीं पड़ती, इसलिए चिंता होती है कि कहीं लंबी अवधि में वे इस feature को पूरी तरह हटा न दें
ज़्यादातर मामलों में JavaScript की भी ज़रूरत नहीं होती, React, JSX, middleware, server-side rendering जैसी चीज़ों की तो बात ही छोड़िए
इतने सारे moving parts और npm dependencies वाली किसी चीज़ का लंबे समय तक maintenance करना कल्पना से बाहर लगता है. इसका मतलब यह नहीं कि इसका कोई उपयोग नहीं है, लेकिन सिर्फ एक landing page बनाने के लिए 1.8 GiB Git checkout और 828,128 lines of code वाले project में कूदने से पहले चीज़ों को सरल रखना चाहिए
Dan Abramov का उदाहरण देखिए: https://gist.github.com/gaearon/9d6b8eddc7f5e647a054d7b33343...
यह Vercel के business model की वजह से नहीं है, बल्कि इसलिए कि Next.js के usage ratio के हिसाब से यह use case कम आम है
“static rewrites” से आपका मतलब क्या है, यह मुझे ठीक से पता नहीं. क्या वह middleware से handle नहीं होता?
90 के दशक में किसी समय “static site generator” शब्द सुनने से पहले मैं m4 से अपनी साइट जनरेट करता था
उसके बाद PHP, Python पर गया, और अब Jekyll इस्तेमाल करके फिर से static पर लौट आया हूँ
जहाँ भी संभव हो, static तरीका कहीं बेहतर है। SSL certificate को छोड़ दें तो मैं सब कुछ अपनी समय-सारिणी के हिसाब से ठीक कर सकता हूँ
अगर PHP upgrade से कुछ टूट जाए, तो उसे तुरंत ठीक करना पड़ता है, और तब तक साइट बंद रह सकती है
static site में generator टूट भी जाए तो नतीजा बस यही होता है कि साइट static हालत में बनी रहती है। अगर नई पोस्ट डालनी नहीं है, तो कोई समस्या नहीं
सर्वर क्रैश हो जाए तो मैं किसी दोस्त से बस कुछ फ़ाइलें host करने के लिए कह सकता हूँ। यह पूछने की ज़रूरत नहीं पड़ती कि “तुम इसे PHP version X पर setting Y के साथ चला रहे हो न? postgres भी है न?”
कुछ दोस्त यह भी कह सकते हैं, “मैं अपने कंप्यूटर पर PHP install नहीं करना चाहता”
complexity के हिसाब से यह
sed "s/VERSION/1.2.3/g"से बस एक स्तर ऊपर लगता है। अगर सब कुछ external shell command से किया जा सकता है, तो Python जैसी चीज़ install करने की ज़रूरत नहीं पड़तीमैं कई सालों से ऐसे architecture pattern तलाश रहा हूँ जो static और dynamic दोनों के फायदे दे
यानी server-side dynamic code चला सके, लेकिन scaling cost बहुत कम हो और कुछ टूटने पर खुद recover भी कर ले
मैं इसे Baked Data pattern कहता हूँ: https://simonwillison.net/2021/Jul/28/baked-data/
इसका मूल विचार यह है कि साइट डेटा की पूरी read-only copy को application के साथ बंधे asset के रूप में deploy किया जाए
पूरी तरह static site की तरह इसमें भी हर बदलाव पर पूरी साइट फिर से deploy करनी पड़ती है, इसलिए लगातार update होने वाली साइटों के लिए यह उपयुक्त नहीं है
फायदा यह है कि इसे Vercel जैसी सस्ती dynamic scale-to-zero hosting पर deploy किया जा सकता है, app की कई copies चलाकर किसी भी traffic को संभाला जा सकता है, और app मर जाए तो host उसे अपने आप restart कर सकता है
मैंने ऐसे static site देखे हैं जिनमें server-side search या comment system था, जहाँ हर पोस्ट या comment अलग flat file के रूप में submit होता था और वहीं से static pages अपने आप फिर से generate हो जाते थे
शायद फ़र्क बस इतना है कि Markdown files की जगह sqlite में store किया जाता है और वहीं से build होता है। सामान्य backend/server-side features वाले static sites की तुलना में यही एकमात्र ध्यान देने लायक अंतर दिखता है
compiled binary executable में फ़ाइलों या images जैसी encoded binary resources को शामिल करना कोई दुर्लभ बात नहीं रही है। executable का size बढ़ जाता है, इसलिए आम तौर पर बहुत ज़्यादा नहीं जोड़ा जाता था
C या C++ का उदाहरण: https://github.com/graphitemaster/incbin
दिलचस्प बात यह है कि प्रोग्राम इस तरह बनाए जाते थे कि executable के अंदर का data बदले नहीं। compiled code मशीन पर चलता है, और security के नज़रिए से भी यह समझ में आता है
लेकिन अगर container, जैसे docker, के बारे में सोचें, तो चल रहा container packaged executable जैसा है, बस उसके पास file system भी होता है
अगर container में data डालें, तो यह executable में embedded resource जैसा ही विचार है, फर्क सिर्फ इतना है कि वह data बदल सकता है
हालाँकि container के अंदर runtime पर data बदल भी जाए, तो भी persistent storage लगाए बिना वह टिकता नहीं है
हाल में मैं यह सोच रहा था कि हमने अब तक “एक executable और उसके अंदर मौजूद volatile data space” जैसी single-file चीज़ क्यों नहीं बनाई। प्रोग्राम और database जैसा data एक ही file में जोड़ा जा सकता था
यह विचार “Baked Data” से थोड़ा जुड़ा हुआ है। executable में resource embed करने का मतलब आखिरकार encoded data को executable के अंदर रखना ही है
scripting languages में आप base64-encoded data को सीधे variable में रखकर script file बना सकते हैं
आख़िरी दो तरीके अपेक्षाकृत छोटे static data के लिए ही ठीक हैं, लेकिन अगर executable की इस सीमा को किसी तरह हटाने वाली तकनीक बन सके, तो वह दिलचस्प होगा
मैं अपने project pages भी इसी तरह host करता हूँ: https://usmanity.com/projects
हर बार जब मैं list में नया project जोड़ता हूँ या किसी मौजूदा entry की details बदलता हूँ, तो HTML files सीधे edit नहीं करना चाहता, इसलिए Notion इस्तेमाल करता हूँ और GitHub पर commit करने से पहले data को bake कर देता हूँ
इसे enable करने पर यह साइट के सारे pages को directory में HTML के रूप में bake कर देता था, और
.htaccessबदलकर सारा traffic उधर भेज देता था। content update होने पर सब कुछ फिर से bake होता थाhttps://www.drupal.org/project/boost
मुझे लगता है कि static site में अब भी सबसे बड़ी कमी यह है कि editing के लिए CMS को कहाँ host किया जाए
अगर मैं गलत हूँ तो सुधारें, लेकिन Decap CMS (पहले Netlify CMS) browser में चलता है और GitHub के ज़रिए read/edit करने के बाद rebuild और deploy trigger कर सकता है। लेकिन CORS की वजह से browser सीधे GitHub API से बात नहीं कर सकता, इसलिए लगता है कि अब भी एक छोटा server या proxy चाहिए
Netlify request को proxy करने वाला GitHub backend host कर देता है, लेकिन फिर आप Netlify और उसकी pricing policy में बदलावों से बंध जाते हैं
शायद GitLab और BitBucket में भी यही समस्या होगी: https://github.com/isomorphic-git/isomorphic-git#cors-suppor...
क्या इसे बहुत कम setup के साथ हल करने का कोई आसान तरीका है? Browser extension से CORS को चुनिंदा तौर पर ढीला किया जा सकता है, लेकिन यह आदर्श नहीं है
अगर Git-आधारित static site generator के साथ Markdown editing और live preview वाला CMS जुड़ा हो, browser में चले, और hosting/server की पाबंदियाँ कम हों, तो यह बहुत सी छोटी websites और blogs के लिए बढ़िया होगा
Static generator उस data को JSON feed जैसी किसी चीज़ से पढ़कर pages बना सकता है। उदाहरण के लिए, हर product record में HTML format में मुख्य description शामिल हो सकता है
तब कोई दूसरा व्यक्ति product information अपडेट करे तब भी website static ही रहेगी। मुझे लगा था Airtable इसके लिए ठीक होगा, लेकिन हैरानी की बात है कि यह HTML field को अच्छी तरह support नहीं करता
आप website को अपनी पसंद के तरीके से बनाइए, FTP से Surreal को जोड़िए, फिर users या clients को सिर्फ़ allowed हिस्से edit करने दीजिए
महीने के 12 डॉलर उस राहत के मुकाबले बहुत सस्ते हैं, और non-technical users को पूरा WYSIWYG editor दिया जा सकता है
[1] https://www.surrealcms.com
अभी यह extension laptop पर local install किए गए VS Code में चलता है, लेकिन GitHub Codespaces में नहीं चलता
अगर इसे GitHub Codespaces की free सीमा के भीतर, उचित usage time limit के साथ चलाया जा सके, तो यह विजेता हो सकता है। अपने computer पर development environment install किए बिना पूरी तरह online और version-controlled setup मिल जाएगा, static site को S3 जैसी जगह से serve किया जा सकेगा, और फिर भी पूरा CMS अनुभव मिलेगा
static sites की एक बहुत महत्वपूर्ण बात यह है कि इन्हें कहीं ज़्यादा आसानी से deploy करके भूल सकते हैं
S3 bucket site जैसी किसी जगह पर डाल दें तो लगभग चिंता ही नहीं करनी पड़ती
PHP या, उससे भी बुरा, self-hosted WordPress के साथ “deploy and forget” site बनाने पर अगर आप हर कुछ महीनों में जाँच न करें तो वह रूसी porn ads से भर सकती है
मैं कुछ static sites चला रहा हूँ, और यह जानना बहुत अच्छा लगता है कि वे हमेशा up रहती हैं और उन्हें ठीक करने की ज़रूरत नहीं पड़ती। दूसरी ओर, dynamic sites के लिए यह जाँचने वाले alerts चाहिए कि वे down तो नहीं हैं