कस्टम समापन बिंदु के साथ मौजूदा API का विस्तार करें

Question

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

मैं व्यक्तिगत रूप से NestJs (हूड के तहत एक्सप्रेस) का उपयोग करता हूं। इसलिए app.moduleवर्तमान में मेरे सभी कोर मॉड्यूल (अपने स्वयं के समापन बिंदुओं के साथ) को पंजीकृत करता है)

import { Module } from '@nestjs/common';

import { UsersModule } from './users/users.module'; // core module

@Module({
  imports: [UsersModule]
})
export class AppModule {}

मुझे लगता है कि यह समस्या NestJs से संबंधित नहीं है तो आप सिद्धांत रूप में इसे कैसे संभालेंगे?

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

कुछ विचार मेरे दिमाग में आते हैं

---

पहले दृष्टिकोण:

प्रत्येक एक्सटेंशन एक नए रिपॉजिटरी का प्रतिनिधित्व करता है। एक कस्टम बाहरी फ़ोल्डर के लिए एक पथ परिभाषित करें जो सभी विस्तार परियोजनाओं को पकड़े हुए है। इस कस्टम निर्देशिका में एक के groupsसाथ एक फ़ोल्डर होगाgroups.module

import { Module } from '@nestjs/common';

import { GroupsController } from './groups.controller';

@Module({
  controllers: [GroupsController],
})
export class GroupsModule {}

मेरा एपीआई उस निर्देशिका के माध्यम से लूप कर सकता है और प्रत्येक मॉड्यूल फ़ाइल को आयात करने का प्रयास कर सकता है।

• पेशेवरों:

  1. कस्टम कोड को कोर रिपॉजिटरी से दूर रखा गया है

• विपक्ष:

  1. NestJs टाइपस्क्रिप्ट का उपयोग करता है इसलिए मुझे पहले कोड संकलित करना होगा। मैं कस्टम ऐप्स से API बिल्ड और बिल्ड कैसे प्रबंधित करूंगा? (प्लग एंड प्ले सिस्टम)

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

  3. कुछ एक्सटेंशन दूसरे एक्सटेंशन से डेटा प्राप्त कर सकते हैं। हो सकता है कि समूह सेवा को उपयोगकर्ता सेवा तक पहुंचने की आवश्यकता हो। यहां चीजें मुश्किल हो सकती हैं।

---

दूसरा तरीका: एपीआई के src फ़ोल्डर के सबफ़ोल्डर के अंदर प्रत्येक एक्सटेंशन रखें। लेकिन इस सबफ़ोल्डर को .gitignore फ़ाइल में जोड़ें। अब आप एपीआई के अंदर अपने एक्सटेंशन रख सकते हैं।

• पेशेवरों:

  1. आपका संपादक निर्भरता को हल करने में सक्षम है

  2. अपना कोड तैनात करने से पहले आप बिल्ड कमांड चला सकते हैं और इसका एक ही वितरण होगा

  3. आप अन्य सेवाओं तक आसानी से पहुँच सकते हैं ( /groupsआईडी द्वारा उपयोगकर्ता को खोजने की आवश्यकता है)

• विपक्ष:

  1. जब आप विकास करते हैं तो आपको उस सबफ़ोल्डर के अंदर अपनी रिपॉजिटरी फ़ाइलों को कॉपी करना होगा। कुछ बदलने के बाद आपको इन फाइलों को वापस कॉपी करना होगा और अपनी रिपॉजिटरी फाइलों को अपडेट के साथ ओवरराइड करना होगा।

---

तीसरा तरीका:

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

• पेशेवरों:

  1. नए एक्सटेंशन को आसानी से विकसित और परीक्षण किया जा सकता है

• विपक्ष:

  1. तैनाती मुश्किल होगी। आपके पास अपनी प्रक्रिया शुरू करने और एक बंदरगाह को सुनने के लिए एक मुख्य एपीआई और एन एक्सटेंशन एपीआई होगा।

  2. प्रॉक्सी सिस्टम मुश्किल हो सकता है। अगर क्लाइंट अनुरोध करता है /usersकि प्रॉक्सी को यह जानने की जरूरत है कि एपीआई उस समापन बिंदु के लिए कौन सा विस्तार सुनता है, तो उस एपीआई और उसके बाद ग्राहक को प्रतिक्रिया दें।

  3. एक्सटेंशन एपीआई की सुरक्षा के लिए (प्रमाणीकरण मुख्य एपीआई द्वारा नियंत्रित किया जाता है) प्रॉक्सी को उन एपीआई के साथ एक रहस्य साझा करने की आवश्यकता होती है। इसलिए एक्सटेंशन API केवल आने वाले अनुरोधों को पारित करेगा यदि उस मेल को प्रॉक्सी से प्रदान किया गया है।

