जंग में सामान्य तरीके: कैसे एक्सोनम को लोहे से एक्टिक्स-वेब में स्थानांतरित किया गया

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

लोहे पर एक्सोनम

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

इस प्रक्रिया को निम्नलिखित की तरह देखा गया (लगभग):

fn set_blocks_response(self, router: &mut Router) { let blocks = move |req: &mut Request| -> IronResult<Response> { let count: usize = self.required_param(req, "count")?; let latest: Option<u64> = self.optional_param(req, "latest")?; let skip_empty_blocks: bool = self.optional_param(req, "skip_empty_blocks")? .unwrap_or(false); let info = self.blocks(count, latest.map(Height), skip_empty_blocks)?; self.ok_response(&::serde_json::to_value(info).unwrap()) }; router.get("/v1/blocks", blocks, "blocks"); } 

इसके अलावा, हमने कॉर्स हेडर के रूप में कुछ मिडलवेयर प्लगइन्स का उपयोग किया। हमने सभी हैंडलर को एक ही एपीआई में मर्ज करने के लिए माउंट का उपयोग किया है।

आयरन से दूर शिफ्ट करने का हमारा निर्णय

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

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

व्हाई वी चोज एक्टिक्स-वेब

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

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

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

वेब फ्रेमवर्क से हमें क्या चाहिए

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

यह समझने के लिए कि इस दृश्य को देखने की क्या आवश्यकता है, आइए परिभाषित करें कि वास्तव में कोई HTTP एपीआई क्या है:

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

यदि हम सभी अमूर्त परतों का विश्लेषण करते हैं, तो यह पता चलता है कि कोई HTTP अनुरोध केवल एक फ़ंक्शन कॉल है:

 fn request(context: &ServiceContext, query: Query) -> Result<Response, ServiceError> 

बाकी सब कुछ इस मूल इकाई का विस्तार माना जा सकता है। इस प्रकार, एक वेब फ्रेमवर्क के एक विशिष्ट कार्यान्वयन से स्वतंत्र होने के लिए, हमें ऊपर के उदाहरण के समान शैली में हैंडलर लिखने की आवश्यकता है।

HTTP- रिक्वेस्ट के जेनेरिक प्रोसेसिंग के लिए Trait `Endpoint`

