सिंगल पेज एप्लीकेशन: फायदे और नुकसान [बंद]

Question

मैंने एसपीए के बारे में पढ़ा है और इसके फायदे हैं। मैं उनमें से अधिकांश को असंबद्ध पाता हूं। वहाँ 3 फायदे हैं जो मेरे संदेह को जगाते हैं।

प्रश्न: क्या आप एसपीए के वकील के रूप में कार्य कर सकते हैं और साबित कर सकते हैं कि मैं पहले तीन बयानों के बारे में गलत हूं?

                              === ADVANTAGES ===

1. एसपीए बहुत संवेदनशील साइटों के लिए बहुत अच्छा है:

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

HTML को पुनः प्राप्त करने के लिए एक सर्वर राउंडट्रिप की आवश्यकता के बिना यूआई के किसी भी हिस्से को फिर से तैयार करने की उनकी क्षमता के आधार पर सिंगल पेज ऐप्स को प्रतिष्ठित किया जाता है। यह एक मॉडल परत होने से डेटा की प्रस्तुति से डेटा को अलग करने के द्वारा प्राप्त किया जाता है जो डेटा को संभालता है और एक दृश्य परत जो मॉडल से पढ़ता है।

गैर-एसपीए के लिए एक मॉडल परत रखने में क्या गलत है? क्या MVC क्लाइंट की तरफ MVC के साथ एकमात्र संगत आर्किटेक्चर है?

2. एसपीए के साथ हमें पृष्ठों को डाउनलोड करने के लिए सर्वर पर अतिरिक्त प्रश्नों का उपयोग करने की आवश्यकता नहीं है।

Hah, और आपकी साइट पर जाने के दौरान उपयोगकर्ता कितने पेज डाउनलोड कर सकता है? दो तीन? इसके बजाय एक और सुरक्षा समस्याएं दिखाई देती हैं और आपको अपने लॉगिन पृष्ठ, व्यवस्थापक पृष्ठ आदि को अलग-अलग पृष्ठों में बदलना होगा। बदले में यह एसपीए वास्तुकला के साथ संघर्ष करता है।

3. किसी भी अन्य लाभ हो सकता है? किसी और के बारे में मत सुनो ..

                            === DISADVANTAGES ===

1. क्लाइंट को जावास्क्रिप्ट सक्षम करना चाहिए।
2. साइट पर केवल एक प्रवेश बिंदु।
3. सुरक्षा।

PS मैंने एसपीए और गैर-एसपीए परियोजनाओं पर काम किया है। और मैं उन सवालों को पूछ रहा हूं क्योंकि मुझे अपनी समझ को गहरा करने की जरूरत है। एसपीए समर्थकों को नुकसान पहुंचाने का कोई मतलब नहीं है। एसपीए के बारे में मुझे कुछ और पढ़ने के लिए मत कहिए। मैं सिर्फ उस बारे में आपके विचार सुनना चाहता हूं।

Comments

2. और 3. मुद्दे नहीं हैं।

— विकटोर ज़िकला

मेरा सुझाव है कि एसपीए के बारे में सिर्फ पढ़ने के बजाय, आप कुछ समय एक्जिट जैसे वास्तविक ढांचे के साथ खेलने में बिता सकते हैं। जिस समय वहां भुगतान होगा, आप भुगतान करेंगे और आप अपने स्वयं के प्रश्नों का उत्तर दे पाएंगे।

— विकटोर ज़िकला

@WiktorZychla मैं एक एसपीए परियोजना पर काम करता हूं। मैं JQuery + बैकबोन का उपयोग करता हूं। मैंने एक JSP साइट भी लिखी है। मैं उन सवालों का जवाब नहीं दे सकता। क्या आप?

— VB_

@VolodymyrBakhmatiuk: कोई फर्क नहीं पड़ता कि क्या उपयोगकर्ता समझौता कर सकता है, डेटा नहीं है क्योंकि डेटा सर्वर साइड पर संरक्षित है।

— विकटोर ज़िकला

यदि यह प्रश्न राय आधारित है तो क्या होगा? मैं अक्सर सोचता था कि मुझे एसपीए क्यों और कब लिखना चाहिए? यह उपयोगी होगा यदि SO ने पेशेवरों को विपक्ष के प्रश्नों की अनुमति दी हो

— अनुराग अवस्थी

Answer 1

चलो सबसे लोकप्रिय एसपीए साइटों में से एक को देखें, जीमेल।

1. एसपीए बहुत संवेदनशील साइटों के लिए बहुत अच्छा है:

सर्वर-साइड रेंडरिंग उतना कठिन नहीं है, जितना कि URL में #hash रखने या हाल ही में HTML5pushState जैसी सरल तकनीकों के साथ हुआ करता था । इस दृष्टिकोण के साथ वेब एप्लिकेशन की सटीक स्थिति पृष्ठ URL में सन्निहित है। जैसा कि जीमेल में हर बार मेल खोलने पर URL में एक विशेष हैश टैग जोड़ा जाता है। यदि अन्य ब्राउज़र विंडो में कॉपी और पेस्ट किया जाता है, तो ठीक उसी मेल को खोल सकते हैं (बशर्ते वे प्रमाणित कर सकें)। यह दृष्टिकोण सीधे एक अधिक पारंपरिक क्वेरी स्ट्रिंग में मैप करता है, अंतर केवल निष्पादन में है। HTML5 pushState () के साथ आप #hashपूरी तरह से क्लासिक URL को समाप्त कर सकते हैं और पहले अनुरोध पर सर्वर पर हल कर सकते हैं और फिर बाद के अनुरोधों पर ajax के माध्यम से लोड कर सकते हैं।

