👨🏼‍🤝‍👨🏻 ➰ 💗 निर्बाध ग्राहक सर्वर 🍥 🧐 🙅🏿

किसी भी क्लाइंट-सर्वर प्रोजेक्ट का मतलब है कि कोड आधार को 2 भागों (कभी-कभी अधिक) - क्लाइंट और सर्वर में स्पष्ट रूप से अलग करना। अक्सर, इस तरह के प्रत्येक भाग को एक अलग स्वतंत्र परियोजना के रूप में निष्पादित किया जाता है, जिसे डेवलपर्स की अपनी टीम द्वारा समर्थित किया जाता है।

इस लेख में, मैं एक बैकएंड और एक दृश्यपटल में कोड के मानक हार्ड डिवीजन पर एक महत्वपूर्ण नज़र रखने का प्रस्ताव करता हूं। और एक विकल्प पर विचार करें जहां कोड क्लाइंट और सर्वर के बीच एक स्पष्ट रेखा नहीं है।

मानक दृष्टिकोण के विपक्ष

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

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

सपने देखते हैं

मान लीजिए कि हम क्लाइंट से डेटाबेस तक एक मॉडल में सर्वर पर फॉर्म से पूरे डेटा पथ का वर्णन कर सकते हैं। कोड में, यह कुछ इस तरह दिख सकता है (कोड काम नहीं कर रहा है):

class MyDataModel { //         verifyData(data) { //   .... return true; } //       client saveData(data) { if(this.verifyData(data)) this.writeDataToDb(data) else consol.log('error') } //  .     server writeDataToDb(data) { if(this.verifyData(data)) this.db.insert(data) else consol.log('error') } }

इस प्रकार, मॉडल का पूरा व्यापार तर्क हमारी आंखों के सामने है। ऐसे कोड को बनाए रखना आसान है। यहां ऐसे फायदे हैं जो क्लाइंट-सर्वर के तरीकों को एक मॉडल में जोड़ सकते हैं:

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

मैं अंतिम बिंदु को अधिक विस्तार से प्रकट करूंगा। ऐसी योजना के रूप में एक नियमित ग्राहक-सर्वर अनुप्रयोग की कल्पना करें:

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

यहां प्रस्तावित दृष्टिकोण आपको 90 डिग्री से जिम्मेदारी के विभाजन की रेखा का विस्तार करने और ऊर्ध्वाधर वास्तुकला को क्षैतिज में बदलने की अनुमति देता है।

इस तरह के आर्किटेक्चर को स्केल करना ज्यादा आसान होता है और गलती ज्यादा सहनशील होती है। वास्या और फेड्या विनिमेय हो जाते हैं।

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

समस्या का बयान

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

निर्णय

मैं काफी समय से एक फ़ाइल में क्लाइंट और सर्वर के एकीकरण के साथ प्रयोग कर रहा था। कुछ समय पहले तक, मुख्य समस्या यह थी कि मानक JS में, क्लाइंट और सर्वर पर थर्ड-पार्टी मॉड्यूल का कनेक्शन बहुत अलग था: n.js में, क्लाइंट को AJAX के सभी जादू की आवश्यकता होती है (...)। ईएस-मॉड्यूल के आगमन के साथ सब कुछ बदल गया है। आधुनिक ब्राउज़रों में, "आयात" लंबे समय से समर्थित है। इस संबंध में Node.js थोड़ा पीछे है और ES- मॉड्यूल केवल "--experimental-मॉड्यूल" ध्वज सक्षम के साथ समर्थित हैं। यह आशा की जाती है कि निकट भविष्य में, मॉड्यूल नोड के बॉक्स से बाहर काम करेंगे। इसके अलावा, यह संभावना नहीं है कि कुछ बहुत बदल जाएगा, क्योंकि ब्राउज़रों में, यह कार्यक्षमता लंबे समय से डिफ़ॉल्ट रूप से काम कर रही है। मुझे लगता है कि अब आप ईएस-मॉड्यूल का उपयोग न केवल क्लाइंट पर, बल्कि सर्वर साइड पर भी कर सकते हैं (यदि आपके पास इस विषय पर काउंटर-तर्क हैं, तो टिप्पणियों में लिखें)।

समाधान योजना इस प्रकार है:

परियोजना में तीन मुख्य कैटलॉग हैं:

संरक्षित - बैकएंड;
जनता - frontend;
साझा - साझा क्लाइंट-सर्वर मॉडल।

एक अलग पर्यवेक्षक प्रक्रिया साझा निर्देशिका में फ़ाइलों की निगरानी करती है और, किसी भी परिवर्तन के साथ, क्लाइंट के लिए और सर्वर के लिए अलग से परिवर्तित फ़ाइल के संस्करण बनाती है (संरक्षित / साझा और सार्वजनिक / साझा निर्देशिका में)।

कार्यान्वयन

एक साधारण वास्तविक समय के दूत के उदाहरण पर विचार करें। हमें ताजा नोड की आवश्यकता होगी। जेएस (मेरे पास संस्करण 11.0.0 है) और रेडिस (उन्हें स्थापित करना यहां कवर नहीं है)।

एक उदाहरण क्लोन:

 git clone https://github.com/Kolbaskin/both-example cd ./both-example npm i

प्रेक्षक प्रक्रिया (आरेख में प्रेक्षक) को स्थापित और चलाएं:

 npm i both-js -g both ./index.mjs

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

आप लिंक पर क्लिक करके दूत के प्रदर्शन को ब्राउज़र में देख सकते हैं

http://localhost:3000/index.html?token=123&user=Vasya

(टोकन और उपयोगकर्ता मनमाना हैं)। कई उपयोगकर्ताओं का अनुकरण करने के लिए, अलग टोकन और उपयोगकर्ता को निर्दिष्ट करके दूसरे ब्राउज़र में एक ही पृष्ठ खोलें।

अब थोड़ा कोड।

वेब सर्वर

संरक्षित / server.mjs

 import express from 'express'; import bodyParser from 'body-parser'; // -     //  -  import wsServer from './lib/wsServer.mjs'; const app = express(); //   - wsServer(app); //  mime  mjs express.static.mime.define({'application/javascript': ['js','mjs']}); app.use( bodyParser.json() ); app.use(bodyParser.urlencoded({ extended: true })); //      public app.use(express.static('public')); const server = app.listen(3000, () => { console.log('server is running at %s', server.address().port); });

यह एक नियमित एक्सप्रेस सर्वर है, यहां कुछ भी दिलचस्प नहीं है। नोड्स में ES मॉड्यूल के लिए mjs एक्सटेंशन की आवश्यकता होती है। स्थिरता के लिए, हम क्लाइंट के लिए इस एक्सटेंशन का उपयोग करेंगे।

ग्राहक

public / index.html

 <!DOCTYPE html> <html lang="en"> <head> ... <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script> <script src="/main.mjs" type="module"></script> </head> <body> ... <ul id="users"> <li v-for="user in users"> {{ user.name }} ({{user.id}}) </li> </ul> <div id="messages"> <div> <input type="text" v-model="msg" /> <button v-on:click="sendMessage()"></button> </div> <ul> <li v-for="message in messages">[{{ message.date }}] <strong>{{ message.text }}</strong></li> </ul> </div> </body> </html>

उदाहरण के लिए, मैं क्लाइंट पर Vue का उपयोग करता हूं, लेकिन यह सार नहीं बदलता है। Vue के बजाय, वहाँ कुछ भी हो सकता है जहाँ आप डेटा मॉडल को एक अलग वर्ग (नॉकआउट, कोणीय) में अलग कर सकते हैं।

सार्वजनिक / main.mjs

 //      - import ws from "/lib/Ws.mjs"; //       import Messages from "./shared/messages/model/dataModel.mjs"; //    import Users from "./shared/users/model/dataModel.mjs"; //  - (     ) window.WS = new ws({ token: new URLSearchParams(document.location.search).get("token"), user: new URLSearchParams(document.location.search).get("user") }); //       new Messages({ el: '#messages' }) //       new Users({ el: '#users' })

main.mjs एक स्क्रिप्ट है जो डेटा मॉडल को संबंधित विचारों के साथ जोड़ती है। कोड को सरल बनाने के लिए, सक्रिय उपयोगकर्ताओं और संदेश फ़ीड की सूची के लिए नमूना प्रतिनिधित्व सीधे index.html में बनाया जाता है

डेटा मॉडल

साझा / संदेश / मॉडल / dataModel.mjs

