रेल 4 में स्ट्रीमिंग

स्ट्रीमिंग क्या है?

स्ट्रीमिंग 3.2 संस्करण के बाद से रेल के आसपास रही है, लेकिन यह विशेष रूप से टेम्पलेट स्ट्रीमिंग तक सीमित थी। रेल 4 अधिक परिपक्व वास्तविक समय स्ट्रीमिंग कार्यक्षमता के साथ आया था। संक्षेप में, इसका मतलब है कि रेल अब I / O ऑब्जेक्ट को मूल रूप से संसाधित करने और वास्तविक समय में क्लाइंट को डेटा भेजने में सक्षम है।

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

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

स्ट्रीमिंग टेम्पलेट्स

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

एक कार्रवाई पर विचार करें, जो बहुत सारे अनुरोध करता है, उदाहरण के लिए:

 class TimelineController def index @users = User.all @tickets = Ticket.all @attachments = Attachment.all end end 

इस मामले में, स्ट्रीमिंग अच्छी है। यह रेल के लिए एक सामान्य स्थिति है, पृष्ठ सामान्य से अधिक समय तक लोड होता है, क्योंकि आपको पहले सभी डेटा प्राप्त करने की आवश्यकता होती है।

आइए स्ट्रीमिंग जोड़ें:

 class TimelineController def index @users = User.all @tickets = Ticket.all @attachments = Attachment.all render stream: true end end 

render stream: true मेथड आलसी सभी अनुरोधों को लोड करेगा और एसेट्स और लेआउट रेंडर होने के बाद उन्हें निष्पादित करने की अनुमति देगा। स्ट्रीमिंग टेम्पलेट्स और केवल उनके साथ काम करता है (लेकिन json या xml के साथ नहीं)। यह पृष्ठ के प्रकार और इसकी सामग्री के आधार पर टेम्पलेट्स को प्राथमिकता देने का एक अच्छा तरीका प्रदान करता है।

अंदर कुछ जोड़ें

स्ट्रीम करने से टेम्पलेट और लेआउट के तरीके में परिवर्तन होता है, जो तार्किक प्रश्न की ओर जाता है: उदाहरण के लिए टेम्प्लेट में वेरिएबल के उपयोग के बारे में क्या?

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

इसलिए, शीर्षक और मेटा जैसी विशेषताओं को लोड करने के लिए, आपको सामान्य yield बजाय content_for का उपयोग करना होगा। हालांकि, yield अभी भी शरीर के लिए काम करेगी।

पहले, हमारी विधि कुछ इस तरह दिखती थी:

 <%= yield :title %> 

अब यह इस तरह दिखेगा:

 <%= content_for :title, "My Awesome Title" %> 

लाइव एपीआई के साथ लाइव हो रही है

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

चूँकि हम स्ट्रीमिंग और कॉन्सेप्ट के संदर्भ में काम करते हैं, WEBrick यहाँ हमारा मित्र नहीं है। हम प्यूमा का उपयोग करेंगे क्योंकि यह जानता है कि कैसे धाराओं के साथ काम करना है।

Gemfile में एक प्यूमा जोड़ें और बंडल चलाएं।

 gem "puma" 

 :~/testapp$ bundle install 

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

 :~/testapp$ rails s => Booting Puma => Rails 4.0.0 application starting in development on http://0.0.0.0:3000 => Run `rails server -h` for more startup options => Ctrl-C to shutdown server Puma 2.3.0 starting... * Min threads: 0, max threads: 16 * Environment: development * Listening on tcp://0.0.0.0:3000 

संदेश भेजने के लिए जल्दी से एक नियंत्रक उत्पन्न करते हैं।

 :~/testapp$ rails g controller messaging 

और उन्हें स्ट्रीम करने के लिए एक सरल विधि जोड़ें।

 class MessagingController < ApplicationController include ActionController::Live def send_message response.headers['Content-Type'] = 'text/event-stream' 10.times { response.stream.write "This is a test Message\n" sleep 1 } response.stream.close end end 

मार्गों में एक मार्ग जोड़ें।

 get 'messaging' => 'messaging#send_message' 

अब हम उदाहरण के लिए कर्ल का उपयोग करके स्ट्रीम तक पहुंच सकते हैं:

 :~/testapp$ curl -i http://localhost:3000/messaging HTTP/1.1 200 OK X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff X-UA-Compatible: chrome=1 Content-Type: text/event-stream Cache-Control: no-cache Set-Cookie: request_method=GET; path=/ X-Request-Id: 68c6b7c7-4f5f-46cc-9923-95778033eee7 X-Runtime: 0.846080 Transfer-Encoding: chunked This is a test message This is a test message This is a test message This is a test message 

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

आइए एक फ़ॉर्म बनाएं और देखें कि क्या हम किसी डेटा को दृश्य में भेज सकते हैं:

 def send_message response.headers['Content-Type'] = 'text/event-stream' 10.times { response.stream.write "#{params[:message]}\n" sleep 1 } response.stream.close end 