सबसे सरल और सीधा दृष्टिकोण `एंडपॉइंट 'विशेषता को घोषित करेगा, जो विशिष्ट अनुरोधों के कार्यान्वयन का वर्णन करता है:

 // A trait describing GET request handlers. It should be possible to call each of the handlers from any freed // thread. This requirement imposes certain restrictions on the trait. Parameters and request results are // configured using associated types. trait Endpoint: Sync + Send + 'static { type Request: DeserializeOwned + 'static; type Response: Serialize + 'static; fn handle(&self, context: &Context, request: Self::Request) -> Result<Self::Response, io::Error>; } 

अब हमें इस हैंडलर को एक विशिष्ट ढांचे में लागू करने की आवश्यकता है। उदाहरण के लिए, एक्टिक्स-वेब में यह निम्नलिखित की तरह दिखता है:

 // Response type in actix-web. Note that they are asynchronous, even though `Endpoint` assumes that // processing is synchronous. type FutureResponse = actix_web::FutureResponse<HttpResponse, actix_web::Error>; // A raw request handler for actix-web. This is what the framework ultimately works with. The handler // receives parameters from an arbitrary context, through which the request parameters are passed. type RawHandler = dyn Fn(HttpRequest<Context>) -> FutureResponse + 'static + Send + Sync; // For convenience, let's put everything we need from the handler into a single structure. #[derive(Clone)] struct RequestHandler { /// The name of the resource. pub name: String, /// HTTP method. pub method: actix_web::http::Method, /// The raw handler. Note that it will be used from multiple threads. pub inner: Arc<RawHandler>, } 

हम संदर्भ के माध्यम से अनुरोध पैरामीटर पारित करने के लिए संरचनाओं का उपयोग कर सकते हैं। एक्टिक्स-वेब सर्ड का उपयोग करके स्वचालित रूप से मापदंडों को डिसेरलाइज़ कर सकता है। उदाहरण के लिए, एक = 15 और बी = हैलो इस तरह एक संरचना में deserialized है:

 #[derive(Deserialize)] struct SimpleQuery { a: i32, b: String, } 

यह deserialization कार्यक्षमता संबद्ध प्रकार के अनुरोध के साथ `समापन बिंदु` विशेषता से अच्छी तरह से सहमत है।

इसके बाद, एक एडेप्टर को विकसित करने देता है जो एक्टिक्स-वेब के लिए एक रिक्वेन्डरलर में `एंडपॉइंट 'के विशिष्ट कार्यान्वयन को लपेटता है। इस तथ्य पर ध्यान दें कि ऐसा करते समय, अनुरोध और प्रतिक्रिया के प्रकार की जानकारी गायब हो जाती है। इस तकनीक को टाइप इरेज़र कहा जाता है - यह स्टेटिक डिस्पैचिंग को डायनामिक में बदल देती है।

 impl RequestHandler { fn from_endpoint<E: Endpoint>(name: &str, endpoint: E) -> RequestHandler { let index = move |request: HttpRequest<Context>| -> FutureResponse { let context = request.state(); let future = Query::from_request(&request, &()) .map(|query: Query<E::Request>| query.into_inner()) .and_then(|query| endpoint.handle(context, query).map_err(From::from)) .and_then(|value| Ok(HttpResponse::Ok().json(value))) .into_future(); Box::new(future) }; Self { name: name.to_owned(), method: actix_web::http::Method::GET, inner: Arc::from(index) as Arc<RawHandler>, } } } 

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

`समापन बिंदु` विशेषता की कमियां

एक हैंडलर लिखे जाने पर सहायक कोड की एक बड़ी मात्रा उत्पन्न होती है:

 // A structure with the context of the handler. struct ElementCountEndpoint { elements: Rc<RefCell<Vec<Something>>>, } // Implementation of the `Endpoint` trait. impl Endpoint for ElementCountEndpoint { type Request = (); type Result = usize; fn handle(&self, context: &Context, _request: ()) -> Result<usize, io::Error> { Ok(self.elements.borrow().len()) } } // Installation of the handler in the backend. let endpoint = ElementCountEndpoint::new(elements.clone()); let handler = RequestHandler::from_endpoint("/v1/element_count", endpoint); actix_backend.endpoint(handler); 

आदर्श रूप से, हमें एक हैंडलर के रूप में एक सरल क्लोजर पास करने में सक्षम होना चाहिए, इस प्रकार सिंटैक्टिक शोर की मात्रा को कम करना चाहिए।

 let elements = elements.clone(); actix_backend.endpoint("/v1/elements_count", move || { Ok(elements.borrow().len()) }); 

नीचे हम चर्चा करेंगे कि यह कैसे किया जा सकता है।

जेनेरिक प्रोग्रामिंग में लाइट विसर्जन

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

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

इसके अलावा, क्लोजर वैल्यू का लौटा हुआ प्रकार `एंडपॉइंट` के कार्यान्वयन के लौटे मूल्य से मेल नहीं खाता है। इस प्रकार में हेरफेर करने के लिए, इसे प्राप्त क्लोजर के प्रकार से निकाला जाना चाहिए।

`Fn` विशेषता से प्राप्त प्रकार

जंग में, प्रत्येक बंद का अपना अलग प्रकार होता है, जिसे कार्यक्रम में स्पष्ट रूप से इंगित नहीं किया जा सकता है। क्लोजर के साथ जोड़तोड़ के लिए, हम `Fn` विशेषता का उपयोग करते हैं। विशेषता में तर्कों के प्रकार और लौटाए गए मान के साथ फ़ंक्शन के हस्ताक्षर होते हैं, हालांकि, इन तत्वों को अलग से पुनर्प्राप्त करना आसानी से नहीं होता है।

