मुझे आधुनिक वेब क्यों पसंद नहीं है

वेब के साथ काम करने में पहला कदम अपने सर्वर एप्लिकेशन को डेटा भेजना है। और अगर एक दर्जन छोटी लाइनों को पार्स करने से फ्रेमवर्क को सौंपा जा सकता है, तो फ़ाइलों को डाउनलोड करने के बारे में क्या?

आइए PHP को एक उदाहरण के रूप में लेते हैं, हालांकि वर्णित अन्य भाषाओं और प्रौद्योगिकियों के 99% के लिए सच है। मान लें कि हम उपयोगकर्ता को साइट पर चित्र अपलोड करने की अनुमति देना चाहते हैं, इसके लिए हम टाइप फ़ाइल के क्षेत्र के साथ एक फ़ॉर्म बनाते हैं और ... बाह्य रूप से, सब कुछ बहुत सरल है, बस फॉर्म में और कोड में कुछ बाइट्स बदल गए हैं, लेकिन अब आप प्रपत्रों से पाठ के बजाय फ़ाइलों के साथ काम कर सकते हैं! लेकिन सब कुछ इतना सरल नहीं है, आपकी फ़ाइल को पहले / tmp में कहीं व्यवस्थित होना चाहिए / जब तक कि अनुरोध पूरी तरह से नहीं आ जाता है, तब तक आपकी स्क्रिप्ट पर नियंत्रण नहीं होता है और आप इसके बारे में कुछ भी नहीं कर सकते हैं। उदाहरण के लिए, एक तस्वीर के बजाय, उपयोगकर्ता ने एक एक्स-फ़ाइल अपलोड की है, लेकिन आपको डाउनलोड के पूरा होने के बाद ही इसके बारे में पता चलेगा। इस प्रकार, एक हमलावर कुछ समय के लिए एक चैनल और आपके डिस्क सबसिस्टम के समय को नियंत्रित कर सकता है, उपयोगी फ़ाइलों को लोड करने का नाटक करता है, और आप इसके बारे में जानते भी नहीं हैं। यदि कैशिंग सर्वर एप्लिकेशन सर्वर के सामने होता है, तो स्थिति और भी खराब होती है: उदाहरण के लिए, nginx अस्थायी फ़ाइलें बनाता है, अर्थात। सबसे पहले, उपयोगकर्ता से अनुरोध डिस्क पर बस जाएगा, जैसे ही यह खत्म होता है, फ़ाइल को फिर से पढ़ा जाता है और जल्दी से आवेदन सर्वर (हमारे मामले में, php) को दिया जाता है, जहां इसे ONCE AGAIN को डिस्क पर सहेजा जाता है। डिस्क का कुल ट्रिपल उपयोग, भले ही उपयोगकर्ता को केवल संदेश प्रदर्शित करने की आवश्यकता हो "आप कैप्चा दर्ज करना भूल गए।"

मैं इस तथ्य के बारे में बात नहीं कर रहा हूं कि इस दृष्टिकोण के साथ अधिक मजेदार चीजें नहीं की जा सकती हैं। "फ़ाइल अपलोड प्रगति बार" जैसी एक सरल सुविधा अनुपलब्ध हो जाती है। अधिक जटिल उदाहरणों के लिए: Youtube ऐसी फिल्म से फ़्रेम दिखाता है जो अभी भी लोड हो रही है लेकिन पूरी तरह से लोड नहीं है। आपको कोई नियंत्रण नहीं मिला (और यहां तक ​​कि सूचनाएं भी!) पूरी फिल्म से पहले (2 गीगाबाइट, उदाहरण के लिए) डाउनलोड की गई है। आप यह भी नहीं जानते हैं कि किसी ने आपकी डिस्क के 1.5 गीगाबाइट खा लिए हैं, लेकिन फिर ब्राउज़र को बंद कर दिया या ब्राउज़र में ताज़ा बटन पर क्लिक किए बिना कुछ भी इंतजार किए।

