क्या बैकएंड को वेब एप्लिकेशन को पूरी तरह से डिकम्पोज करना और उन्हें (JSON) REST API के साथ संवाद करने की अनुमति देना सामान्य डिजाइन है?

मैं नया व्यवसाय वेब एप्लिकेशन बना रहा हूं और मैं इसे प्राप्त करना चाहता हूं:

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

इसलिए - दोनों आवश्यकताओं को पूरा करने के लिए मैं बैकएंड और फ्रंटएंड एप्लिकेशन में अपने एप्लिकेशन को पूरी तरह से अलग करने के लिए इच्छुक हूं और REST API (JSON) का उपयोग करके उनके बीच संचार को व्यवस्थित कर सकता हूं। क्या यह ध्वनि दृष्टिकोण है?

इस तरह की जुदाई स्पष्ट डिजाइन समाधान नहीं है, क्योंकि कई वेब अनुप्रयोग तकनीकों में एकीकृत दृश्य परतें हैं जहां सर्वर साइड अनुप्रयोग दृश्य की पीढ़ी को कम या ज्यादा नियंत्रित करता है और दृश्य से प्रतिक्रियाओं को आंशिक रूप से संभालता है (उदाहरण के लिए दृश्य परत के साथ स्प्रिंगएमवीसी, PHP Yii दृश्य के साथ परत, जावा JSF / फेसलेट पूरी तरह से सर्वर पर उनके घटकों की स्थिति को बचाता है)। इसलिए - ऐसी कई प्रौद्योगिकियां हैं जो अधिक मजबूत युग्मन का प्रस्ताव देती हैं और तेजी से विकास के समय और अधिक मानक पथ यात्रा का वादा करती हैं। इसलिए - जब तकनीक का व्यापक रूप से उपयोग नहीं किया जाता है, तो इसका उपयोग शुरू करते समय मुझे सतर्क रहना चाहिए।

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

वर्तमान में मेरी पसंद की तकनीक जावा / स्प्रिंग बैकएंड और एंगुलर 2 / वेब कंपोनेंट्स / पॉलिमर फॉर फ्रंटेंड है - अगर मुझे यह कहने की अनुमति है। लेकिन यह इस सवाल के लिए अप्रासंगिक है, क्योंकि यह सवाल सामान्य डिजाइन के बारे में है न कि ठोस प्रौद्योगिकियों के विकल्प के बारे में?

— श्रीमान को
स्रोत

(1)। हाँ। इस तरह से जाने के लिए अब एक दिन सामान्य है।

— 13

(2)। So - I must be cautious when starting to use technologies in manner which is not widely used.हां, आपको सतर्क रहना चाहिए अगर आप रेशम को पिच करने के लिए हथौड़ा का उपयोग करने की योजना बना रहे हैं। शायद यह सही उपकरण नहीं है।

— Laiv

विदित हो कि इस तरह के कठोर तरीके से डिकॉय करने से विकास की महत्वपूर्ण लागत में वृद्धि होती है। आपको उससे कुछ ठोस मूल्य प्राप्त करने की आवश्यकता है।

— यूएसआर

यह भी ध्यान दें कि आप कभी भी अपने डोमेन को सीधे ब्राउज़र में उजागर नहीं कर सकते हैं। यह सुरक्षा समस्याएँ पैदा करता है और डेटा को प्रदर्शन के लिए उपयुक्त रूप से प्रारूपित नहीं किया जाएगा। आपको केवल कॉल करने के लिए जावास्क्रिप्ट के लिए एक विशेष उद्देश्य (REST) इंटरफ़ेस बनाना होगा। और वह कपल है।

— यूएसआर

स्प्रिंग में एनोटेशन PathVariable, ResponseBody, RequestBody और RestController है (आपको उनकी जांच करनी चाहिए)। वे अजाक्स आधारित JSON / REST वेब अनुप्रयोगों को बहुत, बहुत आसान विकसित कर रहे हैं, जो स्प्रिंग को एसपीए के लिए एक महान बैकएंड बनाता है। मेरा दृढ़ता से मानना है कि इस तरह से फ्रंटएंड और बैकएंड को अलग करना बेहतर विकल्प है: क्लासिकल जेएसएफ अनुप्रयोगों में मुझे काम करने में "खुशी" होती थी।