2. एसपीए के साथ हमें पृष्ठों को डाउनलोड करने के लिए सर्वर पर अतिरिक्त प्रश्नों का उपयोग करने की आवश्यकता नहीं है।

मेरी वेब साइट पर जाने के दौरान पृष्ठों के उपयोगकर्ता डाउनलोड की संख्या ?? वास्तव में कितने मेल पढ़ते हैं, जब वह अपना मेल खाता खोलता है। मैंने एक बार में> 50 पढ़े। अब मेल की संरचना लगभग समान है। यदि आप एक सर्वर साइड रेंडरिंग योजना का उपयोग करेंगे, तो सर्वर हर अनुरोध (विशिष्ट मामले) पर इसे प्रस्तुत करेगा। - सुरक्षा चिंता - आपको प्रवेश / लॉगिन के लिए अलग-अलग पृष्ठ नहीं रखने चाहिए / जो कि पूरी तरह से आपकी साइट की संरचना पर निर्भर करता है paytm.com लेती है उदाहरण के लिए एक वेब साइट एसपीए बनाने का मतलब यह नहीं है कि आप सभी के लिए सभी समापन बिंदु खोलते हैं उपयोगकर्ताओं को मेरा मतलब है कि मैं अपने स्पा वेब साइट के साथ रूपों का उपयोग करता हूं। - शायद सबसे अधिक इस्तेमाल किया जाने वाला एसपीए फ्रेमवर्क कोणीय जेएस में देव पूरे एचटीएमएल मंदिर को वेब साइट से लोड कर सकते हैं ताकि उपयोगकर्ताओं के प्रमाणीकरण स्तर के आधार पर किया जा सके। सभी प्रकार के प्रकार के लिए प्री लोडिंग html

3. कोई अन्य लाभ हो सकता है? किसी और के बारे में मत सुनो ..

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

लाभ जो मैं सोच सकता हूं:

1. HTML प्रदान करना स्पष्ट रूप से कुछ संसाधनों को लेता है अब आप जिस भी साइट पर जा रहे हैं, प्रत्येक उपयोगकर्ता ऐसा कर रहा है। न केवल प्रमुख लॉगिक्स को रेंडर करने से सर्वर साइड के बजाय क्लाइंट साइड किया जाता है।
2. दिनांक समय समस्याएँ - मैं सिर्फ क्लाइंट को देता हूं यूटीसी समय एक पूर्व निर्धारित प्रारूप है और यहां तक ​​कि उस समय के बारे में परवाह नहीं है जो मैंने जावास्क्रिप्ट को इसे संभालने दिया है। यह बहुत फायदा है जहाँ मुझे उपयोगकर्ताओं के आईपी से प्राप्त स्थान के आधार पर टाइम ज़ोन का अनुमान लगाना था।
3. मेरे लिए राज्य एक एसपीए में अधिक अच्छी तरह से बनाए रखा जाता है क्योंकि एक बार जब आप एक चर निर्धारित करते हैं तो आप जानते हैं कि यह वहां होगा। यह एक वेब पेज के बजाय एक ऐप विकसित करने का अनुभव देता है। यह आम तौर पर फूडपांडा, फ्लिपकार्ट, अमेज़ॅन जैसी साइटों को बनाने में बहुत मदद करता है। क्योंकि यदि आप क्लाइंट साइड स्टेट का उपयोग नहीं कर रहे हैं तो आप महंगे सत्रों का उपयोग कर रहे हैं।
4. वेबसाइटें निश्चित रूप से बेहद संवेदनशील हैं - मैं एक गैर एसपीए वेबसाइट में कैलकुलेटर बनाने की कोशिश के लिए एक चरम उदाहरण लूंगा (मुझे पता है कि यह अजीब है)।

टिप्पणियों से अपडेट

ऐसा लगता नहीं है कि किसी ने सॉकेट और लंबे समय के मतदान के बारे में उल्लेख किया है। यदि आप किसी अन्य क्लाइंट से मोबाइल ऐप कहते हैं, तो आपका ब्राउज़र भी लॉग आउट होना चाहिए। यदि आप एसपीए का उपयोग नहीं करते हैं, तो आपको हर बार रीडायरेक्ट होने पर सॉकेट कनेक्शन को फिर से बनाना होगा। यह डेटा में किसी भी अपडेट जैसे अधिसूचना, प्रोफ़ाइल अपडेट आदि के साथ भी काम करना चाहिए

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

Comments

इसे एक समुदाय बनाने के लिए आप पर अच्छा है विकी उत्तर :) इसके अलावा ये महान बिंदु हैं

