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

चेतावनी! बाइक के अंदर।

समस्या या समस्या कथन

कुछ समय पहले, यह एक ऐसी कंपनी के लिए एक परियोजना पर काम करने के लिए हुआ जो सीआरएम, ईआरएम सिस्टम और डेरिवेटिव जैसे बड़े पैमाने पर प्रसन्नता लाता है। इसके अलावा, कंपनी ने 200 रजिस्टरों की राशि में ऑपरेटरों को किराए पर लेने की संभावना के साथ कॉल-सेंटर के लिए कैश रजिस्टर के सॉफ्टवेयर के बजाय एक व्यापक उत्पाद जारी किया।

मैंने खुद कॉल-सेंटर के लिए फ्रंट-एंड एप्लिकेशन पर काम किया।

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

जब परियोजना पहले से ही शुरू की गई थी और यहां तक ​​कि खुद के लिए भी काफी काम किया गया था, तो सिस्टम पारदर्शिता की समस्या इसके सभी विकास में पैदा हुई।

यह बात है। कई घटक हैं और वे सभी अपने डेटा स्रोतों के साथ काम करते हैं। लेकिन इनमें से लगभग सभी घटक एक बार स्टैंडअलोन उत्पादों के रूप में लिखे गए थे। वह समग्र प्रणाली के तत्व के रूप में नहीं, बल्कि बिक्री के लिए अलग निर्णयों के रूप में है। परिणामस्वरूप, उनके बीच कोई एकल (सिस्टम) API और कोई सामान्य संचार मानक नहीं है।

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

यह जल्द ही स्पष्ट हो गया (मेरे आसपास के लोगों के लिए, मेरे लिए नहीं, क्योंकि मैंने डिजाइन चरण में समस्या के बारे में बात की थी) कि घटकों के बीच "एकीकृत संचार भाषा" की अनुपस्थिति गंभीर समस्याओं की ओर ले जाती है।

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

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

वे सोचने लगे कि हम वास्तव में क्या चाहते हैं, बाहर निकलना चाहते हैं। परिणामस्वरूप, हमने संभावित समाधान के लिए निम्नलिखित आवश्यकताओं को तैयार किया:

सबसे पहले और सबसे महत्वपूर्ण: डेटा संरचना में किसी भी बदलाव को तुरंत सिस्टम में "हाइलाइट" किया जाना चाहिए। यदि किसी ने कहीं परिवर्तन किया है और ये परिवर्तन सिस्टम की अपेक्षा से असंगत हैं, तो घटक परीक्षण चरण में एक त्रुटि उत्पन्न होनी चाहिए, जिसे बदल दिया गया है।

दूसरा वाला । डेटा प्रकारों को न केवल संकलन के दौरान, बल्कि रन-टाइम भी जांचना चाहिए।

तीसरा । चूंकि बड़ी संख्या में पूरी तरह से अलग-अलग कौशल स्तर वाले लोग घटकों पर काम करते हैं, इसलिए विवरण भाषा सरल होनी चाहिए।

चौथा । जो भी समाधान है, उसके साथ काम करने के लिए जितना संभव हो उतना सुविधाजनक होना चाहिए। यदि संभव हो, तो आईडीई को जितना संभव हो उतना हाइलाइट करना चाहिए।

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

तब JSON में प्रोटोकॉल का वर्णन करने के लिए विचार आया। खैर, कितना आसान है?

खैर, फिर मैंने छोड़ दिया। और इस पर यह पद पूरा हो सकता था, क्योंकि मेरे जाने के बाद किसी और ने समस्या से विशेष रूप से निपटना शुरू नहीं किया।

हालांकि, कुछ व्यक्तिगत परियोजनाओं को देखते हुए, जहां घटकों के बीच संचार का मुद्दा फिर से अपनी पूरी क्षमता तक बढ़ गया, मैंने अपने दम पर विचार को लागू करना शुरू करने का फैसला किया। नीचे क्या चर्चा की जाएगी।

