क्लाइंट-साइड या सर्वर-साइड प्रोसेसिंग पर जोर देने के बीच पेशेवरों / विपक्ष

Question

मैं बहुत सारे प्रोसेसिंग सर्वर-साइड वाले वेब ऐप क्यों लिखना चाहूंगा?

मेरे लिए, प्रोग्राम क्लाइंट-साइड लिखना एक बहुत बड़ा लाभ है क्योंकि इसमें जितना संभव हो उतना सर्वर लोड होता है क्योंकि इसे केवल क्लाइंट को न्यूनतम प्रसंस्करण के साथ डेटा भेजना पड़ता है।

मैं इसे सर्वर-साइड लिखने और क्लाइंट-साइड को केवल एक दृश्य के रूप में मानने के अलावा वेब-एप्लिकेशन लिखने पर बहुत कम देखता हूं । मैं ऐसा क्यों करना चाहूंगा? मेरा एकमात्र फायदा यह है कि मैं जो भी भाषा में लिखना चाहता हूं ( http://www.paulgraham.com/avg.html ) लिख सकता हूं ।

Comments

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

— साकिन

डिबगिंग के बारे में सोचने का एक बिंदु, जो मेरी राय में आमतौर पर सर्वर पर अधिक आरामदायक है। वही लॉगिंग के लिए जाता है।

— त्रुबेनफुच्स

मैं इस बात से सहमत नहीं हूं कि वेब ऐप्स लिखना केवल सर्वर साइड को एक दृश्य भेजने के रूप में वर्णित किया गया है। क्लाइंट पर पूर्ण एप्लिकेशन बनाने और सर्वर के साथ केवल डेटा का आदान-प्रदान करने के लिए Vue, Angular आदि जैसे फ्रेमवर्क के बढ़ते हुए देखें।

— कुवेबल

Answer 1

दो प्रमुख मुद्दे हैं।

1. पहला आसान है - आप आमतौर पर यह नहीं जानते हैं कि क्लाइंट की तरफ किस तरह के संसाधन उपलब्ध हैं। यदि किसी चीज़ को संसाधित करने के लिए 1.5GB की आवश्यकता होती है, तो क्या आप वास्तव में एक अज्ञात क्लाइंट ब्राउज़र (IE, सफारी, ओपेरा, फ़ायरफ़ॉक्स, इत्यादि) को अज्ञात क्लाइंट प्लेटफ़ॉर्म पर धकेल सकते हैं? जब आप इसे बढ़ाते हैं तो क्या क्लाइंट उसके सिस्टम को डॉगिंग की सराहना करेगा?

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

Comments

परतों को छिपाने के लिए +1। एसक्यूएल इंजेक्शन दिमाग में आता है ...

— jmq

मुझे नहीं लगता कि SQL इंजेक्शन का आपके क्लाइंट के पक्ष में अधिकांश तर्क को ले जाने से कोई लेना-देना है। यहां तक ​​कि अगर आप डेटा प्रोसेसिंग को क्लाइंट-साइड पर ले जाते हैं, तो भी आपको कुछ प्रकार की सर्वर-साइड सेवा की आवश्यकता होती है, जो वास्तव में SQL क्वेरी चलाती है (जब तक कि आप अपने डेटाबेस उपयोगकर्ता नाम और पासवर्ड को सार्वजनिक नहीं करना चाहते)। यह सेवा डेटा को मान्य और भागने के लिए जिम्मेदार है। वहाँ कोई अंतर नहीं है - आप अपने सर्वर-साइड ALWAYS पर किसी भी इनपुट को मान्य और बचाना चाहिए। इसके आसपास कोई रास्ता नहीं है।

— पीजूस

Answer 2

सबसे पहले और सबसे महत्वपूर्ण है सुरक्षा । क्लाइंट के लिए अपने सभी तर्क को धक्का दें और हैकर्स और कारनामों के लिए यह उचित खेल है।

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

Comments

"ऊब" शायद एक अतिरंजना है। कई हैकर्स बस एक बिंदु बनाने के लिए या डेवलपर को मूर्ख बनाने के लिए हैक करते हैं। एक प्रकार का "आपका कोड खराब है, और आपको बुरा महसूस करना चाहिए" -mentality। यह कहते हुए कि हैक "बोरियत से बाहर" कभी नहीं होता है, लेकिन मुझे नहीं लगता कि यह बहुत आम है।

— मर मौस

@ जरारोड - क्या आप इस बात पर विस्तार से बता सकते हैं कि क्लाइंट-साइड पर लॉजिक को लागू करना आपके सुरक्षा बिंदु से कितना खराब है?

— सिंपल-सॉल्यूशन

@ सिंपल-सॉल्यूशन अगर आपको यह सवाल पूछना हो ...

Answer 3

क्लाइंट साइड बनाम सर्वर साइड

क्लाइंट साइड प्रोसेसिंग अधिक लोकप्रिय रीस्ट मानकों के साथ-साथ एमवीसी के साथ-साथ पेज आधारित दृष्टिकोण और एसओएपी के विपरीत है। इन रुझानों के उद्भव और AJAX और Html-RIA पर ध्यान केंद्रित, ग्राहक पक्ष पटकथा वृद्धि और अधिक लोकप्रिय है; हालाँकि, सुरक्षा चिंताओं और क्लाइंट क्षमता के कारण, क्लाइंट-साइड स्क्रिप्टिंग का एक विशेष स्थान है और इसका उपयोग हर चीज के लिए नहीं किया जाना चाहिए।

बातें:

मोबाइल

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

क्रॉस-ब्राउज़र की संगति

वेब मानक एक लंबा रास्ता तय कर चुके हैं और यह एक चिंता का विषय नहीं हो सकता है, लेकिन प्रत्येक वेब डेवलपर को पता है कि IE 6,7, और 8 और कभी-कभी सफारी क्लाइंट की तरफ से अजीब कार्य कर सकती है - कुछ कार्य इस वजह से नहीं चल सकते हैं गैर-कार्यान्वित मानकों के कारण सुरक्षा प्रतिबंध और अन्य। यह भी ध्यान रखना महत्वपूर्ण है कि अंतिम उपयोगकर्ता एक ब्राउज़र को कुछ प्रतिबंधों को कॉन्फ़िगर कर सकता है या यहां तक ​​कि क्लाइंट-साइड प्रोसेसिंग को बंद कर सकता है (कोई जावास्क्रिप्ट नहीं!)। यदि स्थिरता 100% उपयोगकर्ताओं के लिए एक आवश्यकता है (और विशेष रूप से यदि आप कुछ अपरंपरागत कर रहे हैं) तो सर्वर साइड सबसे महत्वपूर्ण है।

सुरक्षा

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

यूआई / UX

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

Answer 4

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

सर्वर यह नहीं मान सकता कि आपके अमीर / मजबूत ग्राहक ने डेटा भेजा है, इसलिए कुछ भी डेटा भेजे जाने के साथ, सर्वर को इसे सत्यापित करना होगा और प्रक्रिया करनी होगी। इसलिए इसे वहां लगाना समझ में आता है।

हालाँकि, मुझे लगता है कि बेहतर यूआई अनुभव के लिए क्लाइंट स्तर पर कुछ तर्क दिए जा सकते हैं।

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

यहाँ एक अच्छी लाइन है। साधारण सत्यापन तर्क ओके, कोर बिजनेस लॉजिक ओके नहीं।

Answer 5

1. सबसे पहले आपको वेब एप्लिकेशन की वास्तुकला को समझना होगा, सबसे ज्यादा अगर सभी 3-स्तरीय नहीं हैं:

   a) क्लाइंट / प्रेजेंटेशन - HTML और जावास्क्रिप्ट में ActiveX / Flash / Java Applets / Silverlight हो सकता है। मैं एक अंग पर निकलूंगा और मूल मोबाइल एप्लिकेशन जोड़ूंगा जो बैकएंड सर्वर के साथ संवाद करता है। मूल रूप से इस परत की भूमिका सिस्टम के उपयोगकर्ता के साथ बातचीत करने के लिए एक इंटरफ़ेस प्रदान करना है।

   b) बिजनेस लॉजिक - PHP / RoR / Java जहां क्लाइंट से डेटा एकत्र किया जाता है, प्रोसेस किया जाता है और स्टोर किया जाता है और जहां डेटा के लिए क्लाइंट रिक्वेस्ट को प्रोसेस करके क्लाइंट को वापस भेजा जाता है।

   ग) बैकेंड डेटा स्टोर - सिस्टम की जानकारी के लिए लगातार भंडारण प्रदान करता है