— जेसन स्पर्सके

@Parv शर्मा कृपया अधिक व्यापक रूप से बताएं कि एसपीए के साथ राज्य अधिक टिकाऊ क्यों है?

— VB_

आप आसानी से एसपीए के साथ एसईओ अनुकूलन के लिए पृष्ठों को अनुक्रमित नहीं कर सकते।

— अंकित_शाह ५५

@ Ankit_Shah55 यह अब सच नहीं हो सकता है (कम से कम Google के लिए, जो अधिकांश खोज इंजन बाजार का हिस्सा है वैसे भी)। Google से "हमारी AJAX क्रॉलिंग योजना का वर्णन करें" देखें। मेरी समझ यह है कि आपको अपने एसपीए को अनुक्रमित करने के लिए Google के लिए कुछ विशेष करने की आवश्यकता नहीं है। मुझे लगता है कि आपको पुशस्टेट का समर्थन करना सुनिश्चित करना होगा, हालांकि, मुझे नहीं लगता कि Google अनुक्रमित हैश के टुकड़े हैं।

— केविन व्हीलर

ऐसा लगता नहीं है कि किसी ने सॉकेट और लंबे समय के मतदान के बारे में उल्लेख किया है। यदि आप किसी अन्य क्लाइंट से मोबाइल ऐप कहते हैं, तो आपका ब्राउज़र भी लॉग आउट होना चाहिए। यदि आप एसपीए का उपयोग नहीं करते हैं, तो आपको हर बार रीडायरेक्ट होने पर सॉकेट कनेक्शन को फिर से बनाना होगा। यह डेटा में किसी भी अपडेट जैसे अधिसूचना, प्रोफ़ाइल अपडेट आदि के साथ भी काम करना चाहिए

— tsuz

Answer 2

मैं एक व्यावहारिक व्यक्ति हूं, इसलिए मैं इसे लागत और लाभ के संदर्भ में देखने की कोशिश करूंगा।

ध्यान दें कि किसी भी नुकसान के लिए, मैं मानता हूं कि वे हल करने योग्य हैं। यही कारण है कि मैं काले और सफेद के रूप में कुछ भी नहीं देखता, बल्कि लागत और लाभ।

लाभ

• आसान राज्य ट्रैकिंग - 2 पेज लोड के बीच राज्य को याद रखने के लिए कुकीज़, फॉर्म सबमिशन, लोकल स्टोरेज, सेशन स्टोरेज आदि का उपयोग करने की आवश्यकता नहीं है।
• बॉयलर प्लेट की सामग्री जो प्रत्येक पृष्ठ (हेडर, पाद, लोगो, कॉपीराइट बैनर, आदि) पर होती है, केवल विशिष्ट ब्राउज़र सत्र के अनुसार एक बार लोड होती है।
• "पृष्ठ" स्विच करने पर कोई ओवरहेड विलंबता नहीं।

नुकसान

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

फिर से, मैं मानता हूं कि इनमें से हर समस्या किसी न किसी कीमत पर हल करने योग्य है। लेकिन एक ऐसा बिंदु आता है जहाँ आप अपना सारा समय उन समस्याओं को हल करने में लगा रहे हैं, जिन्हें आप पहली बार में टाल सकते थे। यह लाभों पर वापस आता है और वे आपके लिए कितने महत्वपूर्ण हैं।

Comments

मुझे लगता है कि यह प्रतिक्रिया किसी ऐसे व्यक्ति से बहुत वैध प्रतिक्रिया प्रदान करती है जिसने वास्तव में एक बड़ी जटिल प्रणाली का निर्माण किया है और लंबे समय तक हताहतों की संख्या का अनुभव किया है, जो एसपीए लाता है (या ऐसा दिखता है)

— डैनियलकुआड्रा

इस उत्तर से मुझे जो मिलता है, वह एसपीए से बचें यदि आप कुछ भी कर रहे हैं तो दूर से गंभीर भी।

— इवानपी

मुझे लगता है कि आपने हमें सिर्फ जवाब देने के बजाय एक बहुत ही उपयोगी अवलोकन दिया। वास्तव में व्यावहारिक।

— होस मर्करी

मैं सहमत हूँ। जब हमने अवधारणा का प्रमाण दिया तो एसपीए बहुत अच्छा लगा। अब सड़क के 3 साल नीचे, हमने इस उत्तर में वर्णित प्रत्येक समस्या को देखा है और हम उन्हें हल करने की कोशिश में बहुत समय बिता रहे हैं। फ्रेमवर्क परिवर्तन अब एक विकल्प नहीं है और हम एक ऐसे ढांचे के साथ फंस गए हैं जो मूल रूप से विकास को रोक देता है।

— क्यूई फैन

मैंने सीधे पिछले 4 नुकसान बिंदुओं का अनुभव किया है। मैंने Angular JS JS कोड के बारे में 5K के साथ प्राथमिक खिलाड़ियों के रूप में Angular, बूटस्ट्रैप और PHP के साथ 10K LOC वेब ऐप बनाया है। कोणीय की कुछ बहुत ही साफ-सुथरी विशेषताएं हैं, लेकिन इस बिंदु पर मैं वास्तव में चाहता हूं कि मैंने सिर्फ एक पारंपरिक पृष्ठ आधारित दृष्टिकोण का उपयोग किया था और मुझे लगता है कि इससे साइट का विकास काफी बढ़ गया होगा।

