वेब अनुप्रयोग विकास जंग में

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

परियोजना का अवलोकन

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

हमारी परियोजना प्रमाणीकरण तंत्र का एक सरल प्रदर्शन है। यह आपको चयनित उपयोगकर्ता नाम और पासवर्ड के साथ लॉग इन करने की अनुमति देता है (वे समान होना चाहिए)।

यदि उपयोगकर्ता नाम और पासवर्ड अलग हैं, तो प्रमाणीकरण विफल हो जाएगा। सफल प्रमाणीकरण के बाद, JWT टोकन (JSON वेब टोकन) क्लाइंट और सर्वर दोनों तरफ संग्रहीत किया जाता है। इस तरह के अनुप्रयोगों में सर्वर पर टोकन संग्रहीत करना आमतौर पर आवश्यक नहीं होता है, लेकिन मैंने प्रदर्शन प्रयोजनों के लिए बस यही किया। यह, उदाहरण के लिए, यह पता लगाने के लिए इस्तेमाल किया जा सकता है कि कितने उपयोगकर्ता लॉग इन हैं। पूरे एप्लिकेशन को एक एकल config.toml फ़ाइल का उपयोग करके कॉन्फ़िगर किया जा सकता है, उदाहरण के लिए, डेटाबेस तक पहुंचने के लिए क्रेडेंशियल निर्दिष्ट करना, या सर्वर का पता और पोर्ट नंबर। यहां बताया गया है कि इस फ़ाइल का मानक कोड हमारे आवेदन के लिए कैसा दिखता है।

[server] ip = "127.0.0.1" port = "30080" tls = false [log] actix_web = "debug" webapp = "trace" [postgres] host = "127.0.0.1" username = "username" password = "password" database = "database" 

अनुप्रयोग ग्राहक विकास

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

yew फ्रेमवर्क कार्गो-वेब टूल पर निर्भर करता है, जिसे वास में कोड-कंपाइल कोड के लिए डिज़ाइन किया गया है।

कार्गो-वेब टूल एक सीधा yew निर्भरता है जो वास में रस्ट कोड के क्रॉस-संकलन को सरल करता है। इस उपकरण के माध्यम से उपलब्ध वास को संकलित करने के तीन मुख्य लक्ष्य इस प्रकार हैं:

• asmjs-unknown-emscripten - asm.js का उपयोग Emscripten के माध्यम से करता है।
• wasm32-unknown-emscripten - Emscripten के माध्यम से WebAssembly का उपयोग करता है
• wasm32-unknown-unknown - WebAssembly के लिए देशी जंग बैकेंड के साथ WebAssembly का उपयोग करता है

WebAssembly

मैंने आखिरी विकल्प का उपयोग करने का निर्णय लिया, जिसके लिए रस्ट कंपाइलर के "नाइट" असेंबली के उपयोग की आवश्यकता होती है, लेकिन इसके मूल में रस्ट के मूल वासम क्षमताओं का प्रदर्शन होता है।
अगर हम WebAssembly के बारे में बात करते हैं, तो रस्ट के बारे में आज बात करना सबसे गर्म विषय है। वास में क्रॉस-कंपाइलिंग रस्ट पर भारी मात्रा में काम किया जा रहा है और इसे Node.js इकोसिस्टम (npm संकुल का उपयोग करके) में एकीकृत किया जा रहा है। मैंने किसी भी जावास्क्रिप्ट निर्भरता के बिना परियोजना को लागू करने का फैसला किया।