---

चौथा दृष्टिकोण:

माइक्रोसर्विसेज मदद कर सकते हैं। मैंने यहां से एक गाइड लिया https://docs.nestjs.com/microservices/basics

मैं उपयोगकर्ता प्रबंधन, समूह प्रबंधन आदि के लिए एक microservice हो सकता है और उन सेवाओं के लिए एक छोटा सा एपीआई / गेटवे / प्रॉक्सी बनाकर उन सेवाओं का उपभोग कर सकता हूं।

• पेशेवरों:

  1. नए एक्सटेंशन को आसानी से विकसित और परीक्षण किया जा सकता है

  2. अलग की हुई चिंता

• विपक्ष:

  1. तैनाती मुश्किल होगी। आपके पास एक मुख्य एपीआई और एन माइक्रोसर्विसेज होंगे जो अपनी प्रक्रिया शुरू करेंगे और एक पोर्ट सुनेंगे।

  2. ऐसा लगता है कि अगर मैं इसे अनुकूलन योग्य बनाना चाहता हूं तो मुझे प्रत्येक ग्राहक के लिए एक नया प्रवेश द्वार एपीआई बनाना होगा। इसलिए एक आवेदन को विस्तारित करने के बजाय मुझे हर बार एक अनुकूलित comsuming एपीआई बनाना होगा। यह समस्या हल नहीं होगी।

  3. एक्सटेंशन एपीआई की सुरक्षा के लिए (प्रमाणीकरण मुख्य एपीआई द्वारा नियंत्रित किया जाता है) प्रॉक्सी को उन एपीआई के साथ एक रहस्य साझा करने की आवश्यकता होती है। इसलिए एक्सटेंशन API केवल आने वाले अनुरोधों को पारित करेगा यदि उस मेल को प्रॉक्सी से प्रदान किया गया है।

Comments

इससे github.com/nestjs/nest/issues/3277

— प्रश्न

लिंक के लिए धन्यवाद। लेकिन मुझे नहीं लगता कि मुझे अपने कोड के भीतर कस्टम एक्सटेंशन होना चाहिए। मैं जाँच करूँगा कि क्या microservices समस्या को हल करेगा docs.nestjs.com/microservices/basics

— hrp8sfH4xQ4

मुझे लगता है कि आपकी समस्या आराम के बजाय प्राधिकरण से संबंधित है।

— अदनानमुतलेब

@ adnanmuttaleb क्या आप यह बताना चाहेंगे कि क्यों =?

— hrp8sfH4xQ4

Answer 1

इसके लिए कई दृष्टिकोण हैं। आपको जो करने की ज़रूरत है वह यह पता लगाना है कि आपकी टीम, संगठन और ग्राहकों के लिए कौन सा वर्कफ़्लो सबसे उपयुक्त है।

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

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

अतिरिक्त सुगमता के लिए, आप मॉड्यूलेशन फ़ाइल को मार्गों में मैप करने के लिए उपयोग कर सकते हैं और अधिकांश बूटस्ट्रैपिंग करने के लिए एक सामान्य रूट जनरेटर स्क्रिप्ट लिख सकते हैं।

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

निजी संकुल के बारे में यहाँ पढ़ें: निजी संकुल NPM

अब निजी एनपीएम ने पैसे खर्च किए, लेकिन अगर यह एक मुद्दा है तो कई अन्य विकल्प भी हैं। कृपया इस लेख की कुछ विकल्पों के लिए समीक्षा करें - निशुल्क और भुगतान दोनों।

आपके निजी npm रजिस्ट्री के तरीके

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

मैंने ऐसी प्रणाली के लिए एक सरल संदर्भ कार्यान्वयन लिखा है:

रूपरेखा: हरकत सेवा लोकेटर

Palindromes के लिए एक उदाहरण प्लगइन जाँच: हरकत प्लगइन उदाहरण

प्लगइन्स का पता लगाने के लिए फ्रेमवर्क का उपयोग करने वाला एक एप्लिकेशन: लोकोमोशन ऐप उदाहरण

आप इसे npm से प्राप्त करके इसके साथ खेल सकते हैं, npm install -s locomotionआपको plugins.jsonनिम्नलिखित स्कीमा के साथ एक फ़ाइल निर्दिष्ट करने की आवश्यकता होगी :