— Zack Macomber

Answer 3

नुकसान

1. क्लाइंट को जावास्क्रिप्ट सक्षम करना चाहिए। हां, यह एसपीए का एक स्पष्ट नुकसान है। मेरे मामले में मुझे पता है कि मैं अपने उपयोगकर्ताओं से जावास्क्रिप्ट सक्षम होने की उम्मीद कर सकता हूं। यदि आप नहीं कर सकते हैं तो आप एसपीए, अवधि नहीं कर सकते। यह .NET फ्रेमवर्क स्थापित किए बिना मशीन के लिए एक .NET ऐप को तैनात करने की कोशिश करने जैसा है।

2. साइट पर केवल एक प्रवेश बिंदु। मैं SammyJS का उपयोग करके इस समस्या को हल करता हूं । अपनी रूटिंग को ठीक से सेट करने के लिए 2-3 दिन का काम, और लोग आपके ऐप में डीप-लिंक बुकमार्क बनाने में सक्षम होंगे जो सही तरीके से काम करते हैं। आपके सर्वर को केवल एक समापन बिंदु को उजागर करने की आवश्यकता होगी - "मुझे इस ऐप के लिए HTML + CSS + JS दें" समापन बिंदु (इसे एक पूर्व-निर्मित एप्लिकेशन के लिए डाउनलोड / अपडेट स्थान के रूप में देखें) - और क्लाइंट-साइड जावास्क्रिप्ट जिसे आप लिखते हैं आवेदन में वास्तविक प्रवेश संभाल।

3. सुरक्षा।यह मुद्दा एसपीए के लिए अद्वितीय नहीं है, आपको उसी तरह से सुरक्षा से निपटना होगा जब आपके पास "पुराने-स्कूल" क्लाइंट-सर्वर ऐप (पेजों के बीच लिंक करने के लिए हाइपरटेक्स्ट का उपयोग करने का हेटोस मॉडल) हो। यह सिर्फ इतना है कि उपयोगकर्ता आपके जावास्क्रिप्ट के बजाय अनुरोध कर रहा है, और यह परिणाम JSON या कुछ डेटा प्रारूप के बजाय HTML में हैं। एक गैर-एसपीए ऐप में आपको सर्वर पर व्यक्तिगत पृष्ठों को सुरक्षित करना होता है, जबकि एक एसपीए ऐप में आपको डेटा एंडपॉइंट्स को सुरक्षित करना होता है। (और, यदि आप अपने ग्राहक को सभी कोड तक पहुंच नहीं देना चाहते हैं, तो आपको डाउनलोड करने योग्य जावास्क्रिप्ट को अलग-अलग क्षेत्रों में विभाजित करना होगा। मैं बस इसे अपने सैमीजस-आधारित रूटिंग सिस्टम में बाँधता हूं, इसलिए ब्राउज़र केवल अनुरोध करता है उपयोगकर्ता की भूमिकाओं के प्रारंभिक भार के आधार पर ग्राहक को जो चीजें पता हैं, उसकी पहुंच होनी चाहिए,

लाभ

1. एसपीए का एक प्रमुख वास्तुशिल्प लाभ (जो शायद ही कभी उल्लेख किया गया है) कई मामलों में आपके ऐप की "गपशप" में भारी कमी है। यदि आप क्लाइंट (संपूर्ण बिंदु, सभी के बाद) पर अधिकांश प्रसंस्करण को संभालने के लिए इसे ठीक से डिज़ाइन करते हैं, तो सर्वर से अनुरोधों की संख्या ("आपके उपयोगकर्ता अनुभव को बर्बाद करने वाली 503 त्रुटियों के लिए संभावनाएं पढ़ें") नाटकीय रूप से कम हो जाती है। वास्तव में, एक एसपीए पूरी तरह से ऑफ़लाइन प्रसंस्करण करना संभव बनाता है, जो कुछ स्थितियों में बहुत बड़ा है।

2. यदि आप इसे सही करते हैं, तो क्लाइंट-साइड रेंडरिंग के साथ प्रदर्शन निश्चित रूप से बेहतर है, लेकिन एसपीए बनाने के लिए यह सबसे सम्मोहक कारण नहीं है। (नेटवर्क की गति में सुधार हो रहा है, सब के बाद।) अकेले इस आधार पर एसपीए के लिए मामला न बनाएं।

3. आपके UI डिज़ाइन में लचीलापन शायद दूसरा प्रमुख लाभ है जो मुझे मिला है। एक बार जब मैंने अपने एपीआई (जावास्क्रिप्ट में एसडीके के साथ) को परिभाषित किया, तो मैं कुछ स्थैतिक संसाधन फ़ाइलों से सर्वर पर शून्य प्रभाव के साथ अपने फ्रंट-एंड को पूरी तरह से फिर से लिखने में सक्षम था । एक पारंपरिक MVC ऐप के साथ ऐसा करने की कोशिश करें! :) (यह तब मूल्यवान हो जाता है जब आपके पास लाइव अपॉइंटमेंट्स और आपके चिंता करने के लिए एपीआई की संस्करण संगतता होती है।)

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