वेब एप्लिकेशन के फ्रंटेंड को शुरू करते समय (मेरी परियोजना में इसे make frontend कमांड के साथ किया जाता है), cargo-web क्रॉस वासेम में एप्लिकेशन को संकलित करता है और इसे कुछ स्थिर सामग्रियों को जोड़कर पैक करता है। cargo-web एक स्थानीय वेब सर्वर लॉन्च करता है, जो आपको विकास के उद्देश्यों के लिए आवेदन के साथ बातचीत करने की अनुमति देता है। जब आप उपरोक्त आदेश चलाते हैं तो कंसोल में क्या होता है:

 > make frontend  Compiling webapp v0.3.0 (file:///home/sascha/webapp.rs)   Finished release [optimized] target(s) in 11.86s   Garbage collecting "app.wasm"...   Processing "app.wasm"...   Finished processing of "app.wasm"! If you need to serve any extra files put them in the 'static' directory in the root of your crate; they will be served alongside your application. You can also put a 'static' directory in your 'src' directory. Your application is being served at '/app.js'. It will be automatically rebuilt if you make any changes in your code. You can access the web server at `http://0.0.0.0:8000`. 

yew फ्रेमवर्क में कुछ बहुत ही रोचक विशेषताएं हैं। उनमें से पुन: प्रयोज्य घटक आर्किटेक्चर के लिए समर्थन है। इस सुविधा ने तीन मुख्य घटकों में मेरे आवेदन के टूटने को सरल बना दिया है:

RootComponent । यह घटक सीधे वेबसाइट के <body> टैग पर आरूढ़ है। वह तय करता है कि आगे कौन सा बच्चा घटक लोड किया जाना चाहिए। यदि, पृष्ठ के पहले प्रवेश पर, एक JWT टोकन पाया जाता है, तो यह एप्लिकेशन के सर्वर भाग से संपर्क करके इस टोकन को अपडेट करने का प्रयास करता है। यदि यह विफल रहता है, तो LoginComponent घटक में संक्रमण LoginComponent ।

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


LoginComponent घटक की उपस्थिति

ContentComponent । यह घटक RootComponent घटक का एक और वंशज है। इसमें वह होता है जो एप्लिकेशन के मुख्य पृष्ठ पर प्रदर्शित होता है (फिलहाल यह सिर्फ एक शीर्षक और सिस्टम से बाहर निकलने के लिए एक बटन है)। इस तक पहुंच RootComponent माध्यम से प्राप्त की जा सकती है (यदि एप्लिकेशन, स्टार्टअप पर, एक वैध सत्र टोकन खोजने में कामयाब रहा), या LoginComponent (सफल प्रमाणीकरण के मामले में) के माध्यम से। जब उपयोगकर्ता लॉगआउट बटन पर क्लिक करता है तो यह घटक बैकएंड के साथ डेटा का आदान-प्रदान करता है।


ContentComponent घटक

RouterComponent । यह घटक सामग्री वाले घटकों के बीच सभी संभावित मार्गों को संग्रहीत करता है। इसके अलावा, इसमें एप्लिकेशन loading और error की प्रारंभिक स्थिति है। यह सीधे RootComponent से जुड़ा हुआ है।

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

मुझे यह yew प्रसन्नता हुई कि आप विभिन्न थ्रेड पर एजेंटों को चलाने के लिए वेब वर्कर्स एपीआई का उपयोग करते हैं और समानांतर कार्यों को हल करने के लिए थ्रेड से जुड़े एक स्थानीय अनुसूचक का उपयोग करते हैं। यह Rust पर मल्टीथ्रेडिंग के उच्च स्तर के साथ ब्राउज़र अनुप्रयोगों को विकसित करना संभव बनाता है।

प्रत्येक घटक अपने स्वयं के रेंडर करने योग्य विशेषता को लागू करता है, जो हमें HTML कोड को सीधे HTML स्रोत का उपयोग करके रस्ट स्रोत कोड में शामिल करने की अनुमति देता है।

यह एक महान विशेषता है, और निश्चित रूप से, इसका उचित उपयोग संकलक द्वारा नियंत्रित किया जाता है। यहाँ LoginComponent घटक में Renderable करने Renderable कार्यान्वयन Renderable है।

 impl Renderable<LoginComponent> for LoginComponent {   fn view(&self) -> Html<Self> {       html! {           <div class="uk-card uk-card-default uk-card-body uk-width-1-3@s uk-position-center",>               <form onsubmit="return false",>                   <fieldset class="uk-fieldset",>                       <legend class="uk-legend",>{"Authentication"}</legend>                       <div class="uk-margin",>                           <input class="uk-input",                                  placeholder="Username",                                  value=&self.username,                                  oninput=|e| Message::UpdateUsername(e.value), />                       </div>                       <div class="uk-margin",>                           <input class="uk-input",                                  type="password",                                  placeholder="Password",                                  value=&self.password,                                  oninput=|e| Message::UpdatePassword(e.value), />                       </div>                       <button class="uk-button uk-button-default",                               type="submit",                               disabled=self.button_disabled,                               onclick=|_| Message::LoginRequest,>{"Login"}</button>                       <span class="uk-margin-small-left uk-text-warning uk-text-right",>                           {&self.error}                       </span>                   </fieldset>               </form>           </div>       }   } } 

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


प्रोटोकॉल Cap'n प्रोटो

मैंने Cap'n Proto प्रोटोकॉल ( JSON , MessagePack या CBOR की तरह कुछ के बजाय) का उपयोग गति और कॉम्पैक्टनेस कारणों के लिए एप्लिकेशन डेटा संचारित करने के लिए एक परत के रूप में करने का निर्णय लिया। यह ध्यान देने योग्य है कि मैंने आरपीसी प्रोटोकॉल इंटरफ़ेस का उपयोग नहीं किया है, जो कैप'एन प्रोटो में उपलब्ध है, क्योंकि इसकी रस्ट कार्यान्वयन वेबएस्प्रेम ( टॉक्सियो-आरएस यूनिक्स निर्भरता के कारण) के लिए संकलित नहीं है। यह कुछ हद तक सही प्रकार के अनुरोधों और प्रतिक्रियाओं के चयन को जटिल बनाता है, लेकिन एक अच्छी तरह से संरचित एपीआई का उपयोग करके इस समस्या को हल किया जा सकता है। यहां एप्लिकेशन के लिए Cap'n प्रोटो प्रोटोकॉल घोषणा है।

 @0x998efb67a0d7453f; struct Request {   union {       login :union {           credentials :group {               username @0 :Text;               password @1 :Text;           }           token @2 :Text;       }       logout @3 :Text; # The session token   } } struct Response {   union {       login :union {           token @0 :Text;           error @1 :Text;       }       logout: union {           success @2 :Void;           error @3 :Text;       }   } } 

आप देख सकते हैं कि हमारे पास लॉगिन अनुरोध के दो अलग-अलग संस्करण हैं।

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


UIkit - तेजी से और शक्तिशाली वेब इंटरफेस विकसित करने के लिए एक कॉम्पैक्ट मॉड्यूलर फ्रंट-एंड फ्रेमवर्क

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

▍Testing सीमा

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

वैसे, यहां एक नई परियोजना के लिए एक विचार है: रस्ट में एंड-टू-एंड परीक्षण के लिए एक रूपरेखा।

अनुप्रयोग सर्वर साइड विकास

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

• /ws WebSocket संचार का मुख्य संसाधन है।
• / - मुख्य हैंडलर जो स्टेटिक फ्रंट-एंड एप्लिकेशन को एक्सेस देता है।

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


PostgreSQL DBMS और डीजल प्रोजेक्ट

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

 impl Handler<UpdateSession> for DatabaseExecutor {   type Result = Result<Session, Error>;   fn handle(&mut self, msg: UpdateSession, _: &mut Self::Context) -> Self::Result {       //         debug!("Updating session: {}", msg.old_id);       update(sessions.filter(id.eq(&msg.old_id)))           .set(id.eq(&msg.new_id))           .get_result::<Session>(&self.0.get()?)           .map_err(|_| ServerError::UpdateToken.into())   } } 

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

▍Testing बैकएंड

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

परियोजना की तैनाती

एप्लिकेशन को डॉकर छवि का उपयोग करके तैनात करना बहुत आसान है।


डाक में काम करनेवाला मज़दूर

Config.toml make deploy का उपयोग करके make deploy आप Config.toml नामक एक इमेज बना सकते हैं make deploy जिसमें स्टैटिकली लिंक्ड बैकएंड Config.toml , करंट Config.toml फाइल, टीएलएस सर्टिफिकेट और स्टैटिक Config.toml कंटेंट होते हैं। जंग में पूरी तरह से सांख्यिकीय रूप से जुड़े निष्पादनयोग्य की असेंबली को जंग-मसल-बिल्डर- डॉकर छवि के संशोधित संस्करण का उपयोग करके कार्यान्वित किया जाता है। एक तैयार वेब एप्लिकेशन को make run कमांड का उपयोग करके परीक्षण किया जा सकता है, जो एक नेटवर्क-सक्षम कंटेनर लॉन्च करता है। सिस्टम कार्य को सुनिश्चित करने के लिए PostgreSQL कंटेनर को अनुप्रयोग कंटेनर के साथ समानांतर में चलाया जाना चाहिए। सामान्य तौर पर, हमारे सिस्टम को तैनात करने की प्रक्रिया काफी सरल है, इसके अलावा, यहां इस्तेमाल की जाने वाली तकनीकों के लिए धन्यवाद, हम इसके पर्याप्त लचीलेपन के बारे में बात कर सकते हैं, एक विकासशील अनुप्रयोग की जरूरतों के लिए इसके संभावित अनुकूलन को सरल कर सकते हैं।

परियोजना विकास में उपयोग की जाने वाली प्रौद्योगिकियाँ

यहाँ आवेदन निर्भरता आरेख है।


टेक्नोलॉजीज ने Rust में एक वेब एप्लिकेशन विकसित करने के लिए उपयोग किया

एकमात्र घटक जो फ्रंटएंड और बैकएंड का उपयोग करता है, Cap'n Proto का रस्ट संस्करण है, जिसे बनाने के लिए स्थानीय रूप से स्थापित Cap'n प्रोटो कंपाइलर की आवश्यकता होती है।

परिणाम। वेब उत्पादन के लिए जंग तैयार है?

यह एक बड़ा सवाल है। यहाँ मैं क्या जवाब दे सकता हूं। सर्वर के दृष्टिकोण से, मैं उत्तर "हाँ" के लिए इच्छुक हूं, चूंकि actix-web अलावा, रस्ट इकोसिस्टम के पास सर्वर एपीआई और सेवाओं के तेजी से विकास के लिए एक बहुत ही परिपक्व HTTP-stack और कई अलग - अलग चौखटे हैं।

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

प्रिय पाठकों! क्या आप वेब विकास में जंग का उपयोग करते हैं?