हम एक स्ट्रीम में डेटा भेजने के लिए एक फॉर्म बनाते हैं:

 <%= form_tag messaging_path, :method => 'get' do %> <%= text_field_tag :message, params[:message] %> <%= submit_tag "Post Message" %> <% end %> 

और मार्ग को कॉन्फ़िगर करें:

 get 'messaging' => 'messaging#send_message', :as => 'messaging' 

जैसे ही आप एक संदेश दर्ज करते हैं और "पोस्ट संदेश" पर क्लिक करते हैं, ब्राउज़र को एक डाउनलोड करने योग्य पाठ फ़ाइल के रूप में एक स्ट्रीमिंग प्रतिक्रिया मिलेगी जिसमें आपका संदेश 10 बार लॉग इन होता है।



यहां, हालांकि, स्ट्रीम को यह नहीं पता है कि डेटा कहां और किस प्रारूप में भेजा जाए, इसलिए वह इसे सर्वर पर एक टेक्स्ट फाइल पर लिखता है।

आप मापदंडों को पार करके कर्ल के साथ ऑपरेशन का परीक्षण भी कर सकते हैं:

 :~/testapp$ curl -i http://localhost:3000/messaging?message="awesome" HTTP/1.1 200 OK X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff X-UA-Compatible: chrome=1 Content-Type: text/event-stream Cache-Control: no-cache Set-Cookie: request_method=GET; path=/ X-Request-Id: 382bbf75-7d32-47c4-a767-576ec59cc364 X-Runtime: 0.055470 Transfer-Encoding: chunked awesome awesome 

सर्वर साइड इवेंट

HTML5 सर्वर साइड इवेंट्स (SSE) नामक एक विधि प्रदान करता है। SSE एक ब्राउज़र-आधारित विधि है जो सर्वर द्वारा डेटा भेजने पर हर बार घटनाओं को पहचानता है और चलाता है।

हम सर्वर और क्लाइंट के बीच दो-तरफ़ा संचार स्थापित करने के लिए Live API के साथ संयोजन में SSE का उपयोग कर सकते हैं।

डिफ़ॉल्ट रूप से, रेल केवल एकतरफा संचार प्रदान करता है - यह आपको ग्राहक के लिए डेटा उपलब्ध कराने की अनुमति देता है जैसे ही यह उपलब्ध हो जाता है। हालाँकि, यदि हम SSE जोड़ते हैं, तो हम दो तरफ़ा मोड में घटनाओं और प्रतिक्रियाओं का उपयोग कर सकते हैं।

एक साधारण SSE कुछ इस तरह दिखता है:

 require 'json' module ServerSide class SSE def initialize io @io = io end def write object, options = {} options.each do |k,v| @io.write "#{k}: #{v}\n" end @io.write "data: #{object}\n\n" end def close @io.close end end end 

यह मॉड्यूल एक हैश में एक I / O स्ट्रीम ऑब्जेक्ट प्राप्त करता है और इसे एक कुंजी-मूल्य जोड़ी में परिवर्तित करता है ताकि इसे JSON प्रारूप में आसानी से पढ़ा, संग्रहीत और भेजा जा सके।

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

 require 'server_side/sse' class MessagingController < ApplicationController include ActionController::Live def stream response.headers['Content-Type'] = 'text/event-stream' sse = ServerSide::SSE.new(response.stream) begin loop do sse.write({ :message => "#{params[:message]}" }) sleep 1 end rescue IOError ensure sse.close end end end 

यह कोड इस तरह से एक जवाब देगा:

 :~/testapp$ curl -i http://localhost:3000/messaging?message="awesome" HTTP/1.1 200 OK X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff X-UA-Compatible: chrome=1 Content-Type: text/event-stream Cache-Control: no-cache Set-Cookie: request_method=GET; path=/ X-Request-Id: b922a2eb-9358-429b-b1bb-015421ab8526 X-Runtime: 0.067414 Transfer-Encoding: chunked data: {:message=>"awesome"} data: {:message=>"awesome"} 

नुकसान

सावधान रहें, कुछ नुकसान हैं (जहां तब उनके बिना):

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

निष्कर्ष

यह एक ऐसा अवसर है जो कई लोग लंबे समय से रेल की तलाश में हैं, क्योंकि यह एप्लिकेशन प्रदर्शन (स्ट्रीमिंग टेम्प्लेट) को काफी बढ़ा सकता है और नोड.जेएस (लाइव) के साथ गंभीरता से प्रतिस्पर्धा कर सकता है।

कुछ पहले से ही बेंचमार्क का संचालन कर रहे हैं, तुलना कर रहे हैं, लेकिन मुझे लगता है कि यह केवल शुरुआत है और इस सुविधा को समाप्त करने के लिए समय (कुछ रिलीज पढ़ना) पास करना होगा, इसलिए बोलना है। अब यह एक अच्छी शुरुआत है और कार्रवाई में सब कुछ करने का एक रोमांचक अवसर है।

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

मूल यहाँ है ।