सर्वर-साइड पेज रेंडरिंग का उपयोग करके क्या फायदे हैं?

19

मैं एक वेब ऐप विकसित कर रहा हूं और मैंने वर्तमान में html / js / css में पूरी वेबसाइट लिखी है और बैकएंड पर मेरे पास सर्वलेट्स हैं जो कुछ RESTFUL सेवाओं की मेजबानी करते हैं। प्रस्तुति के सभी तर्क json ऑब्जेक्ट्स प्राप्त करने और जावास्क्रिप्ट के माध्यम से दृश्य को संशोधित करने के माध्यम से किया जाता है।

आवेदन अनिवार्य रूप से एक खोज इंजन है, लेकिन इसमें विभिन्न भूमिकाओं वाले उपयोगकर्ता खाते होंगे।

मैं प्ले और स्प्रिंग जैसे कुछ फ्रेमवर्क पर शोध कर रहा हूं। मैं वेब विकास के लिए काफी नया हूं, इसलिए मैं सोच रहा था कि सर्वर साइड पेज रेंडरिंग का उपयोग करने से क्या फायदे होंगे?

क्या यह है: गति? आसान विकास और कार्यप्रवाह? मौजूदा पुस्तकालयों तक पहुंच? अधिक? ऊपर के सभी?

javascript web-applications frameworks

— user1303881
स्रोत

4

सुरक्षा बड़ी है। विशेष रूप से जब एप्लिकेशन गतिशील होता है और डेटाबेस के साथ संवाद करने की आवश्यकता होती है।

— Oded

2

@Oded - जब आप पृष्ठ को API में रेंडर करते हैं तो सुरक्षा करना आसान क्यों होता है? मैंने हमेशा सोचा है कि आपको जो भी प्रोग्राम करना है, वह दोनों तरह से बराबर है, लेकिन यह आसान है (कम से कम मेरे लिए) मनोवैज्ञानिक रूप से याद रखें कि एपीआई करते समय क्लाइंट पर भरोसा न करें। मैं पूछ रहा हूँ क्योंकि अगर मैं कुछ ऐसा देख रहा हूँ जो मैं वास्तव में जानना चाहता हूँ।

— psr

1

@psr वह डेटा सिक्योरिटी का इतना जिक्र नहीं कर सकता जितना यूजर सिक्योरिटी (उदाहरण। MITM कारनामे) करता है। हालांकि सिर्फ एक अनुमान है।

— maple_shaft

1

@psr - सहमत। हालाँकि, कल ही मैंने एक सवाल का जवाब दिया था, जहाँ ओपी ने जेएस में कनेक्शन स्ट्रिंग को एम्बेड किया था ...

— Oded

1

@maple_shaft - MITM के बारे में सोचने के लिए कुछ है, लेकिन फिर से मुझे यकीन नहीं है कि यह एपीआई बनाम सर्वर से उत्पन्न HTML के लिए अंतर क्यों बनाता है। मुझे लगता है कि एक एपीआई के खिलाफ प्रोग्राम करने के लिए अधिक सुविधाजनक है, इसलिए यह थोड़ा आसान दरार होगा, लेकिन मुझे संदेह है कि आपका क्या मतलब है।

— पीएसआर

16

सर्वर-साइड HTML रेंडरिंग:

सबसे तेज़ ब्राउज़र रेंडरिंग
त्वरित और गंदे प्रदर्शन को बढ़ावा देने के रूप में पेज कैशिंग संभव है
"मानक" ऐप्स के लिए, कई यूआई सुविधाएँ पूर्व-निर्मित हैं
कभी-कभी अधिक स्थिर माना जाता है क्योंकि घटक आमतौर पर संकलन-समय सत्यापन के अधीन होते हैं
बैकएंड विशेषज्ञता पर झुकें
कभी-कभी * विकसित करने के लिए तेजी से

* जब यूआई की आवश्यकताओं को अच्छी तरह से रूपरेखा मिलती है।

क्लाइंट-साइड HTML रेंडरिंग:

कम बैंडविड्थ उपयोग
धीमी प्रारंभिक पृष्ठ प्रस्तुत करना। आधुनिक डेस्कटॉप ब्राउज़रों में भी ध्यान देने योग्य नहीं हो सकता है। यदि आपको IE6-7, या कई मोबाइल ब्राउज़रों (मोबाइल वेबकिट खराब नहीं है) का समर्थन करने की आवश्यकता है, तो आपको अड़चनें आ सकती हैं।
API- प्रथम का अर्थ है कि ग्राहक आसानी से एक मालिकाना ऐप, पतला ग्राहक, एक अन्य वेब सेवा, आदि हो सकता है।
जेएस विशेषज्ञता पर झूठ
कभी कभी तेजी से विकसित करने के लिए **