Comments

एक और लाभ यह है कि एक आईओएस पर एक बुकमार्क ("होम स्क्रीन में जोड़ें") के रूप में एक एसपीए को बचाया जा सकता है और इसे फुलस्क्रीन मोड में खोलना है (यह मानते हुए कि आपने सही मेटा टैग को परिभाषित किया है ), जिससे यह एक मूल ऐप की तरह लग रहा है और नहीं वेब पृष्ठ।

— स्ट्रिल

3. यह पारंपरिक MVC ऐप में उतना ही आसान है। यदि आप एक ही डेटा के साथ काम करते हैं तो आपको अपने ऐप के V (व्यू) हिस्से में बदलाव करने की ज़रूरत है। यह आमतौर पर टेम्पलेट, सीएसएस और जेएस है।

— कारंतन

क्या एसओ के एसपीए संस्करण में साझा करने के लिए अलग-अलग सवालों के लिंक हो सकते हैं, या यह क्या फायदे और नुकसान लाएगा, उदाहरण के लिए एसईओ (खोज इंजन से पिछले प्रश्नों की खोज) के संदर्भ में।

— सेल्कुक

ज्यादातर एसपीए ऐप जो मैंने देखे हैं वे सर्वर साइड एप्स की तुलना में ज्यादा चैटिंग हैं। डेटा प्राप्त करने के लिए एक एकल अनुरोध के बजाय आप प्रति पृष्ठ सर्वर के लिए अधिक अनुरोधों के साथ समाप्त होते हैं।

— मैथ्यू व्हीटेड

Answer 4

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

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

अपडेट 19.06.16:

थोड़ी देर पहले यह जवाब लिखने के बाद से, मुझे सिंगल पेज एप्स (अर्थात्, AngularJS 1.x) के साथ बहुत अधिक अनुभव प्राप्त हुआ है - इसलिए मेरे पास साझा करने के लिए अधिक जानकारी है।

मेरी राय में, एसपीए अनुप्रयोगों का मुख्य नुकसान एसईओ है, जो उन्हें केवल "डैशबोर्ड" ऐप के प्रकार तक सीमित करता है। इसके अलावा, आप क्लासिक समाधानों की तुलना में कैशिंग के साथ बहुत कठिन समय रखने जा रहे हैं। उदाहरण के लिए, ASP.NET कैशिंग में आसानी से आसान है - बस OutputCaching चालू करें और आप अच्छे हैं: पूरे HTML पृष्ठ को URL (या किसी अन्य पैरामीटर) के अनुसार कैश किया जाएगा। हालांकि, एसपीए में आपको खुद को कैशिंग को संभालने की आवश्यकता होगी (कुछ समाधान जैसे कि दूसरे स्तर के कैश, टेम्पलेट कैशिंग, आदि ..) का उपयोग करके।

Comments

क्या बेहतर है कि सिंगल पेज बनाम ट्रैफ़िक को एक दो पृष्ठों में फैलाया जाए?

— चुप

@SILENT - निश्चित नहीं है, लेकिन चूंकि एक ही डोमेन के सभी पृष्ठ, मुझे नहीं लगता कि अंतर होना चाहिए

— Illidan

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

— मार्संडबैक

@MarsAndBack: निश्चित नहीं है कि आप किस सर्वर लिंक के बारे में बात कर रहे हैं। यदि आपका मतलब साइटमैप है - तो यह एसपीए के मामले में बेकार है: खोज इंजन जावास्क्रिप्ट निष्पादित नहीं कर रहे हैं (कम से कम, यह कुछ साल पहले चीजों की स्थिति थी), वे केवल HTML डाउनलोड और पार्स करते हैं। इसलिए, भले ही आप साइटमैप तैयार करें - पृष्ठ का निर्माण सही तरीके से नहीं किया जाएगा।

— इलिडन

Answer 5

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

लेकिन अगर आपका पृष्ठ ज्यादातर प्रदर्शन के लिए है, उदाहरण के लिए, सेवा पृष्ठ की शर्तें, तो एक एसपीए पूरी तरह से ओवरकिल है।

मुझे लगता है कि विशेष स्थान पर निर्भर करते हुए स्वीट स्पॉट में एसपीए और स्थिर / एमवीसी शैली पृष्ठों के मिश्रण के साथ एक साइट है।

उदाहरण के लिए, एक साइट पर मैं निर्माण कर रहा हूं, उपयोगकर्ता मानक एमवीसी इंडेक्स पेज पर लैंड करता है। लेकिन फिर जब वे वास्तविक अनुप्रयोग पर जाते हैं, तो यह एसपीए को कॉल करता है। इसका एक और फायदा यह है कि एसपीए का लोड-टाइम होम पेज पर नहीं, बल्कि ऐप पेज पर है। मुख पृष्ठ पर लोड समय पहली बार साइट उपयोगकर्ताओं के लिए एक विकर्षण हो सकता है।

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