2. तो आप सभी परतों में सत्यापन कहां करते हैं। क्यों?

   क) ग्राहक पक्ष - सुनिश्चित करें कि उपयोगकर्ता सही डेटा, आवश्यक फ़ील्ड आदि में प्रवेश करता है

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

   ग) बैकेंड डेटा स्टोर - बाधाएं सुनिश्चित करती हैं कि डेटा भंडारण और बाद में पुनर्प्राप्ति के लिए अच्छी तरह से बना है।

इसलिए आप अपने सत्यापन के प्रयासों पर ध्यान केंद्रित करते हैं, उस सत्यापन को करने के लिए प्रत्येक परत का उपयोग करते हैं जो इसे सबसे अच्छा लगता है, और परत के लिए अधिक जटिल नियम छोड़ें जो इसे संभाल सकते हैं

Answer 6

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

Answer 7

जब आप अपना व्यवहार पूरी तरह से क्लाइंट साइड (जैसे जावास्क्रिप्ट के साथ) पर बनाते हैं, तो SEO एक समस्या बन सकती है।

वेवसुलेशन जो सर्वर साइड पर बहुत अधिक रखते हैं, वे एक विशिष्ट URL (आमतौर पर Restful) पर विशिष्ट सामग्री को पोस्ट करने के लिए आसानी से सक्षम होते हैं, इस तरह से खोज इंजन के लिए दिखाई देता है।