** जब यूआई काफी दिलचस्प बातचीत के साथ बड़े पैमाने पर कस्टम है। इसके अलावा, मुझे कंपाइलर्स और सर्वर रीस्टार्ट के इंतजार की तुलना में ब्राउज़र में कोडिंग की व्याख्या काफी तेज है।

मूंछ जैसे फ्रंट-एंड / बैक-एंड टेम्प्लेटिंग सिस्टम का उपयोग करके आप हल्के बैकएंड कार्यान्वयन के साथ एक हाइब्रिड मॉडल पर भी विचार कर सकते हैं ।

— peteorpeter
स्रोत

1

वाह, कैशिंग के अवसरों के बारे में पूरी तरह से भूल गया!

— माइकल के

"मानक" एप्लिकेशन के लिए, कई UI सुविधाएँ पूर्व-निर्मित हैं "यह अप्रासंगिक है, सर्वर और क्लाइंट दोनों के पास है।

— रेयानोस

@ रेयानोस ने क्लाइंट-साइड फ्रेमवर्क का उपयोग करने का उल्लेख नहीं किया था , लेकिन यदि वह एक का उपयोग कर रहा है, तो यह एक अच्छा बिंदु है।

— पीटोरिपेटर

1

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

— 191

मैं वास्तव में "क्लाइंट-साइड HTML रेंडरिंग" के लिए सूचीबद्ध किसी भी चीज को एक लाभ के रूप में नहीं मानूंगा। "कभी-कभी तेजी से विकसित करने के लिए" खिड़की से बाहर मक्खियों को एक बार खून बहाने वाले किनारे से अधिक ब्राउज़रों (आईई 8, आदि) माना जाता है।

— नल

3

सर्वर-साइड HTML पीढ़ी:

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

क्लाइंट-साइड HTML पीढ़ी:

डीबग करना कठिन;
अप्रचलित ब्राउज़रों के साथ कुछ मुद्दे;
HTML- टेम्प्लेट क्लाइंट-साइड को कैशिंग करने में कोई समस्या नहीं;
HTML- टेम्प्लेट और JS कोड के लिए कैशिंग-प्रॉक्सी और CDN का लाभ लेना;
बहुत कम नेटवर्क उपयोग;

ध्यान दें, क्लाइंट-साइड पीढ़ी वह तरीका है जो सफल मोबाइल साइटों के मामले में होता है, जैसा कि स्पष्ट रूप से यह आधुनिक ब्राउज़रों के साथ अधिक कुशल है (वेबकिट आधारित ब्राउज़रों का मोबाइल बाजार का लगभग 70-80% है)।

लिंक्डइन में डस्ट का उपयोग करके क्लाइंट-साइड अप्रोच के फायदों के बारे में लेख है। उदाहरण के तौर पर: " जेएसपी को धूल में छोड़ना: लिंक्डइन को धूल में बदलना। क्लाइंट-साइड टेम्प्लेट"

— vartec
स्रोत

1

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

— पेटीपीयर

1

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

अधिकांश वेब एप्लिकेशन डेटाबेस पर बहुत अधिक निर्भर करते हैं - उनमें से अधिकांश इतना अधिक है कि पेज कम से कम एक कॉल के बिना प्रस्तुत नहीं कर सकते। स्पष्ट रूप से आप कई कारणों से अपने डेटाबेस को सार्वजनिक रूप से उजागर नहीं करना चाहते:

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

इसलिए, जब आपको एक डेटाबेस की आवश्यकता होती है, तो आप उन भाषाओं का उपयोग करते हैं, जो उनके साथ अच्छा खेलती हैं जैसे जावा, सी #, पीएचपी, आदि। पेज बनाने का सबसे आसान तरीका निम्नानुसार है: आप एक अस्थायी भाषा (सबसे प्रसिद्ध PHP, का उपयोग करते हैं) पृष्ठ के निर्माण के लिए JSP और ASP दो अन्य बहुत ही सामान्य भाषाएं हैं)। भाषा अन्य मॉड्यूल को कॉल करने वाले निर्माण प्रदान करती है। PHP में यह आमतौर पर MVC पैटर्न का उपयोग करके पेज या किसी अन्य PHP फ़ाइल में होता है। JSP में आप स्क्रिप्टलेट या JSP एक्सप्रेशन लैंग्वेज का उपयोग करते हैं। ये अन्य मॉड्यूल डीबी से जुड़ने के भारी काम कर सकते हैं, तर्क का प्रदर्शन कर सकते हैं, और आपके दृश्य परत पर मूल्यों को वापस कर सकते हैं। अंतिम परिणाम एक उत्पन्न HTML पृष्ठ है, जो सर्वर पर प्रदान किया जाता है और क्लाइंट को भेजा जाता है।

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

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

— माइकल के
स्रोत

you can't write SQL in Javascript वास्तव में?! क्या आपने कभी जावास्क्रिप्ट के लिए StackOverflow प्रश्नों को देखा है? मैं दुर्भाग्य से अलग करने के लिए भीख माँगूँगा। दी यह एक सबसे बुरी बात आप संभवतः ... ग्राहक कोड में कर सकता है लेकिन है