Comments

वेब विकास के कई वर्षों के बाद, जो मैं पुष्टि कर सकता हूं। आपको स्पा और एमएक्स ऐप दोनों को एक साथ मिलाना चाहिए। आप एक जवाब नहीं है, या तो नहीं कर सकते हैं। मेरे पास एक स्पा के रूप में मेरा पूरा ऐप था, मुझे लगा कि मेरा ऐप Google द्वारा सही तरीके से सूचीबद्ध नहीं है। इसलिए मैं एमपीए में चला गया और केवल आवश्यक स्थितियों में स्पा का उपयोग किया। वर्डप्रेस भी स्पा नहीं है और अच्छे कारणों के लिए एक लोकप्रिय ढांचा है।

— रुडोल्फ श्मिट

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

— मार्सएंडबैक

Answer 6

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

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

आजकल, "एम्बेडेड सिस्टम" के रूप में कुछ साल पहले मेनफ्रेम के रूप में शक्तिशाली हैं, REST के माध्यम से नियंत्रण इकाई से जुड़ा एक ब्राउज़र-आधारित यूआई संभव समाधान है। फायदा यह है कि, बिना किसी लागत के UI के लिए टूल का बहुत बड़ा पैलेट। (उदाहरण के लिए Qt को रॉयल्टी फीस पर 20-30 $ प्रति यूनिट की आवश्यकता है और साथ ही प्रति डेवलपर 3000-4000 डॉलर)

ऐसी वास्तुकला के लिए एसपीए कई फायदे प्रदान करता है - जैसे कि डेस्कटॉप-ऐप डेवलपर्स के लिए अधिक परिचित विकास-दृष्टिकोण, कम सर्वर एक्सेस (अक्सर कार-उद्योग में यूआई और सिस्टम मैडल्स अलग-अलग हार्डवेयर होते हैं, जहां सिस्टम-पार्ट में आरटी ओएस होता है)।

जैसा कि एकमात्र क्लाइंट अंतर्निहित ब्राउज़र है, जेएस-उपलब्धता, सर्वर-साइड लॉगिंग, सुरक्षा जैसे उल्लिखित नुकसान किसी भी अधिक की गणना नहीं करते हैं।

Comments

अमेज़ॅन बैंडविड्थ या अनुरोधों के बारे में बहुत चिंतित नहीं है। प्रत्येक पृष्ठ लगभग 10 एमबी है और 200 से अधिक अनुरोध हैं।

— मैथ्यू व्हीटेड

Answer 7

2. एसपीए के साथ हमें पृष्ठों को डाउनलोड करने के लिए सर्वर पर अतिरिक्त प्रश्नों का उपयोग करने की आवश्यकता नहीं है।

मुझे अभी भी बहुत कुछ सीखना है लेकिन जब से मैंने एसपीए के बारे में सीखना शुरू किया है, मैं उनसे प्यार करती हूं।

यह विशेष बिंदु भारी अंतर ला सकता है।

कई वेब ऐप में, जो एसपीए नहीं हैं, आप देखेंगे कि वे अभी भी पृष्ठ को पुनः प्राप्त करेंगे और जोड़ देंगे। इसलिए मुझे लगता है कि एसपीए इस पर विचार करने से आगे बढ़ता है: क्या होगा यदि अजाक्स का उपयोग करने वाली सामग्री को पुनर्प्राप्त और प्रदर्शित किया जा रहा है? और सिर्फ एक पृष्ठ का एक छोटा सा हिस्सा नहीं है?

मुझे एक परिदृश्य प्रस्तुत करते हैं। विचार करें कि आपके पास 2 पृष्ठ हैं:

1. उत्पादों की सूची वाला एक पृष्ठ
2. किसी विशिष्ट उत्पाद का विवरण देखने के लिए एक पृष्ठ

विचार करें कि आप सूची पृष्ठ पर हैं। फिर आप विवरण देखने के लिए एक उत्पाद पर क्लिक करें। क्लाइंट साइड ऐप 2 अजाक्स अनुरोधों को ट्रिगर करेगा:

1. उत्पाद विवरण के साथ एक json वस्तु प्राप्त करने के लिए एक अनुरोध
2. एक HTML टेम्पलेट प्राप्त करने के लिए अनुरोध जहां उत्पाद विवरण डाला जाएगा

फिर, क्लाइंट साइड ऐप डेटा को html टेम्पलेट में डालेगा और प्रदर्शित करेगा।

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

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

इसके अलावा, आइए विचार करें कि आप सर्वर साइड भाषा जावा हैं। यदि आप मेरे द्वारा बताए गए 2 अनुरोधों का विश्लेषण करते हैं, तो 1 डाउनलोड डेटा (आपको किसी भी दृश्य फ़ाइल को लोड करने और व्यू रेंडरिंग इंजन को कॉल करने की आवश्यकता नहीं है) और अन्य डाउनलोड और स्थिर HTML टेम्पलेट ताकि आपके पास एक HTTP वेब सर्वर हो जो पुनः प्राप्त कर सके यह सीधे जावा एप्लिकेशन सर्वर पर कॉल किए बिना, कोई गणना नहीं की जाती है!

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

