🙌🏽 ⛓️ 🔤 लारवेल में मिडिलवेयर और पाइपलाइन सुविधाएँ 🤗 🚓 👨🏾‍🤝‍👨🏻

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

और आज हम प्रोग्रामर द्वारा इनमें से किसी एक टूल या इसके उपयोग और कार्यान्वयन पर ध्यान केंद्रित करेंगे। पूर्ण प्रलेखन की कमी, साथ ही साथ रूसी-भाषा के लेखों की कमी और बहुत कम संख्या में विदेशी लेखों ने मुझे रूपरेखा के इस दिलचस्प विशेषता के बारे में गोपनीयता की एक निश्चित घूंघट को प्रकट करने का निर्णय लेने के लिए प्रेरित किया और इस विषय को Habré पर मेरे पहले लेख के रूप में चुना।

middleware

यह लेख मानता है कि पाठक पहले से ही ढांचे की इस कार्यक्षमता के मूल उपयोग से परिचित है, इसलिए मैं इस बिंदु पर लंबे समय तक नहीं रहूंगा।

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

Laravel में इस घटक के मानक उपयोगकर्ता मामलों के उदाहरण हैं: EncryptCookies / RedirectIfAuthenticated / VerifyCsrfToken , और कस्टम कार्यान्वयन के एक उदाहरण के रूप में, आप अनुरोध को स्थानांतरित करने से पहले मिडलवेयर एप्लिकेशन स्थानीयकरण (कुछ अनुरोध डेटा पर आधारित आवश्यक स्थानीयकरण सेट करना) का हवाला दे सकते हैं।

रसातल में कूदा

यहां आने वाले सभी को उम्मीद छोड़ दें

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

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

मिडिलवेयर - बैरिकेड्स के पार

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

सिस्टम में पहले से निर्मित व्यवहार का अध्ययन करने के अलावा, एक घटक के व्यवहार का अध्ययन करने से बेहतर क्या हो सकता है? शायद कुछ हो सकता है, लेकिन हम अनावश्यक जटिलताओं के बिना करेंगे और मानक मिडलवेयर के साथ अपना विश्लेषण शुरू करेंगे - अर्थात्, पूरे गिरोह के सबसे सरल और सबसे समझ में आने वाले - RedirectIfAuthenticated :

RedirectIfAuthenticated.php

class RedirectIfAuthenticated { /**      * Handle an incoming request. * * @param \Illuminate\Http\Request $request * @param \Closure $next * @param string|null $guard * @return mixed */ public function handle($request, Closure $next, $guard = null) { if (Auth::guard($guard)->check()) { return redirect('/'); } return $next($request); } }

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

यदि हम इस मिडलवेयर के पंजीकरण को ऐप / Http / Kernel.php में देखते हैं, तो हम देखेंगे कि यह 'मार्ग मिडलवेयर' में पंजीकृत है। हमारे लिए यह पता लगाने के लिए कि सिस्टम इस मिडलवेयर के साथ कैसे काम करता है, आइए उस वर्ग पर जाएं जहां से हमारा ऐप / Http / कर्नेल विरासत में मिला है - और यह Illuminate \ Foundation \ Http \ कर्नेल वर्ग से विरासत में मिला है। इस स्तर पर, हम सीधे अपने ढांचे के स्रोत कोड को ~~नरक में~~ खोलने के लिए, या इसके सबसे महत्वपूर्ण और मुख्य भाग के लिए - HTTP के साथ काम करने के मूल में खुलेंगे। वैसे, कौन परवाह करता है - लारवेल सिम्फनी के कई घटकों पर आधारित है, विशेष रूप से इस भाग में - HttpFoundation और HttpKernel पर ।

कर्नेल कंस्ट्रक्टर में हमारे मिडलवेयर की परिभाषा और कार्यान्वयन इस प्रकार है:

Illuminate \ Foundation \ Http \ K कर्नेल (एप्लिकेशन $ एप्लिकेशन, राउटर $ राउटर)

  /**    HTTP Kernel . * Create a new HTTP kernel instance. * * @param \Illuminate\Contracts\Foundation\Application $app * @param \Illuminate\Routing\Router $router * @return void */ public function __construct(Application $app, Router $router) { $this->app = $app; $this->router = $router; $router->middlewarePriority = $this->middlewarePriority; foreach ($this->middlewareGroups as $key => $middleware) { $router->middlewareGroup($key, $middleware); } foreach ($this->routeMiddleware as $key => $middleware) { $router->aliasMiddleware($key, $middleware); } }

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

क्या हम वास्तव में रुचि रखते हैं SendRequestThroughRoute विधि है, जो शाब्दिक रूप से अनुवाद के माध्यम से एक अनुरोध भेजने के लिए अनुवाद करता है :

Illuminate \ Foundation \ Http \ K गिरी :: sendRequestThroughRouter ($ अनुरोध)

  /**     middleware / router. * Send the given request through the middleware / router. * * @param \Illuminate\Http\Request $request * @return \Illuminate\Http\Response */ protected function sendRequestThroughRouter($request) { // *    * return (new Pipeline($this->app)) ->send($request) ->through($this->app->shouldSkipMiddleware() ? [] : $this->middleware) ->then($this->dispatchToRouter()); }

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

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

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

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

पाइपलाइन - हमारे आवेदन का सीवरेज

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

नामस्थान के साथ वर्ग अपनी पूरी परिभाषा के द्वारा पाया जा सकता है:

रोशन \ Pipeline \ Pipeline

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

लारवेल में नमूना कार्यान्वयन

हम वास्तविकता क्वेरी श्रृंखला से सबसे सरल और रिमोट लागू करते हैं। हम डेटा के रूप में स्ट्रिंग "हेलो वर्ल्ड" का उपयोग करेंगे, और दो हैंडलर की मदद से हम स्ट्रिंग "हेलो यूजर" बनाएंगे। कोड जानबूझकर सरलीकृत किया गया है।

हमारे अपने "पाइप" के तत्काल कार्यान्वयन से पहले, हमें इस पाइप के तत्वों की पहचान करने की आवश्यकता है। तत्वों को सादृश्य द्वारा लिखित हैं:

परिभाषित करने वाले हैंडलर

StrToLowerAction.php:

 use Closure; class StrToLowerAction { /** * Handle an incoming request. * * @param string $content * @param Closure $next * @return mixed */ public function handle(string $content, Closure $next) { $content = strtolower($content); return $next($content); } }

SetUserAction.php:

 use Closure; class SetUserAction { /** * Handle an incoming request. * * @param string $content * @param Closure $next * @return mixed */ public function handle(string $content, Closure $next) { $content = ucwords(str_replace('world', 'user', $content)); return $next($content); } }

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

 $pipes = [ StrToLowerAction::class, SetUserNameAction::class ]; $data = 'Hello world'; $finalData = app(Pipeline::class) ->send($data) // ,       ->through($pipes) //   ->then(function ($changedData) { return $changedData; //  ,    }); var_dump($finalData); //      $finalData

इसके अलावा, यदि आपको हैंडलर में अपनी खुद की विधि को परिभाषित करने की इच्छा या आवश्यकता है, तो पाइपलाइन इंटरफ़ेस एक विशेष विधि ('method_name') विधि प्रदान करता है, तो चेन प्रोसेसिंग इस तरह से लिखी जा सकती है:

 $finalData = app(Pipeline::class) ->send($data) ->through($pipes) ->via('handle') //      ,         ->then(function ($changedData) { return $changedData; });

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

निष्कर्ष

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

फ्रेमवर्क की इस विशेषता का विशेष रूप से उपयोग कैसे करें, यह आपके द्वारा सौंपे गए कार्यों पर निर्भर करता है।

लारवेल में मिडिलवेयर और पाइपलाइन सुविधाएँ