Django में WebSocket जोड़ने का सबसे आसान तरीका

अनुवादक का ध्यान दें: वेब सॉकेट और Django एक जटिल विषय है, जिसे एक बार हब्रहाब्र पर एक से अधिक बार उठाया गया है और मुख्य विचार वेब सॉकेट के लिए एक समानांतर बैकेंड लिखना है। लेखक इस समस्या का एक संक्षिप्त समाधान प्रदान करता है, जिसका सत्य अभी भी समय का परीक्षण है।

टीएल; डीआर - मैं Django में वेब सॉकेट के साथ काम करने के लिए एक बहुत ही सरल समाधान के साथ आया था। आपको बस django-websocket-request स्थापित करना है, स्क्रिप्ट चलाना है, और अब आपका आवेदन websockets का समर्थन करता है! यह निर्णय Django को लगता है कि यह एक सामान्य (कुछ हद तक) HTTP अनुरोध प्राप्त कर रहा है, इसलिए यह आपके सभी मौजूदा कोड के साथ संगत होगा। समाधान Django रेस्ट फ्रेमवर्क के साथ और नियमित रूप से देखने के कार्यों और कक्षा आधारित दृश्यों के साथ ठीक काम करता है।

अधिक जानकारी

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

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

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

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

हमारे मुख्य लक्ष्य थे:
1. डेटा को क्रमबद्ध और डिसेर्बलाइज़ करने के लिए एक ही तंत्र, HTTP बैकएंड से और वेब सॉकेट एपीआई से दोनों।
2. सभी के लिए एक ही व्यापार तर्क।

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

हमें पता था कि हम एक एकल REST API चाहते हैं जो दो चैनलों पर काम करेगी: HTTP और वेब सॉकेट। सबसे अच्छा विकल्प सिर्फ वेब सॉकेट के साथ काम करने के लिए कुछ भी लिखने से बचना होगा। एक बिंदु पर, यह मुझ पर dawned। मुझे Sails.js याद आया , जो कि हम जो हासिल करना चाहते हैं, उसके साथ भी कुछ ऐसा ही है।

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

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

निर्णय

WebSocketRequest अप्रत्याशित रूप से सरल समाधान निकला। यह एक साधारण वर्ग है जो निम्नलिखित कुंजियों वाली JSON स्ट्रिंग को स्वीकार करता है: विधि, url, डेटा और टोकन। विधि कुंजी किसी भी HTTP विधि हो सकती है: GET, POST, PUT, DELETE, PATCH, HEAD, या विकल्प। URL नाम के बिना url कुंजी एक निरपेक्ष URL है। डेटा कुंजी एक वैकल्पिक पैरामीटर है - एक शब्दकोश जिसमें डेटा होता है। टोकन कुंजी भी वैकल्पिक है - HTTP ऑथराइजेशन हेडर को दोबारा बनाने के लिए, JSON वेब टोकन के माध्यम से प्राधिकरण या अपनी खुद की कुंजी के लिए उपयोग किया जाता है। आप JSON वेब टोकन के बारे में अधिक जानने के लिए मेरे लेख को देख सकते हैं, और यदि आप Django REST फ्रेमवर्क का उपयोग करते हैं, तो आप शायद django-rest-फ्रेमवर्क-jwt पसंद करेंगे।

WebSocketRequest निम्नानुसार काम करता है:

1. जाँच JSON स्ट्रिंग आता है
2. अनुरोध कारखाने का एक उदाहरण बनाता है (RequestFactory)
3. डायनामिक रूप से अनुरोध कारखाने के तरीकों में से एक को कॉल करता है, जो WSGIRequest का एक उदाहरण देता है
4. उपयुक्त URL प्रतिनिधित्व ढूँढता है
5. URL से आए सभी डेटा के साथ पाया गया दृश्य चलाता है।

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

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

डेमो

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

मैंने हरोकू पर डेमो एप्लिकेशन इंस्टॉल किया: http://dwr-example.herokuapp.com/ । सावधान रहें, डेटा समय-समय पर मिट जाता है। यदि आपको किसी प्रकार की त्रुटि मिलती है, तो इसके बारे में मुझे ट्विटर पर लिखें।

आप पाइप के साथ WebSocketRequest इंस्टॉल कर सकते हैं:

pip install django-websocket-request

स्रोत कोड:
https://github.com/GetBlimp/django-websocket-request

डेमो आवेदन:
https://github.com/GetBlimp/django-websocket-request-example