मुख्य विचार निम्नलिखित फॉर्म की एक सहायक संरचना का उपयोग करना है:

 /// Simplified example of extracting types from an F closure: Fn(A) -> B. struct SimpleExtractor<A, B, F> { // The original function. inner: F, _a: PhantomData<A>, _b: PhantomData<B>, } 

हमें फैंटमडाटा का उपयोग करना होगा, क्योंकि जंग के लिए आवश्यक है कि संरचना की परिभाषा में सभी सामान्य मापदंडों को इंगित किया जाए। हालाँकि, क्लोजर या फंक्शन F का प्रकार स्वयं एक जेनेरिक नहीं है (हालाँकि यह एक जेनेरिक `Fn` ट्रैस को लागू करता है)। ए और बी प्रकार के मापदंडों का इसमें सीधे उपयोग नहीं किया जाता है।

यह रस्ट टाइप सिस्टम का यह प्रतिबंध है जो हमें क्लोजर के लिए सीधे 'एंडपॉइंट' विशेषता लागू करके एक सरल रणनीति लागू करने से रोकता है:

 impl<A, B, F> Endpoint for F where F: Fn(&Context, A) -> B { type Request = A; type Response = B; fn handle(&self, context: &Context, request: A) -> Result<B, io::Error> { // ... } } 

उपरोक्त मामले में, कंपाइलर एक त्रुटि देता है:

 error[E0207]: the type parameter `A` is not constrained by the impl trait, self type, or predicates --> src/main.rs:10:6 | 10 | impl<A, B, F> Endpoint for F where F: Fn(&Context, A) -> B { | ^ unconstrained type parameter 

सहायक संरचना SimpleExtractor `From` के रूपांतरण का वर्णन करना संभव बनाता है। यह रूपांतरण हमें किसी भी फ़ंक्शन को बचाने और इसके तर्कों के प्रकार को निकालने की अनुमति देता है:

 impl<A, B, F> From<F> for SimpleExtractor<A, B, F> where F: Fn(&Context, A) -> B, A: DeserializeOwned, B: Serialize, { fn from(inner: F) -> Self { SimpleExtractor { inner, _a: PhantomData, _b: PhantomData, } } } 

निम्नलिखित कोड सफलतापूर्वक संकलित करता है:

 #[derive(Deserialize)] struct Query { a: i32, b: String, }; // Verification of the ordinary structure. fn my_handler(_: &Context, q: Query) -> String { format!("{} has {} apples.", qb, qa) } let fn_extractor = SimpleExtractor::from(my_handler); // Verification of the closure. let c = 15; let my_closure = |_: &Context, q: Query| -> String { format!("{} has {} apples, but Alice has {}", qb, qa, c) }; let closure_extractor = SimpleExtractor::from(my_closure); 

विशेषज्ञता और मार्कर के प्रकार

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

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

 /// Generic handler for HTTP-requests. pub struct With<Q, I, R, F> { /// A specific handler function. pub handler: F, /// Structure type containing the parameters of the request. _query_type: PhantomData<Q>, /// Type of the request result. _item_type: PhantomData<I>, /// Type of the value returned by the handler. /// Note that this value can differ from the result of the request. _result_type: PhantomData<R>, } // Implementation of an ordinary synchronous returned value. impl<Q, I, F> From<F> for With<Q, I, Result<I>, F> where F: Fn(&ServiceApiState, Q) -> Result<I>, { fn from(handler: F) -> Self { Self { handler, _query_type: PhantomData, _item_type: PhantomData, _result_type: PhantomData, } } } // Implementation of an asynchronous request handler. impl<Q, I, F> From<F> for With<Q, I, FutureResult<I>, F> where F: Fn(&ServiceApiState, Q) -> FutureResult<I>, { fn from(handler: F) -> Self { Self { handler, _query_type: PhantomData, _item_type: PhantomData, _result_type: PhantomData, } } } 

अब हमें संरचना को घोषित करने की आवश्यकता है जो अनुरोधकर्ता को उसके नाम और प्रकार के साथ जोड़ देगा:

 #[derive(Debug)] pub struct NamedWith<Q, I, R, F, K> { /// The name of the handler. pub name: String, /// The handler with the extracted types. pub inner: With<Q, I, R, F>, /// The type of the handler. _kind: PhantomData<K>, } 

अगला, हम कई खाली संरचनाओं की घोषणा करते हैं जो मार्कर प्रकारों के रूप में कार्य करेंगे। मार्कर हमें हैंडलर को पहले से वर्णित RequestHandler में बदलने के लिए अपने स्वयं के कोड को लागू करने की अनुमति देंगे।

 /// A handler that does not change the state of the service. In HTTP, GET-requests correspond to this // handler. pub struct Immutable; /// A handler that changes the state of the service. In HTTP, POST, PUT, UPDATE and other similar //requests correspond to this handler, but for the current case POST will suffice. pub struct Mutable; 

अब हम टेम्पलेट पैरामीटर R और K के सभी संयोजनों के लिए `From` विशेषता के चार अलग-अलग कार्यान्वयनों को परिभाषित कर सकते हैं (हैंडलर का वापसी मूल्य और अनुरोध का प्रकार)।

 // Implementation of a synchronous handler of GET requests. impl<Q, I, F> From<NamedWith<Q, I, Result<I>, F, Immutable>> for RequestHandler where F: Fn(&ServiceApiState, Q) -> Result<I> + 'static + Send + Sync + Clone, Q: DeserializeOwned + 'static, I: Serialize + 'static, { fn from(f: NamedWith<Q, I, Result<I>, F, Immutable>) -> Self { let handler = f.inner.handler; let index = move |request: HttpRequest| -> FutureResponse { let context = request.state(); let future = Query::from_request(&request, &()) .map(|query: Query<Q>| query.into_inner()) .and_then(|query| handler(context, query).map_err(From::from)) .and_then(|value| Ok(HttpResponse::Ok().json(value))) .into_future(); Box::new(future) }; Self { name: f.name, method: actix_web::http::Method::GET, inner: Arc::from(index) as Arc<RawHandler>, } } } // Implementation of a synchronous handler of POST requests. impl<Q, I, F> From<NamedWith<Q, I, Result<I>, F, Mutable>> for RequestHandler where F: Fn(&ServiceApiState, Q) -> Result<I> + 'static + Send + Sync + Clone, Q: DeserializeOwned + 'static, I: Serialize + 'static, { fn from(f: NamedWith<Q, I, Result<I>, F, Mutable>) -> Self { let handler = f.inner.handler; let index = move |request: HttpRequest| -> FutureResponse { let handler = handler.clone(); let context = request.state().clone(); request .json() .from_err() .and_then(move |query: Q| { handler(&context, query) .map(|value| HttpResponse::Ok().json(value)) .map_err(From::from) }) .responder() }; Self { name: f.name, method: actix_web::http::Method::POST, inner: Arc::from(index) as Arc<RawHandler>, } } } // Implementation of an asynchronous handler of GET requests. impl<Q, I, F> From<NamedWith<Q, I, FutureResult<I>, F, Immutable>> for RequestHandler where F: Fn(&ServiceApiState, Q) -> FutureResult<I> + 'static + Clone + Send + Sync, Q: DeserializeOwned + 'static, I: Serialize + 'static, { fn from(f: NamedWith<Q, I, FutureResult<I>, F, Immutable>) -> Self { let handler = f.inner.handler; let index = move |request: HttpRequest| -> FutureResponse { let context = request.state().clone(); let handler = handler.clone(); Query::from_request(&request, &()) .map(move |query: Query<Q>| query.into_inner()) .into_future() .and_then(move |query| handler(&context, query).map_err(From::from)) .map(|value| HttpResponse::Ok().json(value)) .responder() }; Self { name: f.name, method: actix_web::http::Method::GET, inner: Arc::from(index) as Arc<RawHandler>, } } } // Implementation of an asynchronous handler of POST requests. impl<Q, I, F> From<NamedWith<Q, I, FutureResult<I>, F, Mutable>> for RequestHandler where F: Fn(&ServiceApiState, Q) -> FutureResult<I> + 'static + Clone + Send + Sync, Q: DeserializeOwned + 'static, I: Serialize + 'static, { fn from(f: NamedWith<Q, I, FutureResult<I>, F, Mutable>) -> Self { let handler = f.inner.handler; let index = move |request: HttpRequest| -> FutureResponse { let handler = handler.clone(); let context = request.state().clone(); request .json() .from_err() .and_then(move |query: Q| { handler(&context, query) .map(|value| HttpResponse::Ok().json(value)) .map_err(From::from) }) .responder() }; Self { name: f.name, method: actix_web::http::Method::POST, inner: Arc::from(index) as Arc<RawHandler>, } } } 

बैकएंड के लिए मुखौटा

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

 pub struct ServiceApiScope { actix_backend: actix::ApiBuilder, } impl ServiceApiScope { /// This method adds an Immutable handler to all backends. pub fn endpoint<Q, I, R, F, E>(&mut self, name: &'static str, endpoint: E) -> &mut Self where // Here we list the typical restrictions which we have encountered earlier: Q: DeserializeOwned + 'static, I: Serialize + 'static, F: Fn(&ServiceApiState, Q) -> R + 'static + Clone, E: Into<With<Q, I, R, F>>, // Note that the list of restrictions includes the conversion from NamedWith into RequestHandler // we have implemented earlier. RequestHandler: From<NamedWith<Q, I, R, F, Immutable>>, { self.actix_backend.endpoint(name, endpoint); self } /// A similar method for Mutable handlers. pub fn endpoint_mut<Q, I, R, F, E>(&mut self, name: &'static str, endpoint: E) -> &mut Self where Q: DeserializeOwned + 'static, I: Serialize + 'static, F: Fn(&ServiceApiState, Q) -> R + 'static + Clone, E: Into<With<Q, I, R, F>>, RequestHandler: From<NamedWith<Q, I, R, F, Mutable>>, { self.actix_backend.endpoint_mut(name, endpoint); self } 

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

दृष्टिकोण की कमियां

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

एक और मुद्दा यह है कि हम अतिरिक्त तर्क के बिना किसी हैंडलर की विशेषज्ञता को परिभाषित नहीं कर सकते । दूसरे शब्दों में, यदि हम निम्नलिखित कोड लिखते हैं, तो इसे संकलित नहीं किया जाएगा क्योंकि यह मौजूदा जेनेरिक कार्यान्वयन के विरोध में है:

 impl<(), I, F> From<F> for With<(), I, Result<I>, F> where F: Fn(&ServiceApiState) -> Result<I>, { fn from(handler: F) -> Self { Self { handler, _query_type: PhantomData, _item_type: PhantomData, _result_type: PhantomData, } } } 

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

इसी प्रकार, लौटाए गए मान का प्रकार विशिष्ट नहीं हो सकता । भले ही अनुरोध एक निश्चित प्रकार का लौटाया गया मान न हो, फिर भी यह JSON को अशक्त कर देगा।

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

निष्कर्ष

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

---

• वेब: Bitfury.com , Exonum.com
• सोशल मीडिया: फेसबुक , ट्विटर , लिंक्डइन
• अनुसंधान एवं विकास: अनुसंधान और श्वेत पत्र

---