बेशक, वक्रता की अलग-अलग डिग्री की विभिन्न बैसाखी होती हैं जो आपको विशिष्ट कार्यों को हल करने की अनुमति देती हैं, जैसे कि "डेटा के माध्यम से अनुरोध प्राप्त करना", वेब सर्वर के मॉड्यूल के रूप में लागू किया जाता है, लेकिन आपको ऐसी चीजें खुद करनी होगी और / या जिससे पर्यावरण से जुड़ी हो, आवेदन स्वतंत्र होना बंद हो जाता है और विशिष्ट अनुप्रयोगों और उनके पुस्तकालयों पर निर्भर हो जाता है।

Kesh

कैश महत्वपूर्ण हैं। कैशिंग तकनीक आपको अपनी साइट की जवाबदेही में तेजी लाने और उस पर लोड कम करने की अनुमति देती है, जिससे कई अनुरोधों के लिए समान संचालन करने की आवश्यकता समाप्त हो जाती है। उदाहरण के लिए, 2 + 2 कितने नहीं करते हैं, हमेशा 4 होगा, लेकिन कंप्यूटिंग 2 + 2 सर्वर संसाधनों को लेता है, इस मूल्य की 1 बार गणना करना बहुत अधिक लाभदायक है, जब पहला आगंतुक आता है, और फिर कहीं और लिखता है, ताकि अन्य उपयोगकर्ता को बाहर कर सकें। परिणाम है।

Http हेडर के साथ इस कैशिंग को भ्रमित न करें, उनका केवल एक विशिष्ट क्लाइंट (मूल में भी मध्यवर्ती प्रॉक्सी पर) पर प्रभाव पड़ता है, जबकि सर्वर पर कैशिंग कई उपयोगकर्ताओं को एक ही सामग्री देने के लिए डिज़ाइन किया गया है।

काश, किसी इंटरमीडिएट सर्वर को कैशिंग देना लाभदायक नहीं होता, किसी पृष्ठ पर थोड़े से अपडेट के मामले में, आपको स्क्रैच से एक पेज बनाना होगा, और आधुनिक वास्तविकताओं को देखते हुए, जब किसी पृष्ठ पर बहुत सारे डायनामिक तत्व होंगे, तो वास्तव में प्रत्येक पेज अद्वितीय होगा, और दूसरी ओर, फॉर्म का अनुरोध प्राप्त होता है। somepage.html; someshit = 12345 कैश के माध्यम से टूट जाएगा और एक नया पृष्ठ बन जाएगा जो इस पैरामीटर को भी ध्यान में नहीं रखेगा, लेकिन फिर भी इसके निर्माण के लिए लागत आएगी, जिसे फिर से एक हमलावर द्वारा उपयोग किया जा सकता है। इसलिए, कुछ लोग मध्यवर्ती कैश सर्वर का उपयोग करते हैं और उन पर भरोसा करना पहले से ही बहुत मुश्किल है।

यह एप्लिकेशन के अंदर सब कुछ कैश करने के लिए रहता है, लगभग हर फ्रेमवर्क अपनी बैसाखी प्रदान करता है, साथ ही तैयार किए गए सभी प्रकार के मेमोशेड्स और जैसे गंदगी। आमतौर पर, नौसिखिए डेवलपर्स केवल उबलते पानी में लिखते हैं जब उन्हें पता चलता है कि एक पेज बनाते समय, आप ज्ञापन के लिए 500 अनुरोध कर सकते हैं और इसके लिए कुछ भी नहीं होगा (सभी के पसंदीदा mysql के विपरीत)। नतीजतन, सभी कोड को आवरण के साथ कवर किया जाता है, जो पहले मेकचे में अनुरोध के परिणाम की जांच करते हैं, और फिर वे mysql में परिणाम के बाद चढ़ते हैं। मैं तर्क नहीं देता, कैश का मैनुअल नियंत्रण आवश्यक है, लेकिन पूरी तरह से मैनुअल कंट्रोल संभव त्रुटियों की ओर जाता है, जहां आप बस कैशिंग चालू करना भूल सकते हैं, जो मतलबी कानून के अनुसार, एक महत्वपूर्ण स्थान होगा।

इंटरफेस

साइट में क्या इंटरफ़ेस होना चाहिए? बस यह मत कहो कि हरा है।