इसका मतलब यह भी है कि एक आगंतुक एक विशिष्ट पृष्ठ को बुकमार्क कर सकता है। क्या आपने फेसबुक पर कोशिश की है?

इस सामान को हल किया जा सकता है, लेकिन यह आमतौर पर उन एप्लिकेशन में बनाया जाता है जो सर्वर (रीलों, वर्डप्रेस आदि) पर बहुत कुछ करते हैं, जबकि अगर आप REACT में कह रहे हैं, तो आपको हुप्स के माध्यम से कूदना होगा।

Answer 8

इसका कारण स्थिरता है ।

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

जब भी मैं जावा को एक नए संस्करण में अपडेट करता हूं, यह आमतौर पर अच्छी तरह से काम करता है क्योंकि जावा प्रमुख संस्करण अपडेट में भी एक अत्यंत स्थिर घटक है। और यह भी, मेरे पास मौजूद हर सर्वर एक ही जावा संस्करण चला रहा है। प्रत्येक क्लाइंट समान जावास्क्रिप्ट कार्यान्वयन नहीं चला रहा है।

क्लाइंट की ओर, मैं स्थिर घटकों का चयन नहीं कर सकता। ब्राउज़र निर्माता मुझे जावास्क्रिप्ट का चयन करने के लिए मजबूर करेंगे, एक ऐसी भाषा जो मुझे विशेष रूप से पसंद नहीं है, लेकिन एक जिसे मैं उपयोग करने के लिए मजबूर हूं। (और मुझे उन भाषाओं के बारे में न बताएं जो जावास्क्रिप्ट में संकलित हैं, वे भयानक हैं!) हर ब्राउज़र का जावास्क्रिप्ट कार्यान्वयन अलग है। इसका मतलब यह है कि यह कुल समर्थित नरक संस्करण के साथ मेरे उत्पाद का परीक्षण करने के लिए एक कुल नरक है।

मेरा हल? मैं सर्वर की ओर से जितनी प्रोसेसिंग कर सकता हूं, करता हूं, और क्लाइंट साइड केवल एक हल्का आवरण है, जो सर्वर को डेटा भेजता है और JSON और HTML टुकड़े के रूप में सर्वर से डेटा प्राप्त करता है। XML से बचें; इसके बजाय JSON का उपयोग करें।

मैं क्लाइंट-साइड टेंपलेटिंग नहीं करता; मैं सर्वर पर एक HTML टुकड़ा करने के लिए सामग्री है कि मैं तो .innerHTMLग्राहक पक्ष पर विभिन्न प्लेसहोल्डर तत्वों के लिए विशेषता का उपयोग सौंपना । यह प्रौद्योगिकी को यथासंभव सरल रखता है, क्योंकि मुझे दो टेम्पलेट इंजन (एक जावा एक और एक जावास्क्रिप्ट) की आवश्यकता नहीं है।

दोष स्पष्ट रूप से प्रकाश की विलंबता है; महाद्वीपों के बीच विलंबता का आधा सेकंड असामान्य नहीं है।

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

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