इसलिए, मैं आपके ध्यान में सेरेस परियोजना प्रस्तुत करता हूं, जिसमें शामिल हैं:

• प्रोटोकॉल जनरेटर
• प्रदाता
• ग्राहक
• ट्रांसपोर्ट का कार्यान्वयन

प्रोटोकॉल

कार्य इसे बनाना था ताकि:

• सिस्टम में संदेश संरचना को सेट करना आसान था।
• सभी संदेश क्षेत्रों के डेटा प्रकार को निर्धारित करना आसान था।
• सहायक संस्थाओं को परिभाषित करना और उन्हें संदर्भित करना संभव था।
• और हां, ताकि यह सब आईडीई द्वारा उजागर किया गया हो

मुझे लगता है कि एक पूरी तरह से प्राकृतिक तरीके से, एक भाषा के रूप में जिसमें प्रोटोकॉल परिवर्तित किया गया है, टाइपस्क्रिप्ट को शुद्ध जावास्क्रिप्ट नहीं चुना गया था। यही है, प्रोटोकॉल जनरेटर करता है कि सभी JSON को टाइपस्क्रिप्ट में बदल देता है।

सिस्टम में उपलब्ध संदेशों का वर्णन करने के लिए, आपको केवल यह जानना होगा कि JSON क्या है। जिसके साथ, मुझे यकीन है कि किसी को कोई समस्या नहीं है।

हैलो वर्ल्ड के बजाय, मैं एक कम हैकनेक उदाहरण - चैट प्रदान करता हूं।

{ "Events": { "NewMessage": { "message": "ChatMessage" }, "UsersListUpdated": { "users": "Array<User>" } }, "Requests": { "GetUsers": {}, "AddUser": { "user": "User" } }, "Responses": { "UsersList": { "users": "Array<User>" }, "AddUserResult": { "error?": "asciiString" } }, "ChatMessage": { "nickname": "asciiString", "message": "utf8String", "created": "datetime" }, "User": { "nickname": "asciiString" }, "version": "0.0.1" } 

सब कुछ अपमानजनक सरल है। हमारे पास NewMessage और UsersListUpdated ईवेंट की एक जोड़ी है; साथ ही UsersList और AddUserResult अनुरोधों की एक जोड़ी। दो और संस्थाएं हैं: चैटमैसेज और यूजर।

जैसा कि आप देख सकते हैं, विवरण काफी पारदर्शी और समझने योग्य है। थोड़ा नियमों के बारे में।

• JSON में एक ऑब्जेक्ट उत्पन्न प्रोटोकॉल में एक वर्ग बन जाएगा
• संपत्ति का मूल्य एक डेटा प्रकार की परिभाषा या एक वर्ग (संस्था) का एक संदर्भ है
• उत्पन्न प्रोटोकॉल के दृष्टिकोण से नेस्टेड ऑब्जेक्ट "नेस्टेड" कक्षाएं बन जाएंगे, अर्थात, नेस्टेड ऑब्जेक्ट अपने माता-पिता के सभी गुणों को विरासत में प्राप्त करेंगे।

अब आपको इसका उपयोग शुरू करने के लिए एक प्रोटोकॉल तैयार करना होगा।

 npm install ceres.protocol -g ceres.protocol -s chat.protocol.json -o chat.protocol.ts -r 

नतीजतन, हमें एक टाइपस्क्रिप्ट-जनरेटेड प्रोटोकॉल मिलता है। हम कनेक्ट और उपयोग:

इसलिए, प्रोटोकॉल पहले से ही डेवलपर को कुछ देता है:

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

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

अब हम संदेश को "पैक" कर सकते हैं और भेज सकते हैं

 import * as Protocol from '../../protocol/protocol.chat'; const message: Protocol.ChatMessage = new Protocol.ChatMessage({ nickname: 'noname', message: 'Hello World!', created: new Date() }); const packet: Uint8Array = message.stringify(); // Send packet somewhere 

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

