ग्राफकॉल और माइक्रोसर्विस आर्किटेक्चर

Question

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

केवल 1 ग्राफ़कॉल स्कीमा होने के बारे में कुछ बहस है जो एपीआई गेटवे के रूप में काम करती है जो लक्षित माइक्रोसर्विस के अनुरोध को आगे बढ़ाती है और उनकी प्रतिक्रिया का जोर देती है। माइक्रोसॉफ़्ट अभी भी संचार विचार के लिए REST / Thrift प्रोटोकॉल का उपयोग करेंगे।

इसके बजाय एक अन्य दृष्टिकोण है कि कई ग्राफकॉल स्कीमास एक माइक्रोसर्विस के लिए है। एक छोटा एपीआई गेटवे सर्वर है जो अनुरोध के सभी सूचनाओं के साथ लक्षित माइक्रोसर्विस + ग्राफक्लाइन क्वेरी को रूट करता है।

1 दृष्टिकोण

एपीआई गेटवे के रूप में 1 ग्राफक्यूएल स्कीमा रखने से एक नकारात्मक पहलू यह होगा कि हर बार जब आप अपना माइक्रोसर्विस कॉन्ट्रैक्ट इनपुट / आउटपुट बदलते हैं, तो हमें एपीआई गेटवे साइड के अनुसार ग्राफक्यूला स्कीमा बदलना होगा।

दूसरा दृष्टिकोण

यदि माइक्रोसर्विसेज में मल्टीपल ग्रेफ्लिका स्कीमा का उपयोग किया जाता है, तो एक तरह से समझ में आता है क्योंकि ग्राफकॉल एक स्कीमा परिभाषा को लागू करता है, और उपभोक्ता को माइक्रोसेवेअर से दिए गए इनपुट / आउटपुट का सम्मान करना होगा।

प्रशन

• क्या आप माइक्रोसेल आर्किटेक्चर को डिजाइन करने के लिए सही फिट ग्राफ़िकल को पाते हैं?

• आप एक संभावित ग्राफकॉल कार्यान्वयन के साथ एपीआई गेटवे कैसे डिजाइन करेंगे?

Answer 1

निश्चित रूप से # 1 से संपर्क करें।

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

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

GraphQL और microservices एक आदर्श फिट हैं, क्योंकि GraphQL इस तथ्य को छुपाता है कि आपके पास क्लाइंट्स से एक microservice आर्किटेक्चर है। बैकएंड के नजरिए से, आप सब कुछ माइक्रोसर्विसेज में विभाजित करना चाहते हैं, लेकिन फ्रंटएंड के नजरिए से, आप चाहेंगे कि आपका सारा डेटा सिंगल एपीआई से आए। GraphQL का उपयोग करना सबसे अच्छा तरीका है जो मुझे पता है कि आप दोनों को करते हैं। यह आपको अपने बैकएंड को माइक्रोसर्विसेज में विभाजित कर देता है, जबकि अभी भी आपके सभी एप्लिकेशन को एक ही एपीआई प्रदान करता है, और विभिन्न सेवाओं में डेटा में शामिल होने देता है।

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

Comments

@ संदर्भ: यह वास्तव में समझ में आता है :) धन्यवाद। इस भव्य उत्तर के शीर्ष पर मेरे कुछ सवाल हैं। - आप कह रहे हैं कि ग्राफकॉल का उपयोग एपीआई गेटवे के रूप में किया जाना है? - मान लें कि मेरे पास एक ऑर्डर माइक्रोसर्विस है जो या तो एक REST या ग्राफकॉल एंड पॉइंट को उजागर करता है। एक बार जब मैं इसके साथ समाप्त हो जाता हूं तो मुझे उसी डेटा को प्रतिबिंबित करने के लिए मुख्य ग्राफ़कॉल स्कीमा को अपडेट करना होगा जो कि माइक्रोसैस सर्विस को उजागर करेगा? क्या यह दोहराव या सूक्ष्म संस्कृति से दूर जाना नहीं है जिसे स्वतंत्र रूप से तैनात किया जाना चाहिए? एक microservice में किसी भी परिवर्तन को प्रतिबिंबित / मुख्य रेखांकन स्कीमा के लिए दोहराया जाना है?