— Traubenfuchs

जवाबों:

क्या बैकएंड को वेब एप्लिकेशन को पूरी तरह से डिकम्पोज करना और उन्हें (JSON) REST API के साथ संवाद करने की अनुमति देना सामान्य डिजाइन है?

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

एक एसपीए इसके साथ जुड़े कुछ मुद्दों के साथ आता है। यहाँ अब मेरे दिमाग में कुछ पॉप हैं:

यह ज्यादातर जावास्क्रिप्ट है। आपके एप्लिकेशन के किसी सेक्शन में एक त्रुटि, उस जावास्क्रिप्ट त्रुटि के कारण काम करने के लिए एप्लिकेशन के अन्य अनुभागों को रोक सकती है। सर्वर (स्प्रिंगएमवीसी, पीएचपी, आदि) से प्राप्त पृष्ठों के साथ आप एक नए अनुभाग को पुनः लोड करते हैं;
कोर । अनिवार्य रूप से अनिवार्य नहीं है, लेकिन अक्सर बैक-एंड फ्रंट-एंड की तुलना में एक अलग डोमेन नाम पर है। तो अब आपको ब्राउज़र सुरक्षा मुद्दों से निपटना होगा;
एसईओ । क्या आपको इसकी जरूरत है? क्या आपकी साइट सार्वजनिक है? Google जावास्क्रिप्ट को समझ सकता है और आपकी साइट से समझ बनाने की कोशिश कर सकता है, लेकिन आप मूल रूप से एक बॉट को नियंत्रण देते हैं और सर्वश्रेष्ठ के लिए आशा करते हैं। नियंत्रण वापस लेने का मतलब हो सकता है कि PhantomJS जैसे अन्य उपकरणों पर भरोसा करना ।
अलग-अलग फ्रंट-एप्लिकेशन का अर्थ है अलग-अलग प्रोजेक्ट, परिनियोजन पाइपलाइन, अतिरिक्त टूलिंग, आदि;
जब ग्राहक सभी कोड पर होता है, तो सुरक्षा कठिन होती है;

यकीन है, वहाँ भी एसपीए लाभ हैं:

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

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

— Bogdan
स्रोत

"सभी क्लाइंट पर कोड होने पर सुरक्षा करना कठिन है;" एहम, एक बड़ा फायदा यह है कि इसके विपरीत, सुरक्षा करना आसान है, क्योंकि एक बहुत ही स्पष्ट परत है जिसे आपको सुरक्षित करना है जो तार्किक और आसान तरीके से समझने के लिए डिज़ाइन किया गया है।

— डेविड मुलदर

@DavidMulder: स्पष्ट परत सुरक्षा के साथ करना बिल्कुल कठिन है, लेकिन सही तरीके से करना आसान है। एक स्पष्ट विभाजन के बिना आप कुछ ऐसा कर सकते हैं जो प्रशंसनीय है, लेकिन बिना किसी समय के बगल में गलत है ;-)

— स्टीव जेसोप

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

— samazi
स्रोत

कैविट्स के साथ सामान्य।

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

इसलिए 'सामान्य' वास्तुकला हो सकता है:

database
business logic services (dll)
api exposing business logic
server side website exposing viewmodels and functionality via json rest endpoints
client side javascript implementing ui

अब यदि आपके पास केवल एक वेब एप्लिकेशन है तो आप 'एपीआई एक्सपोजिंग बिजनेस लॉजिक' लेयर को काट सकते हैं और सर्वर साइड वेब कोड को सीधे बिजनेस लॉजिक को कॉल कर सकते हैं।

क्योंकि आपने व्यावसायिक लॉजिक को अपनी लाइब्रेरी में अलग कर लिया है, फिर भी यह यूआई लॉजिक से अलग हो गया है और आप हमेशा बाद में सर्विस लेयर जोड़ सकते हैं।

इसी तरह, क्योंकि एपीआई सेवा को सर्वर साइड कोड कहा जाता है, आप सीमित संचार नहीं हैं। (हालांकि यह अब बहुत अधिक सार्वभौमिक है)

इसके अलावा, जावास्क्रिप्ट एक ही मेजबान है कि इसकी सेवा से मतलब है कि आप cors के साथ चारों ओर चकमा नहीं है बुला रहा है

— ईवान
स्रोत