पहले, एक नियम के रूप में, साइट की प्रस्तुति एकल और अविभाज्य थी। हालांकि, बड़े पोर्टलों पर बटन "प्रिंट संस्करण", या यहां तक ​​कि "वैप संस्करण" भी थे, जिसे बाद में "पीडीए संस्करण" द्वारा बदल दिया गया था - पहले से ही सादे HTML, केवल सरल। हालाँकि, कहाँ पर निर्भर करता है, अगर आप ट्विटर को लेते हैं, तो यह इसका एकमात्र पठनीय संस्करण है। समय बीतता गया और न केवल प्रिंटर और फोन के लिए, बल्कि सभी प्रकार के आईपैड और रेफ्रिजरेटर के लिए HTML5 समर्थन के साथ साइटों को संपादित करने की आवश्यकता थी। स्वाभाविक रूप से, यह सब डेवलपर्स के साथ प्यार में गिर गया, क्योंकि उन्हें वास्तव में प्रत्येक एक साइट के 10 संस्करण करने थे, और उन्होंने कुछ सार्वभौमिक करने का फैसला किया। साइट के लिए एक प्रकार का एपीआई।

एपीआई क्या है - मुझे नहीं पता। ईमानदारी से, मुझे नहीं पता। आमतौर पर यह कुछ प्रकार की बकवास है जब आप सर्वर पर urlencoded string के टुकड़े के साथ थूकते हैं, और बदले में आपको json / xml / सादे पाठ का एक टुकड़ा मिलता है, यह कितना भाग्यशाली है। बेशक, कोई भी मानक, यहां तक ​​कि आदिम डेटा प्रकार, कुछ भी नहीं हो सकता है, एक खाली परिणाम भी कुछ भी हो सकता है, अशक्त से "" (खाली उद्धरण चिह्न), या यहां तक ​​कि अनुपस्थित होने के परिणामस्वरूप। यह अच्छा है अगर लेखक REST जैसे शब्द के बारे में पढ़ें और इसे लागू करने के लिए दौड़ें, लेकिन बाकी सब चीजों की पृष्ठभूमि के खिलाफ, इसका कोई मतलब नहीं है। कार्यक्षमता भी स्पष्ट नहीं है, अगर एक HTML पृष्ठ का अनुरोध करके हम एक बार में सब कुछ पा सकते हैं (नवीनतम समाचार, टिप्पणियां, पसंद आदि), तो एपीआई के मामले में हमें कितने अनुरोध करने की आवश्यकता है - केवल इस एपीआई के लेखक को पता है, यह बहुत संभव है यह टिप्पणी प्राप्त की जा सकती है, लेकिन उन्हें पसंद है - नहीं। वास्तव में, एक एपीआई क्लाइंट और सर्वर विकास को पूरी तरह से अलग-अलग विकास टीमों में विभाजित करने का एक तरीका है जो एक-दूसरे के साथ खराब संपर्क करते हैं। और इस एपीआई की उपयोगिता के बारे में कोई बात नहीं हो सकती है।

और अक्सर ऐसा होता है कि एपीआई तक पहुंचने के लिए एक निश्चित कुंजी की आवश्यकता होती है। कुंजी अक्सर मुफ्त में प्राप्त की जा सकती है। इतनी चाबी क्यों नहीं मिली? समस्या यह है कि यह हमें कुछ आंतरिक लेखांकन के लिए अनुरोधों के स्पष्ट लेखांकन की ओर ले जाता है। और कौन जानता है कि जब लेखक यह सब मुद्रीकरण करना चाहता है? यह संभव है कि कुछ समय बाद नि: शुल्क चाबियाँ अक्षम या गंभीर रूप से सीमित हो जाएंगी, एक भुगतान किए गए टैरिफ का उपयोग करने की पेशकश की जाएगी। और कभी-कभी सामान्य तौर पर, सभी चाबियों को जारी करना निलंबित कर दिया जाता है, और सेवा बंद कर दी जाती है, यहां तक ​​कि वाणिज्यिक आधार पर भी, यह भी होता है। वैसे, एपीआई क्यों है? इस तरह के अपमान को सहना मेरे लिए पेज को लंबा करना और नियमित रूप से पार्स करना आसान है। इसलिए, मैं आपके इन एपीआई का उपयोग लगभग कभी नहीं करता हूं, खासकर जब से मैं उनकी सुविधाओं से निपटने नहीं जा रहा हूं।