— Fabrizio Fenoglio

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

— Helfer

सही! :) यह लिखने के लिए धन्यवाद! मैं अपोलो रेपो के माध्यम से और गितुब पर आपका अनुसरण कर रहा हूँ! आपके लेख और पोस्ट बहुत मूल्यवान हैं! :) अच्छा काम करते रहें! मुझे यह भी लगता है कि विषय के साथ एक मध्यम लेख ग्राफक्लाइन + माइक्रोसर्विसेज पढ़ने के लिए बहुत ही सुखद होगा!

— फाब्रीजियो फेनोग्लियो

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

— हेल ​​करें

विकल्प # 2 और github.com/AEB-labs/graphql-weaver के संयोजन के बारे में कैसे ?

— मोहसिन

Answer 2

यहां लेख देखें , जो कहता है कि कैसे और क्यों दृष्टिकोण # 1 बेहतर काम करता है। नीचे दिए गए लेख से ली गई छवि को भी देखें:

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

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

निम्नलिखित लेख दूसरों के साथ इन दो लाभों को बहुत अच्छी तरह से समझाता है: https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/

Comments

HI, noob प्रश्नों के लिए खेद है, लेकिन क्या आपका ग्राफकॉल गेटवे एक नया अवधारण बिंदु नहीं है? उदाहरण के लिए, अगर मेरे पास एक टोकरी सेवा है जो अचानक से अधिक है, तो क्या मेरा ग्राफकॉल प्रवेश द्वार भी नहीं टूटेगा? मूल रूप से मुझे इसकी भूमिका पर यकीन नहीं है, इस प्रवेश द्वार में प्रत्येक सेवा के लिए बहुत सारे रिज़ॉल्वर होने चाहिए?

— एरिक ब्यूरेल

@ EricBurel प्रश्न के लिए धन्यवाद। दरअसल, जहां तक ​​मैंने लेख से समझा है, विभिन्न सेवाओं से सभी स्कीमा एक ग्राफक्यूएल स्कीमा के तहत एकीकृत होते हैं, इसलिए जैसा कि आपने उल्लेख किया है, अन्य सेवाएं अभी भी अपने डेटासेट पर रहती हैं। ग्राफकॉल गेटवे के लिए एकल स्रोत की विफलता की संभावना के संबंध में, हमेशा अन्य विकल्प होते हैं जैसे बैकअप योजना प्रदान करना। अधिक जानकारी के लिए कृपया इस लेख ( labs.getninjas.com.br/… ) को पढ़ें। उम्मीद है की यह मदद करेगा।

— इनायत

आप केंद्रीय एपीआई गेटवे और व्यक्तिगत सेवाओं का परीक्षण कैसे करते हैं? क्या आप एकीकरण कर रहे हैं या http प्रतिक्रिया का मजाक उड़ा रहे हैं?

— Jaime Sangcap 16

Answer 3

# 2 दृष्टिकोण के लिए, वास्तव में यही तरीका है जो मैं चुनता हूं, क्योंकि यह कष्टप्रद एपीआई गेटवे को मैन्युअल रूप से बनाए रखने की तुलना में बहुत आसान है। इस तरह से आप अपनी सेवाओं को स्वतंत्र रूप से विकसित कर सकते हैं। जीवन को बहुत आसान बनाएं: पी

स्कीमा को एक में संयोजित करने के लिए कुछ महान उपकरण हैं, उदाहरण के लिए ग्राफक्वल-जुलाहा और अपोलो के ग्राफकल-उपकरण , मैं उपयोग कर रहा हूं graphql-weaver, यह उपयोग करना आसान है और महान काम करता है।

Comments

Android में GraphQL का उपयोग करना अनिवार्य है कि मैं सभी प्रश्नों के साथ एक .graphql फ़ाइल बनाऊँ? या मैं इस फाइल के बिना उन्हें कोड में बना सकता हूं?

— मौरोलेक्सैंड्रो

