jsonex - जटिल क्लाइंट-सर्वर डायलॉग को सरल करता है

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

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

डेवलपर्स बहुत समय बिताते हैं, बार-बार सर्वर साइड पर बदसूरत बाइक बनाते हैं, जिसके बाद उन्हें क्लाइंट की तरफ से भी समर्थन करना पड़ता है।

jsonex कॉल करने योग्य डेटा की अवधारणा के आधार पर एक सरल, एकीकृत दृष्टिकोण के ढांचे के ऊपर और कई अन्य समस्याओं के समाधान को संयोजित करने का एक प्रयास है।

सामग्री

jsonex
संकेतन को बुलाओ
प्रसंग
संचार jsonex और जेएस
कम्प्यूटेबल डेटा (कॉल करने योग्य डेटा)
ग्राहक पक्ष देखें
कम्प्यूटेशनल डेटा के लाभ
HTTP और वेब सॉकेट्स के साथ काम करें
सुरक्षा संबंधी बातें
JSON प्रतिनिधित्व
अतुल्यकालिक कॉल
आर्क
निष्कर्ष

jsonex

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

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

• टिप्पणी की अनुमति दें
• तार के लिए apostrophes की अनुमति दें
• शब्दकोशों में कुंजियों के लिए उद्धरण चिह्नों को छोड़ दें
• शब्दकोशों और सूचियों में अल्पविरामों की अनुमति दें

हमारे JSON का विस्तारित संस्करण (इसे jsonex कहते हैं), उदाहरण के लिए, इस तरह दिख सकता है:

{ //  name: 'John', familyName: 'Smith', dateOfBirth: '1901-01-01', friendIds: [ 124124, 283746, /*   */ ], num: 123, } 

पहले से ही बुरा नहीं है। मैं JSON कॉन्फ़िगरेशन में टिप्पणी लिखने की क्षमता के लिए बहुत कुछ दूंगा। लेकिन इस उदाहरण में एक बहुत ही संदिग्ध रेखा है:

  dateOfBirth: '1901-01-01', 

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

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

संकेतन को बुलाओ

हम अपने क्षेत्र को इस तरह लिखते हैं:

  dateOfBirth: Date('1901-01-01'), 

डेटा प्रकार अब स्पष्ट दिखता है। लेकिन जब पार्कर ऐसा रिकॉर्ड करता है तो वास्तव में उसे क्या करना चाहिए? दृष्टिकोण काफी सीधा है। फार्म SomeName(args...) निर्माण का सामना करने के बाद SomeName(args...) पार्सर को चाहिए:

• अपने डिब्बे में SomeName नाम का एक पूर्वनिर्धारित हैंडलर फ़ंक्शन SomeName
• तर्कों पर इस कार्य को निष्पादित करें args...
• मूल डिजाइन के बजाय संसाधित डेटा में इसके निष्पादन के परिणाम का उपयोग करें

इस प्रकार, विश्लेषण का परिणाम पूरी तरह से हैंडलर फ़ंक्शन के कार्यान्वयन पर निर्भर करता है। हमारी Date('1901-01-01') कॉल Date('1901-01-01') जावास्क्रिप्ट में date , पायथन में date और datetime इत्यादि प्रकार के ऑब्जेक्ट में बदल जाएगी।

मामले में जब पार्सर दिए गए नाम के साथ हैंडलर को नहीं ढूंढ सकता है, तो वह डिफ़ॉल्ट हैंडलर को कॉल करता है, जो या तो कुछ उचित लौटाएगा या अपवाद फेंक देगा।

ऐसा प्रतीत हो सकता है कि कॉल नोटेशन को संसाधित करते समय, हम डेटा में निहित कोड के एक अनियंत्रित टुकड़े को निष्पादित करते हैं, लेकिन यह नहीं है:

• डेटा डेटा रहता है और प्रोसेसिंग पर नियंत्रण पूरी तरह से हमारे साथ है
• पार्सर स्पष्ट रूप से परिभाषित हैंडलर के अलावा किसी भी फ़ंक्शन का उपयोग नहीं कर सकता है
• किसी भी हैंडलर फ़ंक्शन को हमारे द्वारा परिभाषित किया गया है और सक्रिय क्रियाएं करने से पहले किसी भी प्रारंभिक जांच कर सकते हैं।

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

 var handlers = { Date: function (ctx, v) { return new Date(v); }, Complex: function (ctx, real, imag) { return new Complex(real, imag); }, ArrayBuffer: function (ctx, v) { return base64DecToArr(v).buffer; }, Person: function (ctx, personDataDict) { return new Person(personDataDict); } }; //    ,        var person = new JsonexParser(handlers).parse( "Person({"+ " name: 'John',"+ " dateOfBirth: Date('1901-01-01'),"+ " i: Complex(0, 1),"+ " song: ArrayBuffer('Q2FsbCBub3RhdGlvbiBpcyBjb29sIQ=='),"+ "})" ); 

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

प्रसंग

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

• हैंडलर को एक दूसरे के साथ "संवाद" करने दें
• हैंडलर को कुछ सेटिंग्स पास करें
• बाहरी वातावरण से हैंडलर के लिए अतिरिक्त डेटा पास करें
• पार्सिंग के दौरान प्राप्त अतिरिक्त जानकारी सहेजें

उदाहरण के लिए, संदर्भ का उपयोग करते हुए, हैंडलर को get और set करना आसान है जो आपको पहले गणना की गई वस्तुओं का उपयोग करने की अनुमति देता है:

 var handlers = { //         set: function (ctx, key, data) { ctx.box = ctx.box || {}; ctx.box[key] = data; return data; }, //  ,    get: function (ctx, key) { return ctx.box ? ctx.box[key] : undefined; } }; var data = new JsonexParser(handlers).parse( "[ set('x', { a: 'a' }), get('x') ]" ); data[0].a = 5; //  data[0]  data[1]         console.log(JSON.stringify(data)); // [{"a":5},{"a":5}] 

संचार jsonex और जेएस

JSON की तरह, jsonex JS सिंटैक्स से निकटता से संबंधित है। यह जेएस एक्सप्रेशन का एक सिन्थेटिक रूप से सही है और सरलतम मामलों में, जेएस एक्सप्रेशन के रूप में भी मूल्यांकन किया जा सकता है, बशर्ते कि प्रत्येक कॉल नोटेशन को गणना के संदर्भ में परिभाषित किया गया हो। उदाहरण के लिए

 [ foo(), bar.baz() // , jsonex      ] 

एक मान्य और, अधिक, कम्प्यूटेशनल जेएस-अभिव्यक्ति है, बशर्ते कि foo और bar सही ढंग से परिभाषित किया गया हो।

यह, ज़ाहिर है, इसका मतलब यह नहीं है कि यह संबंधित क्लोजर में आवश्यक चर को परिभाषित करके eval() का उपयोग करके jsonex लेने और मूल्यांकन करने के लायक है। संभावित सुरक्षा समस्याओं के अलावा, यह दृष्टिकोण कुछ लचीलेपन को खो देता है जो डेटा के रूप में डेटा का सटीक विश्लेषण करना संभव बनाता है, न कि कुछ प्रदर्शन किया जा रहा है। हालाँकि, कुछ मामलों में, jsonex को वास्तव में JS का सीमित उपसमूह माना जा सकता है और jsonex डेटा को JS अभिव्यक्ति के रूप में माना जाता है।

कम्प्यूटेबल डेटा (कॉल करने योग्य डेटा)

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

 getUsers([1, 15, 7]) 

सर्वर उचित हैंडलर का उपयोग करके इसकी गणना कर सकता है:

 var handlers = { getUsers: function (ctx, userIds) { var listOfUsers = getUsersFromDbOrWhatever(userIds); return listOfUsers; } }; 

फिर परिणाम jsonex में क्रमबद्ध करें और ग्राहक को प्रतिक्रिया भेजें:

 [ User({id: 1, name: 'John', ...}), ...] 

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

ग्राहक पक्ष देखें

ग्राहक के कॉल को व्यवस्थित करने के तरीके के बारे में सोचते हैं। "getUsers([1, 15, 7])" जैसे स्ट्रिंग्स के रूप में मैन्युअल रूप से jsonex प्रतिनिधित्व एकत्र करना असुविधाजनक होगा। इसलिए, हमें एक सहायक वस्तु की आवश्यकता है जो कॉल नोटेशन का वर्णन करती है और धारावाहिक द्वारा समझी जाती है। इस तरह इसका उपयोग दिख सकता है:

 var getUsers = function (userIds) { return new jsonex.Call('getUsers', userIds); //   }; //     jsonex.stringify(getUsers([1, 15, 7])); // 'getUsers([1,15,7])' 

इस स्थिति में, सर्वर अनुरोध इस तरह दिख सकता है:

 server.ask( getUsers([1, 15, 7]), //  function (err, result) { //   ... } ); 

server.ask() को निम्न कार्य करना चाहिए:

• पहले तर्क को jsonex में बदल दें
• इसे सर्वर अनुरोध के रूप में भेजें
• Jsonex प्रतिक्रिया की प्रतीक्षा करें और इसे पार्स करें
• कॉलबैक फ़ंक्शन के लिए परिणाम भेजें

हमारे उदाहरण में, पहला तर्क यह होगा कि getUsers() वापस आ जाएगा, जो कि टाइप jsonex.Call का एक ऑब्जेक्ट है, जिसे स्ट्रिंग के लिए क्रमबद्ध किया जाता है 'getUsers([1,15,7])'

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

यदि सर्वर से प्राप्त परिणाम त्रुटि वर्ग का वंशज है, तो server.ask() मानता है कि सर्वर ने एक त्रुटि लौटा दी और संबंधित तर्कों के साथ कॉलबैक का कारण बनता है। यह दृष्टिकोण संभव है क्योंकि पार्सिंग का परिणाम वांछित वर्ग का तैयार-से-उपयोग ऑब्जेक्ट है।

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

त्रुटि संदेश के साथ उदाहरण सर्वर प्रतिक्रिया:

 UnexpectedError('Error details message') 

हैंडलर उदाहरण:

 handlers.UnexpectedError = function(ctx, msg) { return new ServerError(msg); // ServerError    Error }; 

कम्प्यूटेशनल डेटा के लाभ

कम्प्यूटेशनल डेटा हमें क्या देता है:

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

एक बैच अनुरोध, उदाहरण के लिए, इस तरह दिख सकता है:

 [ getFoo(), getBar(1, 2, 3), ] 

जवाब में, getFoo() और getBar() कॉल के परिणामों के साथ एक सरणी आएगी।

हम दूसरे में एक गणना के परिणाम का उपयोग करते हैं:

 [ set('x', getUserBooks(17)), //    17 getAuthors( //    getProps( //   'authorId'     get('x') get('x'), 'authorId' ) ), ] 

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

राउंड-ट्रिप डेटा ट्रांसफर:

 [ 137, // ,  , , id  someRequest(...) ] 

प्रतिक्रिया 137 नंबर के साथ एक सरणी होगी और कुछ कॉलिंग someRequest() का परिणाम होगा।
नोट: वास्तव में, हमें यह सुनिश्चित करने के लिए एक अधिक जटिल निर्माण का उपयोग करना होगा कि राउंड-ट्रिप डेटा वापस कर दिया जाता है, भले ही कुछ अपवाद someRequest() प्रसंस्करण के दौरान एक अपवाद फेंक दिया गया हो।

अतिरिक्त डेटा अंतरण:

 last( //    metaInfo('   ', 1, 3, 4), someRequest(...) ) 

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

HTTP और वेब सॉकेट्स के साथ काम करें

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

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

डेटा के हस्तांतरण के लिए के रूप में, HTTP अनुरोध के शरीर में प्रसारित होने पर सब कुछ बहुत अच्छा है। ज्यादातर मामलों में, ऐसा होगा, क्योंकि jsonex अनुरोधों के लिए POST विधि का उपयोग उचित लगता है। लेकिन अगर किसी उद्देश्य के लिए, GET, HEAD या DELETE का उपयोग किया जाता है, तो आपको URL के भाग के रूप में डेटा स्थानांतरित करना होगा, क्योंकि मानक के अनुसार इन अनुरोधों के मुख्य भाग को अनदेखा किया जाना चाहिए। ऐसा करने का एक सरल और सस्ता तरीका है - एकल क्वेरी स्ट्रिंग पैरामीटर में jsonex पास करें, उदाहरण के लिए query । इस प्रकार, अनुरोध getUsers([1,2,3]) कॉल को पते में बदल देगा example.com/api?query=getUsers%28%5B1%2C2%2C3%5D%29

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

मेटाडेटा स्थानांतरित करने के लिए आप HTTP हेडर और jsonex दोनों सुविधाओं का उपयोग कर सकते हैं:

 last( authToken('myAuthToken'), //   ,   someOtherHeader('blah blah'), getUsers([1, 15]) ) 

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

HTTP के लिए, अनुरोधों की शालीनता भी महत्वपूर्ण है। यह गुण HTTP विधि द्वारा निर्धारित किया गया है: कुछ विधियों को बेरोजगार होना चाहिए, अन्य नहीं। चूँकि jsonex रिक्वेस्ट idempotent और non-idempotent कॉल्स का मिश्रण हो सकता है, हमें एक ऐसे तंत्र की आवश्यकता है जो हमें इसके बारे में कुछ करने की अनुमति दे। उदाहरण के लिए, आप एक ध्वज को लाद सकते हैं, जिसके लिए आपको अपव्यय की आवश्यकता होती है और इसे कॉल में जांचें:

 var handlers = { idempotent: function (ctx) { ctx.mustBeIdempotent = true; }, updateUser(ctx, userData) { if (ctx.mustBeIdempotent) { throw new NonIdempotentCallError('updateUser'); } ... } }; 

अनुरोध उदाहरण:

 last( idempotent(), [ getUsers([1,2]), updateUser({id:1, ...}) //   ] ) 

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

सुरक्षा संबंधी बातें

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

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

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

 handlers.expesiveCall = function (ctx, args...) { ctx.cost += calcCost(args...); if (ctx.cost > ctx.costThreshold) { throw new TooExpensiveError(); } ... } }; 

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

एक अन्य विकल्प समग्र रूप से अनुरोध का प्रारंभिक विश्लेषण होगा। यह संभव है क्योंकि अनुरोध केवल डेटा है। लेकिन जटिल प्रश्नों का विश्लेषण करना एक कठिन काम हो सकता है, जिसकी कम्प्यूटेशनल जटिलता पर भी नजर रखनी होगी।

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

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

चरम मामले में, कई हैंडलर को केवल व्यक्तिगत रूप से उपयोग करने की अनुमति दी जा सकती है, या Date() बहुत ही आदिम कॉल के साथ संयोजन में। ये हैंडलर अनिवार्य रूप से परिचित मॉडल पर लौट आएंगे, जो अनुरोध में एक से अधिक कॉल की अनुमति नहीं देता है। कम्प्यूटेबल डेटा महान अवसर प्रदान करता है, लेकिन यदि आवश्यक हो, तो इसे सीमित करना आसान है।

JSON प्रतिनिधित्व

यदि आप अभी jsonex का उपयोग करना चाहते हैं, तो आप एक समस्या का सामना करेंगे - JSON के विपरीत, उच्च-प्रदर्शन jsonex पार्सिंग और क्रमांकन लाइब्रेरी, इसे हल्के ढंग से लगाने के लिए, अभी तक इतने व्यापक रूप से उपलब्ध नहीं हैं) लेकिन एक तरीका है कि आप JSON प्रतिनिधित्व के आधार पर jsonex का उपयोग कर सकते हैं। jsonex तीन सरल नियमों को लागू करके JSON में बदल जाता है:

 //   f(...) => {"?": ["f", ...]} //   '?' {'?': value, ...} => {"?": ["?", value], ...} //  ,    f({...}) => {"?": "f", ...} 

पहला नियम दिखाता है कि JSON प्रतिनिधित्व में कॉल नोटेशन कैसे लिखा जाता है। इसके अलावा, एक शब्दकोश संपत्ति है? ' विशेष महत्व प्राप्त करता है। दूसरा नियम इस सवाल का जवाब देता है कि संपत्ति के साथ एक नियमित शब्दकोश कैसे लिखा जाए? ' तो यह कॉल संकेतन के साथ भ्रमित करने के लिए नहीं। और तीसरा सिंटैक्टिक शुगर है, उन मामलों के लिए एक विशेष रूप से नोटेशन कॉल नोटेशन है जहां इसका एक ही तर्क है और यह तर्क एक शब्दकोश है। यहाँ jsonex में डेटा और JSON प्रतिनिधित्व में उनके डेटा का एक उदाहरण दिया गया है:

 Person({ //  Person name: 'John', dateOfBirth: Date('1901-01-01'), i: Complex(0, 1), d: { '?': 123 } }) 

JSON प्रतिनिधित्व:

 { "?": "Person", "name": "John", "dateOfBirth": {"?": ["Date", "1901-01-01"]}, "i": {"?": ["Complex", 0, 1]}, "d": {"?": ["?", 123]} } 

JSON प्रतिनिधित्व अधिक जटिल दिखता है, लेकिन एक ही बात को दर्शाता है। आप JSON.parse() मानक JSON.parse() कर सकते हैं, और फिर इसे दूसरे पास के साथ जोड़ सकते हैं। या, कुछ सरल मामलों में, इसे सीधे JSON.parse () को दिए गए रिवाइवर फ़ंक्शन का उपयोग करके पार्स करने के दौरान गणना की जा सकती है। वही JSON प्रतिनिधित्व में क्रमांकन के लिए जाता है - यह JSON.stringify () में उत्तीर्ण प्रतिकृति फ़ंक्शन का उपयोग करना आसान है।

सामान्यतया, कम्प्यूटेबल डेटा की अवधारणा को लगभग किसी भी डेटा प्रारूप के विस्तार के रूप में जोड़ा जा सकता है।

अतुल्यकालिक कॉल

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

 [ set('x', getUserBooks(17)), getAuthors(getProps(get('x'), 'authorId')), ] 

getUserBooks() और getAuthors() को संभवतः कुछ डेटा स्टोर पर जाना चाहिए, I / O का उपयोग करें और तदनुसार, अतुल्यकालिक हो। इसलिए हम मौके पर उनकी गणना नहीं कर सकते हैं। और यहां तक ​​कि अगर हम (उदाहरण के लिए, तंतुओं का उपयोग करके) कर सकते हैं, तो भी हम समानांतर में स्वतंत्र अतुल्यकालिक कॉल करने में सक्षम होना चाहेंगे, और एक के बाद एक नहीं।

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

लेकिन वास्तव में कार्य अधिक जटिल है। हमारे उदाहरण में, कुछ कॉल की गणना दूसरों पर निर्भर करती है; हम गणना नहीं कर सकते set()जब तक हम गणना नहीं करते getUserBooks()। इसलिए, जब कॉल करने की कोशिश की जा रही है set(), तो हमें इस गणना को स्थगित करना होगा, जिसमें उन सभी गणनाओं को इंगित किया जाएगा, जिन पर यह निर्भर करता है कि जैसे ही वे तैयार हों, उन्हें जोड़ना आवश्यक है set()। यहां हम ठीक एक आस्थगित गणना पर निर्भर करते हैं - getUserBooks()लेकिन अधिक जटिल निर्भरताएं संभव हैं।

लेकिन यह सब नहीं है।एक कॉल get()उपयोगी होने तक कुछ भी वापस करने में सक्षम नहीं है set()। इसलिए, get()यह एक विलंबित गणना भी बन जाना चाहिए, इस समय से एक संकेत के लिए इंतजार कर रहा है set()। बदले में, getProps()पर निर्भर करता है get(), लेकिन getAuthors()निर्भर करता है getProps()।

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

आर्क

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

इंजन के लिए स्रोत डेटा टोकन की एक धारा है। वर्तमान में, टोकन केवल JSON प्रतिनिधित्व के लिए उपलब्ध है, लेकिन सीधे jsonex के साथ काम करना कोने के चारों ओर है। आर्क Node.js के रूप में या ब्राउज़र में का उपयोग कर इस्तेमाल किया जा सकता browserify । चाप के लिए अतुल्यकालिक हैंडलर लिखना बहुत सरल लगता है, बस अतुल्यकालिक कॉल को उचित निर्देश में लपेटें, और इंजन हुड के नीचे सारी मेहनत करेगा:

 handlers.getUserBooks = function (ctx, userId) { return ctx.async(function (cb) { doSomethingAsync(...args, cb); }); }; 

जबकि केवल कॉलबैक समर्थित हैं, वादा समर्थन की योजना बनाई गई है। इंजन का उपयोग करने के उदाहरण, साथ ही jsonex में क्रमांकन और JSON प्रतिनिधित्व को संबंधित अनुभाग में देखा जा सकता है ।

अनुपूरक
आश्चर्य की बात है, शाब्दिक रूप से लेख पोस्ट किए जाने के कुछ घंटों बाद, चाप का एक विकल्प था । हब्रास मेयरोवप ने JSON प्रतिनिधित्व में jsonex को पार्स करने के लिए लाइब्रेरी के अपने संस्करण को प्रस्तुत किया। लाइब्रेरी के इस संस्करण में एक एकल फ़ाइल शामिल है, जिसमें कोई निर्भरता नहीं है, मानक एक का उपयोग करता है JSON.parse()और ए + वादा का समर्थन करता है । दुर्भाग्य से सीमाओं के कारणJSON.parse(), इस कार्यान्वयन में, अतुल्यकालिक कॉल प्रसंस्करण इतना कुशल नहीं होगा, इसलिए इसे काट दिया जाता है। यहाँ jQuery के साथ एक वैकल्पिक पुस्तकालय का उपयोग कर एक उदाहरण दिया गया है:

 var parser = new JSONEX.parser({ allow_async: true, functions: { Foo: function() { var result = $.Deferred(); setTimeout(function() { result.resolve("Hello, world!"); }, 1000); return result.promise(); } }}); $.when(parser.parse('[{"?": ["Foo"]}]')) .done(function(result) { console.log(result); }); 

निष्कर्ष

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

प्रस्तुत विचारों की नवीनता और गैर-रोलिंग प्रकृति के कारण, मैं एक निश्चित मात्रा में सावधानी के साथ उनका उपयोग करने की सलाह दूंगा। फिर भी, मुझे बहुत खुशी होगी यदि आप उनमें से कुछ को पसंद करते हैं और आपकी परियोजनाओं और प्रयोगों में उपयोगी होंगे। यदि आप अपने छापों, अनुभवों और खोजों को साझा करते हैं तो मैं भी आभारी रहूंगा।