निवेश, उत्पाद जीवन चक्र और सकारात्मक उपयोगकर्ता भावनाओं पर वेब एप्लिकेशन वास्तुकला का प्रभाव

हाल ही में "वेब एप्लिकेशन", "फ्रंट-एंड आर्किटेक्चर", "वेब 2.0", "एचटीएमएल 5 एप्लिकेशन" का उपयोग करना फैशनेबल हो गया है। लेकिन, दुर्भाग्य से, ज्यादातर मामलों में, इन शर्तों का उपयोग करने का संदर्भ हमेशा सच नहीं होता है, क्योंकि यह वेब एप्लिकेशन की वास्तुकला के कार्यान्वयन और उपयोग की सभी बारीकियों को ध्यान में नहीं रखता है। आज हम वास्तुकला के बारे में बात करेंगे।

इस लेख को लिखने की प्रेरणा ब्लॉग http://blog.pamelafox.org/2013/05/frontend-Healthectures-server-side-html.html पर प्रकाशित थी। यह ध्यान देने योग्य है कि यह काफी संकुचित है और एचटीएमएल 5 / मोबाइल को परिवर्तित करने की संभावना को ध्यान में नहीं रखता है। यहां हमने आर्किटेक्चर पर अधिक विस्तार से विचार करने की कोशिश की, वेब पर नवीनतम रुझानों और एप्लिकेशन ग्राहक के लिए कुछ प्रमुख बिंदुओं (जैसे सुरक्षा) पर ध्यान दिया।

शुरू करने के लिए, हम वेब अनुप्रयोगों के लिए सबसे सामान्य आर्किटेक्चर, उनके फायदे और नुकसान को तीन बिंदुओं से देखेंगे: ग्राहक, डेवलपर और उपयोगकर्ता। अन्य विकल्प संभव हैं, लेकिन वे अभी भी विचाराधीन आर्किटेक्चर के उपप्रकार हैं और मुख्य तीन तक कम हो गए हैं।

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

यहां सीधे उस आर्किटेक्चर से संबंधित भ्रम शुरू होता है जिसके साथ वेब एप्लिकेशन को लागू किया जाता है। तथ्य यह है कि आवेदन का तर्क सर्वर और क्लाइंट दोनों पर स्थित हो सकता है। विभिन्न आर्किटेक्चर क्लाइंट और सर्वर के बीच अलग-अलग तर्क वितर्क करते हैं।



दुर्भाग्य से, पूरी तरह से अलग आर्किटेक्चर का निष्पक्ष मूल्यांकन करना असंभव है। हम मूल्यांकन करने के लिए निम्नलिखित मानदंडों का उपयोग करेंगे:

उपयोगकर्ता:
जवाबदेही / प्रयोज्यता: किसी पृष्ठ पर डेटा अपडेट करना और पृष्ठों के बीच स्विच करना (याद करने का समय)। इंटरफ़ेस की समृद्धि और सुविधा, इसकी सहजता।
लिंकबिलिटी: साइट के विभिन्न वर्गों के लिए बुकमार्क और लिंक को बचाने की क्षमता।
ऑफलाइन: एक नेटवर्क के बिना आवेदन चलाने की क्षमता।

डेवलपर:
विकास की गति : नई कार्यक्षमता जोड़ने, रीफैक्टरिंग, डेवलपर्स और टाइपसेटर्स के बीच विकास प्रक्रिया के समानांतरकरण, आदि की गति।
प्रदर्शन: कंप्यूटिंग शक्ति की न्यूनतम लागत के साथ सर्वर से सबसे तेज प्रतिक्रिया।
स्केलेबिलिटी: सूचना की मात्रा या उपयोगकर्ताओं की संख्या में वृद्धि के कारण कंप्यूटिंग शक्ति या डिस्क स्थान को बढ़ाने की क्षमता। एक वितरित स्केलेबल सिस्टम का उपयोग करने के मामले में, डेटा स्थिरता, पहुंच और पृथक्करण प्रतिरोध (CAP- प्रमेय) सुनिश्चित किया जाना चाहिए। यह ध्यान दिया जाना चाहिए कि ग्राहक की इच्छाओं की वृद्धि के साथ एप्लिकेशन की सुविधाओं / स्क्रीनशॉट की संख्या (ग्राहक पक्ष पर) इस परिभाषा पर लागू नहीं होती है - यह वेब आर्किटेक्चर के प्रकार पर नहीं, बल्कि उपयोग किए गए और निष्पादन पर निर्भर करता है।
परीक्षण क्षमता : परीक्षण की क्षमता और आसानी (इकाई ऑटो-परीक्षण)।