— maple_shaft

... मैं भी Node.JS के बारे में भूल गया था, लेकिन फिर सर्वर जेएस जो पूरी तरह से एक पूरी तरह से अलग जानवर है।

— maple_shaft

जाहिर है आप कर सकते हैं - टीआईएल! बस ... वाह, हालांकि। हालांकि, भाषा के दुरुपयोग के बारे में बात करें!

— माइकल के

2

REST इंटरफ़ेस यह है कि क्लाइंट वर्तमान में डेटाबेस ऑब्जेक्ट को json ऑब्जेक्ट्स के माध्यम से कैसे एक्सेस करता है। यह सब कुछ उजागर नहीं करता है और यह एप्लिकेशन एक निजी उद्यम नेटवर्क का हिस्सा है। इंटरफेस का एक लाभ उद्यम में अन्य अनुप्रयोगों के लिए किसी भी सेवा का लाभ उठाने की क्षमता है जो वे चाहते हैं। विकास के नजरिए से, मैं फ्रंट एंड डेवलपर्स को html / js / css में कर सकता हूं और फिर वे जावा डेवलपर्स द्वारा डिज़ाइन किए गए Restful इंटरफ़ेस को बंद कर सकते हैं। हालांकि, हम में से अधिकांश के पास एक मिश्रित कौशल सेट है और यह विभाजन आवश्यक नहीं हो सकता है।

— user1303881

3

-1: @MichaelK: आप एक स्ट्रॉ-मैन के साथ चर्चा कर रहे हैं जिसकी आपने कल्पना की है, लेकिन वास्तविक जीवन से इसका कोई लेना-देना नहीं है। Restful HTTP का उपयोग करता है। JS में किसी को SQL लिखने की जरूरत नहीं है, यही Restful इंटरफ़ेस है। इसके अलावा रेस्टफुल का मतलब यह नहीं है कि डीबी प्रश्नों के साथ 1-टू -1 मैपिंग है। आपका उत्तर 1990 में मान्य हो सकता है, लेकिन अब हम 2012 में हैं।

— vartec

0

मोबाइल ग्राहक आमतौर पर शक्ति-, बैंडविड्थ- और मेमोरी-विवश होते हैं। सर्वर पर उनके लिए पृष्ठों को प्रस्तुत करना बेहतर है।

डेस्कटॉप क्लाइंट के लिए आप क्लाइंट पर पेज रेंडर करने के लिए js + json भेजने पर विचार कर सकते हैं, इसे गतिशील रूप से अपडेट करने योग्य बना सकते हैं, आदि।

— 9000
स्रोत

व्यवहार में हालांकि सटीक विपरीत अक्सर सच होता है। JQuery मोबाइल परियोजना, वास्तव में, पूरी तरह से क्लाइंट-साइड रेंडरिंग के विचार पर आधारित है।

— पॉइंटी

@ संकेत: हाँ, यह दूसरा तरीका हो सकता है। किसी को यह परीक्षण करना चाहिए कि विशेष क्लाइंट में विशेष पेज कैसे व्यवहार करते हैं। वैकल्पिक के लिए एक लिंक प्रदान करना (जैसे 'मोबाइल' और 'डेस्कटॉप' संस्करण लिंक) उपयोगकर्ता के लिए भी मददगार हो सकते हैं।

— 9000

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

— माइकल के

@ जॉइंट मोबाइल परियोजना भी भयानक कोड का एक बड़ा ढेर है जिसका उपयोग नहीं किया जाना चाहिए। लोकप्रियता! == मान

— Raynos

@Raynos हम वास्तव में बहुत अच्छी सफलता के साथ, Jquery मोबाइल का उपयोग कर रहे हैं। क्या आप जानते हैं कि हम कुछ नहीं करते हैं? ;)

— माइकल के

0

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

— व्याट बार्नेट
स्रोत

अच्छी बात है, हालांकि इस एप्लिकेशन को एसईओ की आवश्यकता नहीं है क्योंकि यह निजी है, मैं कुछ व्यक्तिगत ऐप भी विकसित कर रहा हूं और यह उस क्षेत्र में एक विचार है।

— user1303881

Googlebot काफी समय से JS / AJAX की व्याख्या करता है: searchenginewatch.com/article/2122137/…

— vartec

@vartec: मुझे लगता है कि उस लेख में मुख्य भावना "अब AJAX और जावास्क्रिप्ट के माध्यम से लागू किए गए कुछ गतिशील टिप्पणियों को पढ़ और समझ सकते हैं।" मेरा संदेह है कि यह डिस्कस और फेसबुक को कवर करता है लेकिन आपके कस्टम अजाक्स सेटअप को नहीं।

— वायट बार्नेट