यह सीधे रन-टाइम पर किया जाता है।

 import * as Protocol from '../../protocol/protocol.chat'; const message: Protocol.ChatMessage = new Protocol.ChatMessage({ nickname: 'noname', message: 'Hello World!', created: new Date() }); // Switch to debug mode Protocol.Protocol.state.debug(true); // Now packet will be present as JSON string const packet: string = message.stringify(); // Send packet somewhere 

सर्वर (या किसी अन्य प्राप्तकर्ता) पर, हम आसानी से संदेश अनपैक कर सकते हैं:

 import * as Protocol from '../../protocol/protocol.chat'; const smth = Protocol.parse(packet); if (smth instanceof Error) { // Oops. Something wrong with this packet. } if (Protocol.ChatMessage.instanceOf(smth) === true) { // This is chat message } 

प्रोटोकॉल सभी प्रमुख डेटा प्रकारों का समर्थन करता है:

प्रोटोकॉल के भीतर, इन डेटा प्रकारों को आदिम कहा जाता है। हालांकि, प्रोटोकॉल की एक और विशेषता यह है कि यह आपको अपने स्वयं के डेटा प्रकार (जिसे "अतिरिक्त डेटा प्रकार" कहा जाता है) को जोड़ने की अनुमति देता है।

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

प्रोटोकॉल में अपने प्रकार को जोड़ना काफी सरल है। उदाहरण के लिए, यदि हम ईमेल डेटा टाइप करना चाहते हैं, तो प्रोटोकॉल में निम्न संदेश के लिए कहें:

 { "User": { "nickname": "asciiString", "address": "email" }, "version": "0.0.1" } 

आपको केवल ईमेल प्रकार के लिए एक परिभाषा लिखने की आवश्यकता है।

 export const AdvancedTypes: { [key:string]: any} = { email: { // Binary type or primitive type binaryType : 'asciiString', // Initialization value. This value is used as default value init : '""', // Parse value. We should not do any extra decode operations with it parse : (value: string) => { return value; }, // Also we should not do any encoding operations with it serialize : (value: string) => { return value; }, // Typescript type tsType : 'string', // Validation function to valid value validate : (value: string) => { if (typeof value !== 'string'){ return false; } if (value.trim() === '') { // Initialization value is "''", so we allow use empty string. return true; } const validationRegExp = /^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/gi; return validationRegExp.test(value); }, } }; 

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

 const user: Protocol.User = new Protocol.User({ nickname: 'Brad', email: 'not_valid_email' }); console.log(user); 

ओह ...

 Error: Cannot create class of "User" due error(s): - Property "email" has wrong value; validation was failed with value "not_valid_email". 

तो, प्रोटोकॉल केवल सिस्टम में "खराब" डेटा की अनुमति नहीं देता है।

कृपया ध्यान दें, जब एक नया डेटा प्रकार परिभाषित करते हुए, हमने कुछ प्रमुख गुणों को निर्दिष्ट किया है:

• बाइनरीटाइप - एक आदिम डेटा प्रकार का एक संदर्भ जो डेटा को स्टोर करने, एन्कोड / डीकोड करने के लिए उपयोग किया जाना चाहिए। इस मामले में, हम संकेत देते हैं कि पता एक एससीआई स्ट्रिंग है।
• tsType Javascript प्रकार का संदर्भ है, अर्थात् , जावास्क्रिप्ट प्रकार में डेटा प्रकार का प्रतिनिधित्व कैसे किया जाना चाहिए। इस मामले में हम स्ट्रिंग के बारे में बात कर रहे हैं
• यह भी ध्यान देने योग्य है कि हमें केवल प्रोटोकॉल उत्पन्न करने के समय एक नए डेटा प्रकार को परिभाषित करने की आवश्यकता है। आउटपुट पर, हमें एक उत्पन्न प्रोटोकॉल मिलता है जिसमें पहले से ही एक नया डेटा प्रकार होता है।

आप यहां ceres.protocol के सभी प्रोटोकॉल विशेषताओं के बारे में विस्तृत जानकारी देख सकते हैं।

प्रदाता और ग्राहक

द्वारा और बड़े पैमाने पर, प्रोटोकॉल का उपयोग संचार को व्यवस्थित करने के लिए किया जा सकता है। हालांकि, अगर हम ब्राउज़र और नोडज के बारे में बात कर रहे हैं, तो प्रदाता और ग्राहक उपलब्ध हैं।

ग्राहक

सृजन

क्लाइंट बनाने के लिए, आपको क्लाइंट और ट्रांसपोर्ट की आवश्यकता होती है।

स्थापना

 # Install consumer (client) npm install ceres.consumer --save # Install transport npm install ceres.consumer.browser.ws --save 

सृजन

 import Transport, { ConnectionParameters } from 'ceres.consumer.browser.ws'; import Consumer from 'ceres.consumer'; // Create transport const transport:Transport = new Transport(new ConnectionParameters({ host: 'http://localhost', port: 3005, wsHost: 'ws://localhost', wsPort: 3005, })); // Create consumer const consumer: Consumer = new Consumer(transport); 

क्लाइंट, साथ ही प्रदाता, विशेष रूप से प्रोटोकॉल के लिए डिज़ाइन किए गए हैं। यही है, वे केवल प्रोटोकॉल (ceres.protocol) के साथ काम करेंगे।

घटनाओं

क्लाइंट बनाए जाने के बाद, डेवलपर ईवेंट की सदस्यता ले सकता है

 import * as Protocol from '../../protocol/protocol.chat'; import Transport, { ConnectionParameters } from 'ceres.consumer.browser.ws'; import Consumer from 'ceres.consumer'; // Create transport const transport:Transport = new Transport(new ConnectionParameters({ host: 'http://localhost', port: 3005, wsHost: 'ws://localhost', wsPort: 3005, })); // Create consumer const consumer: Consumer = new Consumer(transport); // Subscribe to event consumer.subscribe(Protocol.Events.NewMessage, (message: Protocol.Events.NewMessage) => { console.log(`New message came: ${message.message}`); }).then(() => { console.log('Subscription to "NewMessage" is done'); }).catch((error: Error) => { console.log(`Fail to subscribe to "NewMessage" due error: ${error.message}`); }); 

कृपया ध्यान दें कि ग्राहक ईवेंट हैंडलर को केवल तभी कॉल करेगा जब संदेश डेटा पूरी तरह से सही होगा। दूसरे शब्दों में, हमारे एप्लिकेशन को गलत डेटा के खिलाफ संरक्षित किया गया है और NewMessage ईवेंट हैंडलर को हमेशा एक तर्क के रूप में Protocol.Events.NewMessage के उदाहरण के साथ कहा जाएगा।

स्वाभाविक रूप से, क्लाइंट ईवेंट उत्पन्न कर सकता है।

 consumer.emit(new Protocol.Events.NewMessage({ message: 'This is new message' })).then(() => { console.log(`New message was sent`); }).catch((error: Error) => { console.log(`Fail to send message due error: ${error.message}`); }); 

ध्यान दें कि हम कहीं भी इवेंट के नाम निर्दिष्ट नहीं करते हैं, हम बस प्रोटोकॉल से क्लास के लिए लिंक का उपयोग करते हैं, या इसका एक उदाहरण देते हैं।

हम दूसरे तर्क के रूप में टाइप के { [key: string]: string } एक साधारण ऑब्जेक्ट को निर्दिष्ट करके प्राप्तकर्ताओं के एक सीमित समूह को एक संदेश भेज सकते हैं। अनाज के भीतर, इस ऑब्जेक्ट को क्वेरी कहा जाता है।

 consumer.emit( new Protocol.Events.NewMessage({ message: 'This is new message' }), { location: "UK" } ).then(() => { console.log(`New message was sent`); }).catch((error: Error) => { console.log(`Fail to send message due error: ${error.message}`); }); 

इस प्रकार, इसके अतिरिक्त { location: "UK" } संकेत देकर, हम यह सुनिश्चित कर सकते हैं कि केवल उन ग्राहकों को जिन्होंने यूके के रूप में अपनी स्थिति की पहचान की है, उन्हें यह संदेश प्राप्त होगा।

ग्राहक को खुद को एक विशिष्ट क्वेरी के साथ जोड़ने के लिए, आपको केवल रेफ विधि को कॉल करने की आवश्यकता है:

 consumer.ref({ id: '12345678', location: 'UK' }).then(() => { console.log(`Client successfully bound with query`); }); 

क्लाइंट को क्वेरी से जोड़ने के बाद, उसके पास "व्यक्तिगत" या "समूह" संदेश प्राप्त करने का अवसर है।

अनुरोध

हम भी अनुरोध कर सकते हैं

 consumer.request( new Protocol.Requests.GetUsers(), // Request Protocol.Responses.UsersList // Expected response ).then((response: Protocol.Responses.UsersList) => { console.log(`Available users: ${response.users}`); }).catch((error: Error) => { console.log(`Fail to get users list due error: ${error.message}`); }); 

यह ध्यान देने योग्य है कि दूसरे तर्क के रूप में हम अपेक्षित परिणाम ( Protocol.Responses.UserList ) को निर्दिष्ट करते हैं, जिसका अर्थ है कि हमारा अनुरोध सफलतापूर्वक पूरा हो जाएगा यदि प्रतिक्रिया उपयोगकर्तालेस्ट का एक उदाहरण है, अन्य सभी मामलों में हम "गिर जाएंगे" पकड़। फिर, यह हमें गलत डेटा संसाधित करने से रोकता है।

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

 function processRequestGetUsers(request: Protocol.Requests.GetUsers, callback: (error: Error | null, results : any ) => any) { // Get user list somehow const users: Protocol.User[] = []; // Prepare response const response = new Protocol.Responses.UsersList({ users: users }); // Send response callback(null, response); // Or send error // callback(new Error(`Something is wrong`)) }; consumer.listenRequest(Protocol.Requests.GetUsers, processRequestGetUsers, { location: "UK" }).then(() => { console.log(`Consumer starts listen request "GetUsers"`); }); 

ध्यान दें, वैकल्पिक रूप से, तीसरे तर्क के रूप में, हम एक क्वेरी ऑब्जेक्ट निर्दिष्ट कर सकते हैं जिसका उपयोग क्लाइंट की पहचान करने के लिए किया जा सकता है। इस प्रकार, यदि कोई क्वेरी के साथ एक क्वेरी भेजता है, तो कहें, { location: "RU" } , तो हमारे ग्राहक को ऐसा कोई अनुरोध नहीं मिलेगा, क्योंकि उसका क्वेरी { location: "UK" } ।

एक क्वेरी में असीमित संख्या में गुण शामिल हो सकते हैं। उदाहरण के लिए, आप निम्नलिखित निर्दिष्ट कर सकते हैं

 { location: "UK", type: "managers" } 

फिर, एक पूर्ण क्वेरी मैच के अलावा, हम निम्नलिखित प्रश्नों को भी सफलतापूर्वक संसाधित करेंगे:

 { location: "UK" } 

या

 { type: "managers" } 

प्रदाता

सृजन

एक प्रदाता बनाने के लिए (और साथ ही एक ग्राहक बनाने के लिए), आपको प्रदाता और परिवहन की आवश्यकता है।

स्थापना

 # Install provider npm install ceres.provider --save # Install transport npm install ceres.provider.node.ws --save 

सृजन

 import Transport, { ConnectionParameters } from 'ceres.provider.node.ws'; import Provider from 'ceres.provider'; // Create transport const transport:Transport = new Transport(new ConnectionParameters({ port: 3005 })); // Create provider const provider: Provider = new Provider(transport); 

प्रदाता द्वारा बनाए जाने वाले क्षण से, यह ग्राहकों से कनेक्शन स्वीकार कर सकता है।

घटनाओं

क्लाइंट के साथ-साथ, प्रदाता संदेशों को "सुन" और उन्हें उत्पन्न कर सकता है।

सुनना

 // Subscribe to event provider.subscribe(Protocol.Events.NewMessage, (message: Protocol.Events.NewMessage) => { console.log(`New message came: ${message.message}`); }); 

उत्पन्न

 provider.emit(new Protocol.Events.NewMessage({ message: 'This message from provider' })); 

अनुरोध

स्वाभाविक रूप से, प्रदाता अनुरोधों के लिए "सुन सकता है" और कर सकता है

 function processRequestGetUsers(request: Protocol.Requests.GetUsers, clientID: string, callback: (error: Error | null, results : any ) => any) { console.log(`Request from client ${clientId} was gotten.`); // Get user list somehow const users: Protocol.User[] = []; // Prepare response const response = new Protocol.Responses.UsersList({ users: users }); // Send response callback(null, response); // Or send error // callback(new Error(`Something is wrong`)) }; provider.listenRequest(Protocol.Requests.GetUsers, processRequestGetUsers).then(() => { console.log(`Consumer starts listen request "GetUsers"`); }); 

क्लाइंट से केवल एक अंतर है, अनुरोध निकाय के अलावा प्रदाता को एक विशिष्ट क्लाइंटआईडी प्राप्त होगा, जो सभी कनेक्टेड क्लाइंट के लिए स्वचालित रूप से असाइन किया गया है।

उदाहरण

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

आप आसानी से स्रोतों को डाउनलोड करके और कुछ सरल क्रिया करके चैट उदाहरण स्थापित कर सकते हैं

ग्राहक स्थापना और लॉन्च

 cd chat/client npm install npm start 

क्लाइंट http: // localhost: 3000 पर उपलब्ध होगा। "संचार" देखने के लिए क्लाइंट के साथ तुरंत टैब खोलें।

प्रदाता (सर्वर) की स्थापना और प्रक्षेपण

 cd chat/server npm install ts-node ./server.ts 

मुझे यकीन है कि आप ts-node पैकेज से परिचित हैं, लेकिन यदि नहीं, तो यह आपको TS फ़ाइलों को चलाने की अनुमति देता है। यदि आप इंस्टॉल नहीं करना चाहते हैं, तो बस सर्वर संकलित करें, और फिर JS फ़ाइल चलाएँ।

 cd chat/server npm run build node ./build/server/server.js 

शॉ? फिर से!

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

यही कारण है कि आपकी प्रतिक्रिया मेरे लिए विशेष मूल्य की है। किसी तरह आपको प्रेरित करने के प्रयास में, मैं यह वादा कर सकता हूं कि गितुब पर हर स्टार के लिए, मैं हम्सटर को स्ट्रोक करूँगा (जो, इसे हल्के ढंग से डालने के लिए, मुझे पसंद नहीं है)। कांटा के लिए, उह, मैं उसके pussiko खरोंच हूँ ...

हम्सटर मेरा नहीं, बेटे का हम्सटर है ।

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

लिंक और पैकेज

परियोजना को दो रिपॉजिटरी द्वारा होस्ट किया गया है

• ceres source: ceres.provider, ceres.consumer और आज उपलब्ध सभी ट्रांसपोर्ट।
• ceres.protocol प्रोटोकॉल जनरेटर स्रोत

उपलब्ध पैकेजों के बाद एनपीएम

• ceres.protocol प्रोटोकॉल जनरेटर
• ceres.provider प्रदाता
• ceres.consumer ग्राहक
• लंबे मतदान के आधार पर एक प्रदाता के लिए ceres.provider.node.longpoll परिवहन
• ceres.provider.node.ws वेब सॉकेट पर आधारित प्रदाता के लिए परिवहन
• लंबे मतदान के आधार पर ग्राहक के लिए ceres.consumer.browser.longpoll परिवहन
• ceres.consumer.browser.ws वेब सॉकेट पर आधारित क्लाइंट के लिए परिवहन

अच्छा और हल्का।