 //    //          , //    import Base from '@root/lib/Base.mjs'; export default class dataModel extends Base { //!#client constructor(attr) { attr.data = { msg: '', messages: [] } super(attr); //     this.on('newmessage', (data) => { this.messages.push(data) }) } //!#client async sendMessage(e) { //    await this.$sendMessage(this.msg); this.msg = ''; } //!#server async $sendMessage(text) { //   newmessage     this.fireEvent('newmessage', 'all', { date: new Date(), text }) return true; } }

ये कई तरीके वास्तविक समय में संदेश भेजने और प्राप्त करने की सभी कार्यक्षमता को लागू करते हैं। निर्देश! #Client और! #Sverver पर्यवेक्षक प्रक्रिया को बताता है कि किस विधि के लिए किस भाग (क्लाइंट या सर्वर) का इरादा है। यदि किसी विधि को परिभाषित करने से पहले ये निर्देश नहीं हैं, तो ऐसी विधि क्लाइंट और सर्वर दोनों पर उपलब्ध है। निर्देश के पहले टिप्पणी स्लैश वैकल्पिक हैं और केवल मानक IDE को सिंटैक्स त्रुटियों पर शपथ लेने से रोकने के लिए मौजूद हैं।

पथ की पहली पंक्ति & रूट लुकअप का उपयोग करती है। क्लाइंट और सर्वर संस्करण बनाते समय, और रूट को क्रमशः सार्वजनिक और संरक्षित निर्देशिकाओं के सापेक्ष पथ से बदल दिया जाएगा।

एक और महत्वपूर्ण बिंदु: क्लाइंट विधि से, आप केवल सर्वर विधि को कॉल कर सकते हैं, जिसका नाम "$" से शुरू होता है।

 ... //    async sendMessage(e) { await this.$sendMessage(this.msg); <-    this.msg = ''; } ...

यह सुरक्षा कारणों से किया जाता है: बाहर से आप केवल इसके लिए विशेष रूप से डिज़ाइन किए गए तरीकों की ओर मुड़ सकते हैं।

आइए उन डेटा मॉडल के संस्करणों को देखें जो क्लाइंट और सर्वर के लिए उत्पन्न पर्यवेक्षक हैं।

ग्राहक (सार्वजनिक / साझा / संदेश / मॉडल / dataModel.mjs)