लेकिन अच्छे एसपीए डिजाइन पैटर्न का उपयोग करना महत्वपूर्ण है। आप AngularJS जैसे ढांचे का उपयोग कर सकते हैं। अच्छा डिज़ाइन पैटर्न का उपयोग किए बिना एसपीए को लागू करने का प्रयास न करें क्योंकि आप एक गड़बड़ हो सकते हैं।

Comments

फेसबुक एक एसपीए नहीं है, वास्तव में यह एक एमपीए शैली ऐप है, वे रिएक्टजेस का उपयोग यहां और वहां टिप्पणी, चैट आदि के लिए कर रहे हैं। इंस्टाग्राम पूर्ण स्पा पेज के लिए पीडब्ल्यूए सक्षम के साथ एक अच्छा उदाहरण है। Amazon, Youtube दोनों के लिए समान आवेदन MPA ऐप हैं।

— पीटर हुबेक

Answer 8

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

• क) सुरक्षा: पार साइट स्क्रिप्टिंग (XSS) के कारण पारंपरिक पृष्ठों की तुलना में एकल पृष्ठ अनुप्रयोग कम सुरक्षित है।
• बी) मेमोरी लीक: जावास्क्रिप्ट में मेमोरी लीक भी शक्तिशाली कंप्यूटर को धीमा करने का कारण बन सकता है। जैसा कि पारंपरिक वेबसाइटें पृष्ठों के बीच नेविगेट करने के लिए प्रोत्साहित करती हैं, इस प्रकार पिछले पृष्ठ के कारण होने वाली कोई भी स्मृति रिसाव लगभग कम अवशेषों को छोड़ देती है।
• c) क्लाइंट को स्पा चलाने के लिए जावास्क्रिप्ट को सक्षम करना होगा, लेकिन मल्टी-पेज एप्लिकेशन में जावास्क्रिप्ट को पूरी तरह से टाला जा सकता है।
• डी) एसपीए इष्टतम आकार में बढ़ता है, लंबे समय तक प्रतीक्षा का कारण बनता है। उदा: धीमे कनेक्शन के साथ जीमेल पर काम करना।

उपरोक्त के अलावा, अन्य वास्तुशिल्प सीमाएं हैं नेविगेशनल डेटा हानि, ब्राउज़र में नेविगेशनल इतिहास का कोई लॉग नहीं और सेलेनियम के साथ स्वचालित कार्यात्मक परीक्षण में कठिनाई।

यह लिंक सिंगल पेज एप्लीकेशन के फायदे और नुकसान की व्याख्या करता है।

Comments

यह गलत है। a) XSS सर्वर-जनरेट किए गए पेजों को उसी तरह प्रभावित करता है जैसे कि क्लाइंट पर उत्पन्न दस्तावेज। मैं मोरेसो का तर्क दूंगा, यह देखते हुए कि क्लाइंट पर बहुत सरल और प्रभावी एक्सएसएस शमन समाधान हैं। यदि आप XSS की अनुमति नहीं देना चाहते हैं, तो उपयोगकर्ता द्वारा प्रस्तुत सामग्री को HTML के रूप में व्याख्या न करें। कोई भी सभ्य प्रोग्रामर इसे संभाल सकता है। उपलब्ध तकनीकों (पुशस्टेट, हैश रूटिंग, आदि) में से किसी का उपयोग करके नेविगेशन आसान है। ठीक से निर्मित एसपीए के लिए एएफटी किसी भी अन्य वेब एप्लिकेशन के समान है। आपके उत्तर का सारांश यह है कि आप क्लाइंट के लिए निर्माण करना नहीं जानते हैं।

— जेसन मिलर

@ जैसनमिलर: सहमत। मुझे बस एहसास है कि सारांश पूरे ब्लॉग का संदर्भ नहीं है। मैं इसमें बदलाव करूंगा। धन्यवाद।

— विश

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

— गैरीप

Answer 9

अपने विकास में मैंने एसपीए का उपयोग करने के लिए दो अलग-अलग फायदे पाए। यह कहना नहीं है कि पारंपरिक वेब ऐप में निम्नलिखित हासिल नहीं किया जा सकता है, क्योंकि मुझे अतिरिक्त नुकसान शुरू किए बिना वृद्धिशील लाभ दिखाई देता है।

• नई सामग्री प्रदान करने के लिए कम सर्वर अनुरोध के लिए संभावित हमेशा या एक HTML HTML पृष्ठ के लिए http सर्वर अनुरोध नहीं है। लेकिन मैं कहता हूं कि संभावित है क्योंकि नई सामग्री को आसानी से डेटा में खींचने के लिए एक अजाक्स कॉल की आवश्यकता हो सकती है, लेकिन यह डेटा एक से अधिक लाभ प्रदान करने वाले प्लस मार्कअप की तुलना में आकस्मिक रूप से हल्का हो सकता है।

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

जेएस (जो वेब ऐप्स की आवश्यकता के लिए एक पागल चीज नहीं है) की आवश्यकता के अलावा अन्य उल्लेखनीय नुकसान मेरी राय में या तो एसपीए के लिए विशिष्ट नहीं हैं या अच्छी आदतों और विकास पैटर्न के माध्यम से कम किए जा सकते हैं।