@MauroAlexandro मैं एक एंड्रॉइड आदमी नहीं हूं, लेकिन आपके पास अलग-अलग फ़ाइलों में प्रश्न हो सकते हैं। यह एक डिजाइन समस्या अधिक है। IMHO, मैं पहले एक को पसंद करता हूं :)

— HFX

Answer 4

2019 के मध्य में 1 दृष्टिकोण के लिए समाधान का नाम अब " स्कीमा फेडरेशन " रखा गया है जो अपोलो लोगों द्वारा गढ़ा गया था (पहले यह अक्सर ग्राफक्यूएल सिलाई के रूप में जाना जाता था)। वे मॉड्यूल @apollo/federationऔर इसके @apollo/gatewayलिए भी प्रस्ताव करते हैं ।

जोड़ें: कृपया ध्यान दें कि स्कीमा फेडरेशन के साथ आप गेटवे स्तर पर स्कीमा को संशोधित नहीं कर सकते हैं। इसलिए आपको अपने स्कीमा में प्रत्येक बिट के लिए, आपको एक अलग सेवा की आवश्यकता होगी।

Comments

यह जानना भी मान्य है कि यह समाधान अपोलो सर्वर की मांग करता है जो कि मुफ्त संस्करण में थोड़ा सीमित है (प्रति माह अधिकतम 25 मिलियन प्रश्न)

— मार्क्स

Answer 5

2019 तक सबसे अच्छा तरीका यह है कि आप माइक्रोस्लाइज़ को लिखें जो अपोलो गेटवे विनिर्देश को लागू करता है और फिर इन सेवाओं को एक गेटवे निम्नलिखित दृष्टिकोण # 1 का उपयोग करके एक साथ गोंद करता है। प्रवेश द्वार का निर्माण करने का सबसे तेज़ तरीका इस तरह की एक डॉकटर छवि है फिर सभी सेवाओं को समवर्ती शुरू करने के लिए डॉक-कंपोज़ का उपयोग करें:

version: '3'

services:
    service1:
        build: service1
    service2:
        build: service2
    gateway:
        ports:
            - 80:80
        image: xmorse/apollo-federation-gateway
        environment: 
            - CACHE_MAX_AGE=5
            - "FORWARD_HEADERS=Authorization, X-Custom-Header" # default is Authorization, pass '' to reset
            - URL_0=http://service1
            - URL_1=http://service2

Answer 6

इस प्रश्न में जिस तरह से इसका वर्णन किया जा रहा है, मेरा मानना ​​है कि ऑर्केस्ट्रेशन सेवा के रूप में एक कस्टम एपीआई गेटवे का उपयोग करना जटिल उद्यम केंद्रित अनुप्रयोगों के लिए बहुत कुछ समझ सकता है। ग्राफ़कॉक उस ऑर्केस्ट्रेशन सेवा के लिए एक अच्छा प्रौद्योगिकी विकल्प हो सकता है, जहां तक ​​कम से कम क्वेरीज़ जाती हैं। आपके पहले दृष्टिकोण का लाभ (सभी माइक्रोसर्विसेज के लिए एक स्कीमा) एक ही अनुरोध में कई माइक्रोसेरवियर्स से डेटा को एक साथ सिलाई करने की क्षमता है। आपकी स्थिति के आधार पर यह बहुत महत्वपूर्ण हो सकता है या नहीं भी हो सकता है। यदि GUI एक साथ कई माइक्रोसिस्टर्स से डेटा रेंडर करने के लिए कहता है, तो यह दृष्टिकोण क्लाइंट कोड को सरल बना सकता है जैसे कि एक सिंगल कॉल डेटा को लौटा सकता है जो GUI के एंगुलर या रिएक्ट जैसे फ्रेमवर्क के डेटा बाइंडिंग के लिए उपयुक्त है। यह लाभ म्यूटेशन के लिए लागू नहीं होता है।

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

ग्राफ्सेल बनाम आरईएसटी की इस तुलना में आप पाएंगे कि ग्राफकॉल, रेस्टफुल एपीआई के समान कुशल नहीं है, इसलिए मैं डेटा एपीआई के लिए ग्राफक के साथ आरईएसटी को बदलने की सिफारिश नहीं करूंगा।