{
    "path": "relative path where plugins should be stored",
    "plugins": [
        { 
           "module":"name of service", 
           "dir":"location within plugin folder",
           "source":"link to git repository"
        }
    ]
}

उदाहरण:

{
    "path": "./plugins",
    "plugins": [
        {
            "module": "palindrome",
            "dir": "locomotion-plugin-example",
            "source": "https://github.com/drcircuit/locomotion-plugin-example.git"
        }
    ]
}

इसे इस तरह से लोड करें: कॉन्स्ट लोको = आवश्यकता ("लोकोमोशन");

यह तब एक वादा वापस करता है जो सेवा लोकेटर ऑब्जेक्ट को हल करेगा, जिसमें आपकी सेवाओं की पकड़ पाने के लिए लोकेटर विधि है:

loco.then((svc) => {
    let pal = svc.locate("palindrome"); //get the palindrome service
    if (pal) {
        console.log("Is: no X in Nixon! a palindrome? ", (pal.isPalindrome("no X in Nixon!")) ? "Yes" : "no"); // test if it works :)
    }
}).catch((err) => {
    console.error(err);
});

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

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

Comments

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

— hrp8sfH4xQ4

इस तरह की प्रणाली के लिए एक अल्पविकसित समाधान का एक संदर्भ कार्यान्वयन जोड़ा गया।

— एस्पेन

Answer 2

मैं बाहरी पैकेज विकल्प के लिए जाना होगा।

आप एक packagesफ़ोल्डर के लिए अपने ऐप को स्ट्रक्चर कर सकते हैं । मेरे पास उस फ़ोल्डर में यूएमडी बाहरी पैकेजों का संकलन होगा ताकि आपके संकलित टाइपस्क्रिप्ट में पैकेज के साथ कोई समस्या न हो। सभी पैकेजों में index.jsप्रत्येक पैकेज के रूट फ़ोल्डर में एक फ़ाइल होनी चाहिए ।

और आपका ऐप पैकेज फ़ोल्डर का उपयोग करके fsऔर आपके ऐप के requireसभी पैकेजों के माध्यम से एक लूप चला सकता है index.js।

फिर से निर्भरता की स्थापना एक ऐसी चीज है जिसका आपको ध्यान रखना है। मुझे लगता है कि प्रत्येक पैकेज पर एक कॉन्फ़िगरेशन फ़ाइल भी हल कर सकती है। npmएप्लिकेशन शुरू करने से पहले सभी पैकेज निर्भरताओं को स्थापित करने के लिए आपके पास मुख्य ऐप पर एक कस्टम स्क्रिप्ट हो सकती है ।

इस तरह, आप पैकेज को कॉपी करके पैकेज फ़ोल्डर में कॉपी करके और ऐप को रिबूट करके अपने पैकेज में नए पैकेज जोड़ सकते हैं। आपकी संकलित टाइपस्क्रिप्ट फ़ाइलों को छुआ नहीं जाएगा और आपको अपने स्वयं के पैकेज के लिए निजी npm का उपयोग करने की आवश्यकता नहीं है।

Comments

आपके जवाब के लिए धन्यवाद। मुझे लगता है कि इस समाधान की तरह लगता है @ एस्पेन पहले से ही पोस्ट किया गया है, नहीं?

— hrp8sfH4xQ4

@ hrp8sfH4xQ4 हां, एक विस्तार के लिए। मैंने इसका उपयोग करने के बारे में आपकी टिप्पणी को पढ़ने के बाद जोड़ा npm। ऊपर एक समाधान है जिसे आप निजी एनपीएम खाते से बचने के लिए कर सकते हैं। इसके अलावा, मेरा मानना ​​है कि आपको अपने संगठन के बाहर किसी व्यक्ति द्वारा बनाए गए पैकेज को जोड़ने की आवश्यकता नहीं है। सही?

— कलश कालाधन

btw। लेकिन यह भी समर्थन के लिए बहुत बढ़िया होगा ... किसी भी तरह ...

— hrp8sfH4xQ4

यदि आपको तीसरे पक्ष के पैकेज को जोड़ने के लिए विकल्प की आवश्यकता है, तो npmऐसा करने का तरीका या कोई अन्य पैकेज प्रबंधक है। ऐसे मामलों में, मेरा समाधान पर्याप्त नहीं होगा।

— कलश कालधरण

यदि आपको कोई आपत्ति नहीं है, तो मैं जितना संभव हो उतने दृष्टिकोण लेने के लिए इंतजार करना चाहूंगा

— hrp8sfH4xQ4