Answer 10

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

1. यह एसपीए पर सत्र (और यह सुरक्षा है) को स्थानांतरित करेगा और आपके सर्वर को उस ओवरहेड से छुटकारा दिलाएगा।
2. आपका API स्थिर और आसानी से एक्स्टेंसिबल दोनों है।

पहले संकेत दिया, लेकिन स्पष्ट नहीं किया गया; यदि आपका लक्ष्य एंड्रॉइड और ऐप्पल एप्लिकेशन को तैनात करना है, तो एक जावास्क्रिप्ट एसपीए लिखना जो एक ब्राउज़र (एंड्रॉइड या ऐप्पल) में स्क्रीन को होस्ट करने के लिए एक देशी कॉल द्वारा लिपटा है, ऐप्पल कोड आधार और एंड्रॉइड कोड बेस दोनों को बनाए रखने की आवश्यकता को समाप्त करता है।

Answer 11

मैं समझता हूं कि यह एक पुराना सवाल है, लेकिन मैं सिंगल पेज एप्लिकेशन का एक और नुकसान जोड़ना चाहूंगा:

यदि आप एक एपीआई का निर्माण करते हैं जो डेटा भाषा (जैसे XML या JSON) के बजाय एक स्वरूपण भाषा (HTML) के रूप में परिणाम देता है, तो आप व्यापार-से-व्यापार (B2B) अनुप्रयोगों में, उदाहरण के लिए, अधिक से अधिक एप्लिकेशन इंटरऑपरेबिलिटी सक्षम कर रहे हैं। इस तरह की इंटरऑपरेबिलिटी के बहुत फायदे हैं लेकिन लोगों को आपके डेटा को "मेरा" (या चोरी करने) के लिए सॉफ्टवेयर लिखने की अनुमति देता है। यह विशेष रूप से नुकसान सभी एपीआई के लिए आम है जो डेटा भाषा का उपयोग करते हैं, और सामान्य रूप से एसपीए के लिए नहीं (वास्तव में, एक एसपीए जो प्री-रेंडर किए गए एचटीएमएल के लिए सर्वर से पूछता है, लेकिन यह खराब मॉडल / देखने के अलगाव की कीमत पर)। इस नुकसान से उजागर होने वाले जोखिम को विभिन्न तरीकों से कम किया जा सकता है, जैसे अनुरोध सीमित करना और कनेक्शन अवरुद्ध करना, आदि।

Comments

1.) एक एपीआई नहीं होने का मतलब यह नहीं है कि HTML पृष्ठों का खनन नहीं किया जा सकता है। 2.) आप कुछ हद तक अपने एपीआई के दुरुपयोग को रोक सकते हैं। 3.) एक एपीआई होने से, आप आसानी से न केवल वेब पेज बना सकते हैं, बल्कि इसके शीर्ष पर मोबाइल एप्लिकेशन भी बना सकते हैं, जो कि मेरी राय में किसी भी नुकसान को बहुत दूर करता है।

— होन्ज़ा कालफस '

1. मैंने यह नहीं कहा कि गैर-एपीआई डेटा माइनिंग को रोकता है। मैंने अभी कहा कि एक एपीआई डेटा माइनिंग को आसान बना सकता है। 2. यही मेरा आखिरी वाक्य है। 3. एपीआई होने के बहुत सारे फायदे हैं, और मैं आमतौर पर सबसे अधिक उपयोग होने वाले मामलों के लिए एपीआई / एसपीए संयोजन को व्यक्तिगत रूप से पसंद करता हूं। हालांकि, मैं सिर्फ सूची में एक ही नुकसान जोड़ना चाहता था (जो कि पूर्वव्यापी में मुझे पूर्ण उत्तर के बजाय एक टिप्पणी के रूप में जोड़ा जाना चाहिए)।

— मैगनस

क्षमा करें, लेकिन अगर मैंने गलत नहीं समझा है, तो आपने नहीं कहा, "इस तरह की इंटरऑपरेबिलिटी के बहुत फायदे हैं लेकिन लोगों को आपके डेटा को" मेरा "(या चोरी करने) के लिए सॉफ्टवेयर लिखने की अनुमति देता है।" अगर मैंने आपकी सजा को थोड़ा बदल दिया, तो मैं यह भी कह सकता हूं कि "वेबसाइटें लोगों को आपके डेटा को" मेरा "(या चोरी) करने के लिए सॉफ़्टवेयर लिखने की अनुमति देती हैं।" और सही हो। अब मैं यह नहीं कह रहा हूं कि आपका विचार गलत है, मैं खनन के आसान होने से सहमत हूं, मैं सिर्फ इतना कह रहा हूं कि यह आपने नहीं लिखा है;)

— होन्ज़ा कालफस

माना। यह पर्याप्त स्पष्ट नहीं था। HTML में एम्बेड किया गया डेटा देखने योग्य है। डाटा JSON / XML / आदि में एम्बेडेड भी mineable है, अब और भी आसान

— मैगनस