 import Base from '/lib/Base.mjs'; export default class dataModel extends Base { __getFilePath__() {return "messages/model/dataModel.mjs"} // constructor(attr) { attr.data = { msg: '', messages: [] } super(attr); //     this.on('newmessage', (data) => { this.messages.push(data) }) } // async sendMessage(e) { //    await this.$sendMessage(this.msg); this.msg = ''; } // ... async $sendMessage() {return await this.__runSharedFunction("$sendMessage",arguments)} }

क्लाइंट पक्ष पर, मॉडल Vue वर्ग (Base.mjs के माध्यम से) का वंशज है। इस प्रकार, आप नियमित Vue डेटा मॉडल के साथ इसके साथ काम कर सकते हैं। पर्यवेक्षक ने मॉडल के क्लाइंट संस्करण में __getFilePath__ विधि को जोड़ा, जो क्लास फ़ाइल में पथ देता है और $ sendMessage सर्वर विधि कोड को एक निर्माण के साथ बदलता है, जो कि संक्षेप में, उस विधि को कॉल करेगा जिसे हमें rpc तंत्र के माध्यम से सर्वर (पेरेंट क्लास में __runSaredFunction परिभाषित किया गया है) की आवश्यकता है।

सर्वर (संरक्षित / साझा / संदेश / मॉडल / dataModel.mjs)

 import Base from '../../lib/Base.mjs'; export default class dataModel extends Base { __getFilePath__() {return "messages/model/dataModel.mjs"} ...       ... // async $sendMessage(text) { //   newmessage     this.fireEvent('newmessage', 'all', { date: new Date(), text }) return true; } }

सर्वर संस्करण में, __getFilePath__ पद्धति को भी जोड़ा गया था और निर्देश के साथ चिह्नित क्लाइंट विधियों को हटा दिया गया था! # रोगी

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

क्लाइंट-सर्वर इंटरैक्शन

जब हमें क्लाइंट पर कुछ सर्वर विधि को कॉल करने की आवश्यकता होती है, तो हम इसे करते हैं।
यदि कॉल एक ही मॉडल के भीतर है, तो सब कुछ सरल है:

 ... !#client async sendMessage(e) { await this.$sendMessage(this.msg); this.msg = ''; } !#server async $sendMessage(msg) { // -    } ...

आप दूसरे मॉडल को "खींच" सकते हैं:

 import dataModel from "/shared/messages/model/dataModel.mjs"; var msg = new dataModel(); msg.$sendMessage('blah-blah-blah');

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

 //    ... //!#client constructor(attr) { .... //       "newmessage" this.on('newmessage', (data) => { this.messages.push(data) }) } //!#server async $sendMessage(text) { //     newmessage     this.fireEvent('newmessage', 'all', { date: new Date(), text }) return true; } ...

फायरइनवेंट विधि में 3 पैरामीटर होते हैं: घटना का नाम, जिसे यह संबोधित किया जाता है, और डेटा। आप प्राप्तकर्ता को कई तरीकों से सेट कर सकते हैं: कीवर्ड "ऑल" - ईवेंट को उन सभी क्लाइंट्स या ऐरे को भेजा जाएगा, जिनके पास ईवेंट को संबोधित करने वाले क्लाइंट्स के सेशन टोकन को सूचीबद्ध करने के लिए है।

घटना डेटा मॉडल वर्ग के एक विशिष्ट उदाहरण से बंधी नहीं है और हैंडलर उस वर्ग के सभी उदाहरणों में आग लगाएगा जिसमें फायरवर्थ को बुलाया गया था।

क्षैतिज बैकेंड स्केलिंग

पहली नज़र में, प्रस्तावित कार्यान्वयन में क्लाइंट-सर्वर मॉडल की अखंडता को सर्वर भाग के क्षैतिज स्केलिंग की संभावना पर महत्वपूर्ण प्रतिबंध लगाना चाहिए। लेकिन यह ऐसा नहीं है: तकनीकी रूप से, सर्वर क्लाइंट पर निर्भर नहीं है। आप "सार्वजनिक" निर्देशिका को कहीं भी कॉपी कर सकते हैं और इसकी सामग्री किसी अन्य वेब सर्वर (nginx, Apache, आदि) के माध्यम से दे सकते हैं।

नए बैकेंड इंस्टेंस को लॉन्च करके सर्वर साइड को आसानी से बढ़ाया जा सकता है। रेडिस और क्यू कतार प्रणाली का उपयोग व्यक्तिगत उदाहरणों के साथ बातचीत करने के लिए किया जाता है।

एक बैकएंड के लिए एपीआई और विभिन्न क्लाइंट

वास्तविक परियोजनाओं में, विविध सर्वर क्लाइंट एक सर्वर एपीआई - वेबसाइटों, मोबाइल एप्लिकेशन, तृतीय-पक्ष सेवाओं का उपयोग कर सकते हैं। प्रस्तावित समाधान में, यह सब बिना किसी अतिरिक्त नृत्य के उपलब्ध है। कॉलिंग सर्वर विधियों के हुड के तहत अच्छा पुराना आरपीसी है। वेब सर्वर अपने आप में एक क्लासिक एक्सप्रेस एप्लिकेशन है। यह समान डेटा मॉडल के आवश्यक तरीकों को कॉल करने वाले मार्गों के लिए वहां एक आवरण जोड़ने के लिए पर्याप्त है।

पोस्ट स्क्रिप्टम

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

यह परियोजना प्रयोगात्मक है, टिप्पणियों में लिखें कि क्या, आपकी राय में, यह प्रयोग जारी रखने के लायक है।

निर्बाध ग्राहक सर्वर