Answer 7

1 सवाल करने के लिए, इंटुइट ने कुछ साल पहले ग्राफक्यूएल की शक्ति को स्वीकार किया जब उसने एक इंटुइट एपीआई पारिस्थितिक तंत्र ( https://www.slideshare.net/IntuitDeveloper/building-the-next-generation-of-quickbooks-app-integrations) पर जाने की घोषणा की -क्विकबुक-कनेक्ट-2017 )। Intuit ने दृष्टिकोण के साथ जाना चुना। आपके द्वारा उल्लिखित खामी वास्तव में डेवलपर्स को टूटने वाले स्कीमा परिवर्तनों को पेश करने से रोकती है जो संभावित रूप से ग्राहक अनुप्रयोगों को बाधित कर सकते हैं।

GraphQL ने कई तरीकों से डेवलपर्स की उत्पादकता में सुधार करने में मदद की है।

1. एक डोमेन के लिए एक नया माइक्रोसैस डिजाइन करते समय, इंजीनियर (बैकेंड / फ्रंटेंड / स्टेकहोल्डर) डोमेन एंटिटी के लिए स्कीमा पर सहमत होते हैं। स्कीमा के स्वीकृत होने के बाद, इसे मास्टर डोमेन स्कीमा (सार्वभौमिक) के साथ विलय कर दिया जाता है और गेटवे पर तैनात किया जाता है। अंत में इंजीनियर इस स्कीमा के साथ क्लाइंट एप्लिकेशन को कोड करना शुरू कर सकते हैं, जबकि बैकेंड इंजीनियर कार्यक्षमता को लागू करते हैं। एक सार्वभौमिक स्कीमा होने का अर्थ है कि निरर्थक कार्यक्षमता के साथ कोई दो माइक्रोसेवा नहीं हैं।

2. GraphQL ने क्लाइंट एप्लिकेशन को सरल और तेज़ बनने में मदद की है। डेटा को / से अपडेट करने के लिए डेटा को कई microservices में लाना चाहते हैं? सभी क्लाइंट एप्लिकेशनों को एक आग का गोला अनुरोध करना पड़ता है और एपीआई गेटवे एब्स्ट्रेक्शन लेयर को कई स्रोतों (माइक्रोसर्विस) से डेटा प्राप्त करने और समेटने के लिए ध्यान रखना होगा। अपोलो ( https://www.apollographql.com/ ) जैसे ओपन सोर्स फ्रेमवर्क ने ग्राफकॉल को अपनाने की गति को तेज कर दिया है।

3. आधुनिक अनुप्रयोगों के लिए मोबाइल पहली पसंद होने के साथ, ग्राउंड ज़ीरो से कम डेटा बैंडविड्थ आवश्यकताओं के लिए डिज़ाइन करना महत्वपूर्ण है। GraphQL केवल विशिष्ट क्षेत्रों के लिए ग्राहक एप्लिकेशन को अनुरोध करने की अनुमति देकर मदद करता है।

प्रश्न 2: हमने एपीआई गेटवे पर एक कस्टम अमूर्त परत का निर्माण किया है जो जानता है कि स्कीमा का कौन सा हिस्सा किस सेवा (प्रदाता) के स्वामित्व में है। जब एक क्वेरी अनुरोध आता है, अमूर्त परत उपयुक्त सेवा (ओं) के लिए अनुरोध को आगे बढ़ाती है। एक बार जब अंतर्निहित सेवा प्रतिक्रिया वापस कर देती है, तो एब्स्ट्रैक्शन परत अनुरोधित फ़ील्ड को वापस करने के लिए ज़िम्मेदार होती है।

हालाँकि, आज वहाँ कई प्लेटफ़ॉर्म हैं (अपोलो सर्वर, ग्राफकल-योगा, आदि) जो किसी भी समय में एक ग्राफकॉल एब्स्ट्रक्शन लेयर बनाने की अनुमति देते हैं।

Answer 8

मैं GraphQL और microservices के साथ काम कर रहा हूँ

मेरे अनुभव के आधार पर, मेरे लिए जो काम करता है, वह कार्यक्षमता / उपयोग के आधार पर दोनों दृष्टिकोणों का एक संयोजन है, मेरे पास कभी भी एक गेटवे नहीं होगा जैसा कि दृष्टिकोण 1 में है ... लेकिन दृष्टिकोण 2 के रूप में प्रत्येक माइक्रोसर्विस के लिए ग्राफिकल को नापें।

उदाहरण के लिए, एनैयट के उत्तर की छवि के आधार पर, इस मामले में मैं क्या करूंगा कि 3 ग्राफ गेटवे हैं (छवि में 5 नहीं)

• ऐप (उत्पाद, टोकरी, शिपिंग, इन्वेंटरी, अन्य सेवाओं से जुड़ी / आवश्यक)

• भुगतान

• उपयोगकर्ता

इस तरह आपको जरूरत से ज्यादा सेवाओं से जुड़े / जुड़े न्यूनतम डेटा के डिजाइन पर अतिरिक्त ध्यान देना होगा, जैसे कि एक टोकन, उपयोगकर्ता, भुगतान, भुगतान की स्थिति

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

यह रास्ता आसान है ...

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

• एक बार गेटवे परिपक्व होने के बाद, बढ़ता है, उपयोग ज्ञात होता है या आपके पास उस डोमेन पर अधिक विशेषज्ञता होती है जिसे आप पहचान सकते हैं कि स्कीमा का कौन सा हिस्सा हो सकता है जो उनके पास स्वयं का गेटवे हो सकता है (... मेरे साथ एक विशाल स्कीमा है जो गिट रिपॉजिटरी के साथ बातचीत करता है। , मैंने गेटवे को अलग कर दिया जो एक रिपॉजिटरी के साथ बातचीत करता है और मैंने देखा कि केवल इनपुट की जरूरत थी / लिंक की गई जानकारी थी ... फ़ोल्डर पथ और अपेक्षित डेटा)

• आपके द्वारा रिपॉजिटरी का इतिहास अधिक स्पष्ट है और आपके पास एक गेटवे और इसके शामिल परिसीमन के लिए समर्पित रिपॉजिटरी / डेवलपर / टीम हो सकती है।

अपडेट करें:

मेरे पास एक kubernetes क्लस्टर ऑनलाइन है जो उसी दृष्टिकोण का उपयोग कर रहा है जिसे मैं यहां सभी बैकएंड के साथ वर्णन करता हूं ग्राफकॉक, सभी ओपनसोर्स का उपयोग कर रहा हूं, यहां मुख्य रिपॉजिटरी है: https://github.com/vicjicaman/microservice-realm

यह मेरे उत्तर के लिए एक अद्यतन है क्योंकि मुझे लगता है कि यह बेहतर है यदि उत्तर / दृष्टिकोण बैकअप कोड है जो चल रहा है और परामर्श / समीक्षा की जा सकती है, मुझे आशा है कि यह मदद करता है।

Answer 9

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

Comments

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

— रॉय

Answer 10

Microservices के बारे में अधिक, मुझे लगता है कि रेखांकन भी सर्वर रहित वास्तुकला में सही काम कर सकता है। मैं GraphQL का उपयोग नहीं करता हूं, लेकिन मेरी अपनी समान परियोजना है । मैं इसे एक एग्रीगेटर के रूप में उपयोग करता हूं जो एक ही परिणाम में कई कार्यों को आह्वान और ध्यान केंद्रित करता है। मुझे लगता है कि आप रेखांकन के लिए एक ही पैटर्न लागू कर सकते हैं।

Comments

क्षमा करें, लेकिन यह ओपी के प्रश्न के लिए बिल्कुल भी प्रासंगिक नहीं है। सवाल दो विशिष्ट दृष्टिकोणों के बारे में है जिसका उपयोग ग्राफकॉल करता है। यह एक टिप्पणी के रूप में बेहतर हो सकता है।

— tiomno