ग्राहक:
कार्यात्मक एक्स्टेंसिबिलिटी: न्यूनतम समय और धन के साथ कार्यक्षमता बनाने की क्षमता।
एसईओ: उपयोगकर्ताओं को किसी भी खोज इंजन का उपयोग करके एप्लिकेशन को खोजने में सक्षम होना चाहिए।
समर्थन: एप्लिकेशन इन्फ्रास्ट्रक्चर को बनाए रखने की लागत - हार्डवेयर, नेटवर्क इन्फ्रास्ट्रक्चर की लागत, एप्लिकेशन को सेवा देने के लिए आवश्यक कर्मचारी।
सुरक्षा: एप्लिकेशन के ग्राहक को व्यावसायिक डेटा की सुरक्षा और अन्य उपयोगकर्ताओं के बारे में डेटा की अयोग्यता के बारे में सुनिश्चित होना चाहिए। मुख्य सुरक्षा मानदंड के रूप में, हम क्लाइंट पर एप्लिकेशन के व्यवहार की कार्यक्षमता को बदलने की संभावना के साथ-साथ इससे जुड़े जोखिमों पर भी विचार करेंगे। मानक खतरे (उदाहरण के लिए, https://www.owasp.org/index.php/Main_Page पर विश्लेषण) सभी तुलना किए गए आर्किटेक्चर के लिए समान हैं। हम इस तथ्य के कारण सर्वर-क्लाइंट डेटा ट्रांसफर सेक्शन में सुरक्षा को ध्यान में नहीं रखते हैं, क्योंकि सभी माना जाता है कि आर्किटेक्चर हैकिंग के लिए समान रूप से अतिसंवेदनशील हैं - डेटा ट्रांसफर चैनल समान हो सकता है।
रूपांतरण: वेबसाइट - एक मोबाइल या डेस्कटॉप एप्लिकेशन: मोबाइल बाजारों में एप्लिकेशन प्रकाशित करने की क्षमता, या इसे डेस्कटॉप एप्लिकेशन में न्यूनतम अतिरिक्त लागतों के साथ लपेटने की क्षमता।

शायद कुछ मापदंड या हमारी रेटिंग आपको गलत लग सकती है; लेकिन इस लेख का उद्देश्य "क्या अच्छा है और क्या बुरा है" दिखाना नहीं है, लेकिन एक अधिक विस्तृत समीक्षा करना और पसंद की संभावना दिखाना है।

आइए सर्वर और ब्राउज़र (क्लाइंट) द्वारा की जाने वाली भूमिकाओं के आधार पर मुख्य प्रकार के वेब अनुप्रयोगों की पहचान करने का प्रयास करें।

टाइप 1: सर्वर-साइड HTML



इस समय सबसे आम वास्तुकला। यह इस तथ्य में शामिल है कि सर्वर HTML सामग्री उत्पन्न करता है और इसे क्लाइंट को पूर्ण HTML पृष्ठ के रूप में भेजता है।
इस वास्तुकला को कभी-कभी "वेब 1.0" के रूप में संदर्भित किया जाता है, क्योंकि यह पहली बार दिखाई दिया था और वर्तमान में वेब पर प्रमुख है।

जवाबदेही / उपयोगिता: 1/5। माना आर्किटेक्चर का कम से कम इष्टतम। यह इस तथ्य के कारण है कि सर्वर और क्लाइंट के बीच डेटा की एक बड़ी मात्रा को स्थानांतरित करना आवश्यक है, न केवल व्यवसाय डेटा के लिए, बल्कि इसके डिजाइन के लिए भी जिम्मेदार है। उपयोगकर्ता को तुच्छ कार्यों के जवाब में पृष्ठ को फिर से लोड करने के लिए प्रतीक्षा करने के लिए मजबूर किया जाता है, उदाहरण के लिए, पृष्ठ के केवल एक छोटे से हिस्से को अपडेट करना। क्लाइंट पर यूआई टेम्प्लेट सीधे सर्वर पर उपयोग किए जाने वाले फ्रेमवर्क पर निर्भर करते हैं। सीमित मोबाइल इंटरनेट और भेजे गए डेटा की बड़ी मात्रा के कारण, यह आर्किटेक्चर व्यावहारिक रूप से मोबाइल सेगमेंट में कार्यात्मक नहीं है। त्वरित डेटा अपडेट या वास्तविक समय में परिवर्तन देने का कोई तरीका नहीं है। यदि हम सर्वर-साइड जनरेट करके और क्लाइंट को (AJAX, वेब सॉकेट के माध्यम से) सामग्री के तैयार किए गए टुकड़ों के रूप में अपडेट करने की संभावना पर विचार करते हैं, साथ ही पृष्ठ के भाग के प्रतिस्थापन के साथ डिजाइन तैयार करते हैं, तो हम पहले से ही विचार के तहत वास्तुकला की सीमाओं से परे जाएंगे।
लिंक करने की क्षमता: 5/5। विचाराधीन आर्किटेक्चर में, लिंकेबिलिटी को इसमें लागू करना सबसे आसान है। यह इस तथ्य के कारण है कि सर्वर पर, एक विशिष्ट HTML सामग्री डिफ़ॉल्ट रूप से एक URL को दी गई है।
एसईओ: 5/5। यह काफी सरल रूप से लागू किया गया है, पिछले पैराग्राफ के समान - पृष्ठ की सामग्री पहले से ज्ञात है।
विकास की गति: 5/5। सबसे पुरानी वास्तुकला, इसलिए किसी भी सर्वर भाषा और विशिष्ट आवश्यकताओं के लिए रूपरेखा चुनना संभव है।
स्केलेबिलिटी : 4/5। यदि हम HTML की पीढ़ी पर विचार करते हैं, तो अंत में बढ़ते भार के साथ एक ऐसा क्षण होता है जब लोड संतुलन के लिए संतुलन को लागू करना आवश्यक होता है। डेटाबेस स्केलिंग के साथ स्थिति बहुत अधिक जटिल है, लेकिन यह कार्य समान है और विचाराधीन सभी तीन आर्किटेक्चर के लिए विशेषता है।
उत्पादकता: 3/5। यातायात, गति, आदि के संदर्भ में जवाबदेही और स्केलिंग से संबंधित। प्रदर्शन कम है, क्योंकि इसके लिए HTML, डिज़ाइन और साथ ही व्यावसायिक डेटा में सबसे बड़ी डेटा के हस्तांतरण की आवश्यकता होती है। इस प्रकार, पूरे पृष्ठ के लिए डेटा उत्पन्न करना आवश्यक है (और न केवल परिवर्तित व्यापार डेटा के लिए), साथ ही साथ सभी संबंधित जानकारी (उदाहरण के लिए, लेआउट)।
परीक्षण क्षमता: 4/5। इस वास्तुकला का सकारात्मक पहलू यह है कि फ्रंट-एंड के परीक्षण के लिए, सामान्य स्थिति में, जावास्क्रिप्ट की व्याख्या का समर्थन करने वाले विशेष उपकरणों की आवश्यकता नहीं है (क्योंकि पृष्ठों की सामग्री स्थिर है)।
सुरक्षा: 4/5। "आप वह नहीं तोड़ सकते जो नहीं है" - अनुप्रयोग के व्यवहार का पूरा तर्क सर्वर पर है। उसी समय, डेटा स्पष्ट रूप में भेजा जाता है, इसलिए, यदि आवश्यक हो, तो एक सुरक्षित चैनल की सिफारिश की जाती है (जो अनिवार्य रूप से सर्वर से जुड़े किसी भी आर्किटेक्चर पर लागू होती है)। सभी सुरक्षा कार्यक्षमता सर्वर साइड पर आती है।
रूपांतरण: वेबसाइट - मोबाइल या डेस्कटॉप अनुप्रयोग: 0/5। ज्यादातर मामलों में, यह संभव नहीं है। अपवाद (या, बल्कि, विदेशी) दुर्लभ मामले हैं: उदाहरण के लिए, यदि आपके सर्वर को नोड.जेएस पर लागू किया गया है और कोई बड़ा डेटाबेस नहीं है; या यदि आप डेटा प्राप्त करने के लिए तृतीय-पक्ष वेब सेवाओं का उपयोग करते हैं (लेकिन यह आर्किटेक्चर का अधिक उन्नत संस्करण है)। इस तरह आप नोड-वेबकिट या साथियों का उपयोग करके अपने आवेदन को लपेटते हैं।
ऑफलाइन: 2/5। HTML5 विनिर्देश में शुरू किए गए सर्वर मेनिफ़ेस्ट का उपयोग करके कार्यान्वित किया गया। यदि ब्राउज़र इस विनिर्देश का समर्थन करता है, तो एप्लिकेशन के सभी पृष्ठ कैश हो जाएंगे, और यदि नेटवर्क से डिस्कनेक्ट किया गया है, तो कैश्ड पृष्ठ उपयोगकर्ता को प्रदर्शित किया जाएगा।

टाइप 2: JS जेनरेशन विजेट्स (AJAX)



पहले प्रकार की वास्तुकला का विकास। अंतर यह है कि ब्राउज़र में प्रदर्शित पृष्ठ में विजेट्स (कार्यात्मक रूप से स्वतंत्र ब्लॉक) होते हैं। इन विजेट्स में डेटा सर्वर से AJAX अनुरोध के साथ भरा हुआ है: या तो HTML का एक पूरा टुकड़ा के साथ; या तो JSON के रूप में, और पहले से ही जावास्क्रिप्ट-टेम्प्लेट / बिनिंग का उपयोग करने से पृष्ठ सामग्री में परिवर्तित हो जाते हैं। HTML के टुकड़ों को लोड करने का विकल्प क्लाइंट-साइड जावास्क्रिप्ट-एमवी * फ्रेमवर्क की आवश्यकता को समाप्त करता है, इस स्थिति में कुछ सरल के साथ करना संभव है, उदाहरण के लिए, jQuery। अन्तरक्रियाशीलता को कम करके, हम विकास की गति को तेज करते हैं और कार्यक्षमता को सस्ता और अधिक विश्वसनीय बनाते हैं।

मुख्य लाभ यह है कि सर्वर से केवल उस पेज को अपडेट करने के लिए डेटा भेजा जाता है जिसे क्लाइंट अपडेट करने का अनुरोध कर रहा है। अच्छी बात यह है कि विजेट्स को कार्यात्मक रूप से अलग किया जाता है, और पृष्ठ के उस हिस्से की कार्यक्षमता को बदलना जो किसी विशेष विजेट के लिए जिम्मेदार है, वह सभी को प्रभावित नहीं करेगा।

जवाबदेही / उपयोगिता : 3/5। पृष्ठ के केवल भाग को अपडेट करने के लिए भेजे गए डेटा की मात्रा पूरे पृष्ठ की तुलना में बहुत कम है, इसलिए जवाबदेही अधिक है। लेकिन इस तथ्य के कारण कि पृष्ठ विगेट्स का एक सेट है, वेब अनुप्रयोग में लागू यूआई टेम्पलेट लागू यूआई फ्रेमवर्क द्वारा सीमित हैं। यह ध्यान देने योग्य है कि इस तरह के वेब पेज का "कोल्ड स्टार्ट" (पहला फुल लोड) थोड़ा लंबा होगा। सर्वर पर पूरी तरह से उत्पन्न और कैश की गई सामग्री को क्लाइंट पर तुरंत प्रदर्शित किया जा सकता है; यहाँ, समय विजेट के लिए डेटा प्राप्त करने पर और एक नियम के रूप में, टेंपलेटिंग पर खर्च किया जाता है। इस प्रकार, जब आप पहली बार साइट में प्रवेश करते हैं तो बहुत तेज़ी से नहीं खुलेंगे, लेकिन तब पहली बार वास्तुकला के साथ तुलना में काम करना अधिक सुखद होगा। यह "भागों में" डाउनलोड को लागू करने की संभावना का उल्लेख करने के लायक भी है (जैसा कि http://www.yahoo.com/ पर किया गया है)।
लिंक करने की क्षमता : 2/5। विशेष उपकरण और तंत्र की जरूरत है। एक नियम के रूप में, एक हैश-बैंग तंत्र का उपयोग किया जाता है।
एसईओ : 2/5। इन कार्यों के लिए विशेष तंत्र हैं। उदाहरण के लिए, इस वास्तुकला की साइटों को बढ़ावा देने के लिए, उन पृष्ठों की सूची को बढ़ावा देना और पैरामीटर और संशोधक के बिना उनके लिए स्थैतिक URL बनाना पूर्व-निर्धारित करना संभव है।
विकास की गति: 3/5। इसके लिए न केवल सर्वर-साइड तकनीकों का ज्ञान होना चाहिए, बल्कि क्लाइंट साइड पर जावास्क्रिप्ट फ्रेमवर्क का उपयोग भी करना होगा। एक सर्वर-साइड समानता कार्यान्वयन भी आवश्यक है।
प्रदर्शन: 4/5। एचटीएमएल कंटेंट को जेनरेट करने में लगने वाला समय और संसाधन उस समय की तुलना में अपेक्षाकृत कम होते हैं, जब एप्लिकेशन डेटाबेस से डेटा प्राप्त करने और टेम्पलेट जेनरेशन से पहले इसे प्रोसेस करने पर खर्च करता है। इस आर्किटेक्चर के एक विस्तारित प्रकार का उपयोग करना (जब डेटा JSON के रूप में प्रेषित होता है), हालांकि यह क्लाइंट और सर्वर के बीच ट्रैफ़िक को कम करता है, यह एप्लिकेशन में एब्सट्रैक्शन का एक अतिरिक्त स्तर जोड़ता है: डेटाबेस से निकालना -> डेटा प्रोसेसिंग, JSON में क्रमांकन -> एपीआई: JSON -> पार्सिंग JSON -> क्लाइंट डेटा ऑब्जेक्ट HTML से बाइंडिंग।
स्केलेबिलिटी: पहले प्रकार की वास्तुकला के समान।
परीक्षण क्षमता: 1/5। सर्वर साइड, क्लाइंट कोड और एक वेब सेवा पर परीक्षण की आवश्यकता होती है जो विजेट्स को अपडेट करने के लिए डेटा लौटाती है।
सुरक्षा: 4/5। लॉजिक का एक हिस्सा क्लाइंट-साइड जावास्क्रिप्ट में किया जाता है, जिसे एक हमलावर द्वारा आसानी से संशोधित किया जा सकता है।
रूपांतरण: वेबसाइट - मोबाइल या डेस्कटॉप अनुप्रयोग: पहले प्रकार की वास्तुकला के समान।
ऑफलाइन: 1/5 इस मामले में प्रकट तंत्र भी काम करता है, लेकिन समस्या तब होती है जब विजेट पर प्रदर्शित डेटा को अपडेट या कैशिंग करता है। इस कार्यक्षमता को अतिरिक्त रूप से लागू करने की आवश्यकता है, क्योंकि प्रकट में आप केवल उन फ़ाइलों के नाम निर्दिष्ट कर सकते हैं जिन्हें सर्वर से कैश किया जाएगा। विजेट टेम्प्लेट फ़ाइल के नाम के बीच संबंध का संगठन प्रकट में कैश्ड है और पृष्ठ व्यवहार तर्क को अतिरिक्त कार्य की आवश्यकता है।

टाइप 3: सर्विस-ओरिएंटेड सिंगल-पेज वेब ऐप्स (वेब ​​2.0, एचटीएमएल 5 ऐप)



यहां मैं एक छोटी सी टिप्पणी करना चाहूंगा कि "वेब 2.0" शब्द यहां उपयोग करने के लिए बिल्कुल सही नहीं है। यह पहली बार टिम ओ'रिली द्वारा "सिस्टम को डिजाइन करने के लिए एक कार्यप्रणाली के रूप में पेश किया गया था, जो नेटवर्क इंटरैक्शन को ध्यान में रखते हुए, बेहतर हो जाता है कि जितने अधिक लोग उनका उपयोग करते हैं।" और वेब 2.0 की ख़ासियत उपयोगकर्ताओं को सूचना सामग्री को भरने और दोहराया सत्यापन के लिए आकर्षित करने का सिद्धांत है। वास्तव में, शब्द "वेब 2.0" उन परियोजनाओं और सेवाओं को संदर्भित करता है जो स्वयं उपयोगकर्ताओं द्वारा सक्रिय रूप से विकसित और सुधार किए जाते हैं: ब्लॉग, विकी, सोशल नेटवर्क, आदि। इसमें से यह निम्नानुसार है कि वेब 2.0 किसी एक तकनीक या प्रौद्योगिकियों के सेट से बंधा नहीं है।

प्रश्न में वास्तुकला का सार यह है कि एक HTML पृष्ठ सर्वर से लोड किया गया है, जो कि जावास्क्रिप्ट कोड के लिए एक कंटेनर है जो एक विशिष्ट वेब सेवा तक पहुंचने पर, इसमें से केवल व्यावसायिक डेटा प्राप्त करता है। जिनमें से, बदले में, जावास्क्रिप्ट एप्लिकेशन पेज की HTML सामग्री उत्पन्न करता है। वास्तव में, तीसरे प्रकार की वास्तुकला पिछले प्रकार का विकास है और इसे कार्यक्षमता के हिस्से को क्लाइंट पक्ष में स्थानांतरित करके एक स्वतंत्र, काफी जटिल जावास्क्रिप्ट एप्लिकेशन के पूर्ण स्तर पर लाया जाता है। दूसरे प्रकार का एक आर्किटेक्चर आमतौर पर बहुत बड़ी संख्या में परस्पर, संरचित कार्यों का दावा नहीं कर सकता है।

यह भी ध्यान दिया जाना चाहिए कि जावास्क्रिप्ट अनुप्रयोग जो पूरी तरह से ऑफ़लाइन काम करते हैं, लगभग कभी नहीं बनाये जाते हैं (दुर्लभ अपवादों के साथ: http://www.wakanda.org/ , http://html.adobe.com/edge/code/ , http: / /cdn.sencha.io/touch/sencha-touch-2.2.1/examples/kitchensink/index.html , http://rad-js.com/ ), यह दृष्टिकोण आसान रिवर्स रूपांतरण के लिए अनुमति देता है - किसी मौजूदा एप्लिकेशन को प्रकाशित करें वेब।

जवाबदेही / उपयोगिता: 5/5। जानकारी अपडेट करने के लिए भेजा गया डेटा न्यूनतम है, इसलिए अधिकतम जवाबदेही है। UI का उपयोग जावास्क्रिप्ट द्वारा किया जाता है। कोई भी आवश्यक विकल्प लागू किया जा सकता है। सूक्ष्म बिंदु जावास्क्रिप्ट में मल्टीथ्रेडिंग का मुद्दा है: हमारे मामले में, व्यापार डेटा के बड़े संस्करणों के प्रसंस्करण को वेब सेवा के पक्ष में लाया जाना चाहिए)
जुड़ाव: 1/5। न केवल विशेष उपकरण और तंत्र की आवश्यकता है, बल्कि ऐसे फ्रेमवर्क भी हैं जो उदाहरण के लिए, हैश-बैंग तंत्र का उपयोग कर सकते हैं।
एसईओ: १/५ सबसे भारी पदोन्नति वास्तुकला। यदि पूरे आवेदन को सीधे बढ़ावा दिया जा रहा है, तो कोई समस्या नहीं है: आवेदन कंटेनर को बढ़ावा देना संभव है। यदि आवेदन के हिस्सों का रोटेशन आवश्यक है, तो फिलहाल सभी तंत्र निम्नलिखित के समान हैं: http://googlewebmastercentral.blogspot.com/2009/10/proposal-for-making-ajax-crawlable.html और http: // seodacha वा / समाचार / यांडेक-प्रेडलागेट-रेस्नी-डेल्या-इंडेकसैकी-अजाक्स-सॉल्टोव । प्रत्येक या कम बड़े खोज इंजन इस प्रक्रिया को मानकीकृत करने के लिए अपने तरीके प्रदान करते हैं।
विकास की गति: 2/5। इसके लिए एक वेब सेवा के विकास और अधिक विशिष्ट (एप्लिकेशन आर्किटेक्चर का निर्माण) जावास्क्रिप्ट चौखटे के उपयोग की आवश्यकता होती है। यह उल्लेखनीय है कि वास्तुकला की नवीनता के कारण, इस दृष्टिकोण के साथ वास्तव में उच्च-गुणवत्ता वाली वेबसाइट / सिस्टम बनाने में सक्षम कुछ विशेषज्ञ हैं; कुछ विकसित और अच्छी तरह से विकसित उपकरण, रूपरेखा और दृष्टिकोण।
प्रदर्शन: 5/5। आर्किटेक्चर के साथ, इस विशेषता का सर्वर साइड पर सबसे कम प्रभाव पड़ता है, क्योंकि सर्वर को केवल जेएस एप्लिकेशन को ब्राउज़र में भेजने की आवश्यकता होती है। क्लाइंट की तरफ, ब्राउज़र का प्रदर्शन और प्रकार सबसे महत्वपूर्ण है।
स्केलेबिलिटी: 5/5। सभी वेब लॉजिक क्लाइंट साइड में दिए गए हैं; कंटेंट जेनरेट करने के लिए सर्वर पर कोई लोड नहीं रखा गया है। उपयोगकर्ताओं की संख्या में वृद्धि के साथ, स्केलिंग केवल उन वेब सेवाओं के लिए आवश्यक है जो व्यवसाय डेटा प्रदान करती हैं।
परीक्षण क्षमता: 3/5। वेब सेवाओं और क्लाइंट-साइड जावास्क्रिप्ट कोड का परीक्षण आवश्यक है।
सुरक्षा: 0/5। सभी तर्क क्लाइंट-साइड जावास्क्रिप्ट में किए जाते हैं, जिसे एक हमलावर द्वारा आसानी से संशोधित किया जा सकता है। इसलिए, सुरक्षित प्रणालियों के लिए, एक निवारक वास्तुकला विकसित करना आवश्यक है, जो ओपन-सोर्स एप्लिकेशन http://aosabook.org/en/index.html के संगठन की विशेषताओं को ध्यान में रखता है - उदाहरण के लिए, एक तृतीय-पक्ष कुंजी वितरण चैनल के साथ एक विकल्प।
रूपांतरण: वेबसाइट - मोबाइल या डेस्कटॉप अनुप्रयोग: ५/५ साइट चुपचाप http://phonegap.com/ , https://github.com/rogerwang/node-webkit , https://code.google.com/p/chromiumembedded/ और अन्य जैसे प्लेटफार्मों का उपयोग करके एक एप्लिकेशन में बदल रही है उस तरह।
ऑफलाइन: 5/5। यह वास्तुकला एक पूर्ण अनुप्रयोग है; किसी भी स्टोरेज (उदाहरण के लिए, लोकलस्टोरेज) का उपयोग करके व्यक्तिगत डेटा और एप्लिकेशन के कुछ हिस्सों को सहेजना संभव है। एक और प्लस यह है कि आप डेटा के भंडारण और प्रबंधन को पूरी तरह से ऑफ़लाइन मोड में बदल सकते हैं; जबकि दो पिछले आर्किटेक्चर केवल आंशिक रूप से कार्यात्मक ऑफ़लाइन हैं। , , .

- , , — . , «», , , , - .

इस प्रकार, हम देख सकते हैं कि कोई आदर्श वास्तुकला नहीं है - सबसे इष्टतम प्रकार की पसंद कार्यों और प्राथमिकताओं पर आधारित है। एप्लिकेशन आर्किटेक्चर को अनुकूलित करना या हाइब्रिड आर्किटेक्चर को लागू करना भी संभव है जो आपके व्यावसायिक आवश्यकताओं में पूरी तरह फिट बैठता है।



इस तालिका में प्रत्येक मानदंड के लिए भार कारक शामिल नहीं हैं; प्रत्येक वास्तविक परियोजना के लिए, मानदंडों में से एक एक मौलिक भूमिका निभा सकता है।