परियोजना का विवरण
अनुवादितहमारे पास कई REST माइक्रोसर्विसेज हैं, प्रत्येक अपनी स्वयं की डोमेन क्षेत्र के लिए जिम्मेदार है - उपयोगकर्ता, कैटलॉग, ऑर्डर, बिलिंग। वेब और मोबाइल क्लाइंट एक स्क्रीन को रेंडर करने के लिए लगातार तीन या चार अनुरोध करने से थक गए हैं। हमें इन सेवाओं के सामने एक GraphQL गेटवे की आवश्यकता है, जो एक साफ एकीकृत स्कीमा लौटाता है, और क्लाइंट को एक ही अनुरोध में ठीक वही फ़ील्ड प्राप्त करने की अनुमति देता है जिसकी उन्हें आवश्यकता है। हम जोर देते हैं: यह एक गेटवे कार्य है, पुनर्लेखन नहीं - REST APIs जैसे हैं, और आपकी परत उन्हें एकत्रित और संघटित करती है।
काम का मुख्य भाग स्कीमा डिज़ाइन और रिसॉल्वर है। हम एक अच्छी तरह से संरचित प्रकार प्रणाली की अपेक्षा करते हैं जिसमें स्पष्ट नाम और रिसॉल्वर होते हैं जो अंतर्निहित REST एंडपॉइंट्स को कॉल करते हैं, संबंधित संस्थाओं को स्टिच करते हैं, और क्लासिक N+1 विस्फोट के बिना क्रॉस-सेवा लिंक को हल करते हैं - अर्थात्, प्रत्येक क्वेरी के लिए बैचिंग और डेटा लोडर पैटर्न अनिवार्य हैं। इसके ऊपर, हमें उचित अमान्यकरण और प्राधिकरण के साथ प्रतिक्रिया कैशिंग की आवश्यकता है: कॉलर के टोकन को पास करें, इसे गेटवे पर जांचें, और फ़ील्ड और प्रकार स्तर पर पहुंच नियम लागू करें। कृपया आंशिक विफलताओं को सुचारू रूप से संभालें ताकि एक धीमा बैकएंड पूरी अनुरोध को न गिराए।
भ्रम से बचने के लिए: यह एक मॉक API सर्वर या वेबहुक गेटवे नहीं है - हमें लाइव REST APIs के ऊपर GraphQL का एक उत्पादन एकत्रीकरण परत की आवश्यकता है। परिणाम को तैनात करने योग्य, दस्तावेजीकृत और परीक्षणों के साथ कवर किया जाना चाहिए। कृपया बताएं कि आप कौन सा स्टैक पसंद करते हैं (Node with Apollo, federation router, या कोई अन्य दृष्टिकोण) और क्यों। अनुमान लगाएं - तीन सप्ताह, एक मजबूत इंजीनियर के लिए समय सीमा बातचीत योग्य है।
— 4+ REST सेवाओं के ऊपर एकीकृत GraphQL स्कीमा
— स्टिचिंग, संघ और डेटा लोडर के साथ रिसॉल्वर
— प्रतिक्रिया कैशिंग और अमान्यकरण रणनीति
— फ़ील्ड और प्रकार स्तर पर टोकन पास-थ्रू और प्राधिकरण
— परीक्षण, दस्तावेज़ और चलाने के लिए स्थानीय docker-compose
काम का मुख्य भाग स्कीमा डिज़ाइन और रिसॉल्वर है। हम एक अच्छी तरह से संरचित प्रकार प्रणाली की अपेक्षा करते हैं जिसमें स्पष्ट नाम और रिसॉल्वर होते हैं जो अंतर्निहित REST एंडपॉइंट्स को कॉल करते हैं, संबंधित संस्थाओं को स्टिच करते हैं, और क्लासिक N+1 विस्फोट के बिना क्रॉस-सेवा लिंक को हल करते हैं - अर्थात्, प्रत्येक क्वेरी के लिए बैचिंग और डेटा लोडर पैटर्न अनिवार्य हैं। इसके ऊपर, हमें उचित अमान्यकरण और प्राधिकरण के साथ प्रतिक्रिया कैशिंग की आवश्यकता है: कॉलर के टोकन को पास करें, इसे गेटवे पर जांचें, और फ़ील्ड और प्रकार स्तर पर पहुंच नियम लागू करें। कृपया आंशिक विफलताओं को सुचारू रूप से संभालें ताकि एक धीमा बैकएंड पूरी अनुरोध को न गिराए।
भ्रम से बचने के लिए: यह एक मॉक API सर्वर या वेबहुक गेटवे नहीं है - हमें लाइव REST APIs के ऊपर GraphQL का एक उत्पादन एकत्रीकरण परत की आवश्यकता है। परिणाम को तैनात करने योग्य, दस्तावेजीकृत और परीक्षणों के साथ कवर किया जाना चाहिए। कृपया बताएं कि आप कौन सा स्टैक पसंद करते हैं (Node with Apollo, federation router, या कोई अन्य दृष्टिकोण) और क्यों। अनुमान लगाएं - तीन सप्ताह, एक मजबूत इंजीनियर के लिए समय सीमा बातचीत योग्य है।
— 4+ REST सेवाओं के ऊपर एकीकृत GraphQL स्कीमा
— स्टिचिंग, संघ और डेटा लोडर के साथ रिसॉल्वर
— प्रतिक्रिया कैशिंग और अमान्यकरण रणनीति
— फ़ील्ड और प्रकार स्तर पर टोकन पास-थ्रू और प्राधिकरण
— परीक्षण, दस्तावेज़ और चलाने के लिए स्थानीय docker-compose
वेब प्रोग्रामिंग नकद, बैंक ट्रांसफर
