Rwf - Rust वेब फ्रेमवर्क

 (github.com/levkk)
3 पॉइंट द्वारा GN⁺ 2024-10-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Rwf, Rust में वेब एप्लिकेशन बनाने के लिए एक व्यापक फ्रेमवर्क है, और यह क्लासिक MVC पैटर्न पर आधारित तेज़ और सुरक्षित वेब ऐप बनाने के लिए ज़रूरी सुविधाएँ डिफ़ॉल्ट रूप से प्रदान करता है
  • इसकी बुनियादी सुविधाओं में HTTP सर्वर, PostgreSQL क्वेरी के लिए ORM, dynamic templates, authentication और user sessions, middleware, background jobs और scheduled jobs, तथा database migrations शामिल हैं
  • यह JSON serialization को सपोर्ट करने वाला built-in REST framework, WebSockets, static file hosting, environment-specific configuration, logging और metrics, तथा CLI भी प्रदान करता है
  • Hotwired Turbo के साथ इसका गहरा integration है, जिससे backend-driven SPA बनाए जा सकते हैं, और यह Django/Flask migration के लिए WSGI server तथा Rails migration के लिए Rack server प्रदान करता है
  • यह अभी beta स्थिति में है और शुरुआती adopters की तलाश में है; इसके अनुसार अधिकांश फीचर्स अच्छी स्थिति में हैं और documentation उपयोग के लिए पर्याप्त है

Rust के लिए MVC वेब फ्रेमवर्क

  • Rwf, Rust में वेब एप्लिकेशन बनाने के लिए एक व्यापक फ्रेमवर्क है
  • यह क्लासिक MVC(model-view-controller) पैटर्न में लिखा गया है
  • इसका लक्ष्य तेज़ और सुरक्षित वेब ऐप आसानी से बनाने के लिए ज़रूरी फीचर्स को built-in रूप में शामिल करना है
  • documentation आधिकारिक दस्तावेज़ में उपलब्ध है

उपलब्ध सुविधाएँ

  • सर्वर और request handling
    • यह HTTP server प्रदान करता है
    • यह Middleware को सपोर्ट करता है
    • इसमें WebSockets सपोर्ट शामिल है
    • यह Static files hosting प्रदान करता है
  • डेटा और एप्लिकेशन संरचना
    • PostgreSQL क्वेरी को आसानी से बनाने के लिए user-friendly ORM प्रदान करता है
    • यह database migrations को सपोर्ट करता है
    • यह Dynamic templates प्रदान करता है
    • इसमें Authentication और built-in user sessions शामिल हैं
  • API और job processing
  • संचालन और development tools
    • यह environment-specific configuration को सपोर्ट करता है
    • यह logging और metrics प्रदान करता है
    • इसमें CLI शामिल है

Hotwired Turbo और migration सपोर्ट

  • Hotwired Turbo के साथ इसका गहरा integration है, जिससे backend-driven SPAs बनाए जा सकते हैं
  • यह Django/Flask ऐप्स से migration के लिए WSGI server प्रदान करता है
  • यह Rails से migration के लिए Rack server प्रदान करता है

Quick Start

  • एक Rust binary application बनाएँ और dependency में rwf जोड़कर इसका उपयोग करें
cargo add rwf
  • बेसिक ऐप rwf::prelude::* और rwf::http::Server का उपयोग करके controllers और routes परिभाषित करता है
use rwf::prelude::*;
use rwf::http::Server;

#[controller]
async fn index() -> Response {
    Response::new().html("Welcome to Rwf!

")
}

#[tokio::main]
async fn main() {
    Server::new(vec![
        route!("/" => index),
    ])
    .launch()
    .await
    .unwrap();
}

उदाहरण और प्रोजेक्ट की स्थिति

  • सामान्य उपयोग के मामले examples में देखे जा सकते हैं
  • Rwf अभी beta स्थिति में है और शुरुआती adopters की तलाश में है
  • इसके अनुसार अधिकांश फीचर्स अच्छी स्थिति में हैं और documentation उपयोग के लिए पर्याप्त है
  • contributions का स्वागत है; गाइड CONTRIBUTING में, code structure की जानकारी ARCHITECTURE में, और इच्छित फीचर्स की सूची ROADMAP में है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-10-23
Hacker News की रायें

  • रिलीज़ काफी अवास्तविक-सी लगेगी, और बधाई। Rails के साथ लंबे समय तक web MVC करते हुए मैंने सबसे बड़ी बात यह सीखी कि framework को model layer की business logic को मजबूती से रोकना चाहिए
    मेरे हिसाब से data model में Active Record वाले callbacks, जैसे afterCreate जैसे hooks, नहीं डालना बेहतर है। अभी ORM में नहीं हैं, लेकिन roadmap में हों तो भी मुझे लगता है कि न होना बेहतर होगा
    हालांकि यह तभी ठीक से काम करता है जब service, यानी business logic layer, को मजबूती से recommend किया जाए। मेरी Rails apps में ज़्यादातर Interactor जैसे gems से command/service objects बनाए जाते हैं
    सिर्फ MVC से, यानी Rails की default configuration से, service layer की कमी के कारण मुझे लगता है कि production में चल सकने वाली app लिखने के लिए यह ideal नहीं है। और यह भी जानना चाहूंगा कि community के मौजूदा ORM या query builder का इस्तेमाल क्यों नहीं किया गया। मैंने अभी Rust की एक लाइन भी नहीं लिखी है, लेकिन उत्सुकता बढ़ती जा रही है

    • यह नजरिया कहां से आता है, यह जानने की उत्सुकता है। मेरी सोच इसके ठीक उलट है: जितनी ज्यादा हो सके business logic model में होनी चाहिए
      मेरे हिसाब से services लगभग पूरी तरह model से trigger होने वाले ज्यादा जटिल और विशिष्ट code pieces होने चाहिए। पतले controllers, मोटे models debugging, organization और discoverability के लिहाज से सबसे अच्छे रहे हैं, और services ज्यादा इस्तेमाल करने पर मेरे अनुभव में काफी spaghetti code बनता है
      pure object-oriented नजरिए से भी model entity को define करने वाला basic object है। User को अपने बारे में जानने लायक सब कुछ पता होना चाहिए, और दूसरी entities से messages के जरिए communicate करना चाहिए
      हालांकि callbacks पर सहमत हूं। callbacks बहुत सारे अजीब side effects बनाते हैं और debugging को सच में मुश्किल कर देते हैं
    • अगर business logic नहीं है तो फिर model है क्या, समझ नहीं आता। ऐसा लगता है जैसे आप ऐसी बनावट चाहते हैं जहां struct को model और procedures को service कहा जाए
      ऐसा किया जा सकता है, लेकिन यह reason करना काफी मुश्किल हो जाता है कि किसी entity को किन तरीकों से update किया जा सकता है। क्योंकि कितनी भी procedures update कर सकती हैं और हर एक के अपने business rules हो सकते हैं। अगर ऐसा ही करना है तो procedures को सीधे database में लिखने दें और model हटा दें
    • मैं सहमत हूं कि model में business logic नहीं होनी चाहिए। Martin Fowler और Robert C. Martin इसे anemic domain model कहते हैं, और यह पुराने object-oriented तथा pattern-heavy enterprise development तरीके के उलट है
      लेकिन 20 साल से ज्यादा development करने के बाद मैं इस निष्कर्ष पर पहुंचा हूं कि encapsulation feature नहीं, बल्कि बोझ है, और data को उस data पर किए जाने वाले operations से अलग होना चाहिए। इसे data-oriented design या data-oriented programming कहा जाता है, और इसी निष्कर्ष पर पहुंचने वाला मैं अकेला नहीं हूं
    • यह कहना कि सिर्फ MVC production-level apps के लिए पर्याप्त नहीं है, काफी बड़ा दावा है। निजी तौर पर मुझे service objects पसंद नहीं हैं, क्योंकि वे इधर-उधर बिखर जाते हैं और discoverability को नुकसान पहुंचाते हैं
      अच्छी तरह scale होने वाले दूसरे modeling तरीके भी हैं, और इस पर कुछ लेख भी हैं। Basecamp के व्यक्ति द्वारा लिखा लेख https://dev.37signals.com/vanilla-rails-is-plenty/ है
      बेशक यह बहुत object-oriented है, इसलिए मुझे भी यह बहुत पसंद नहीं। उदाहरण के लिए Elixir का Phoenix framework संबंधित functionality को group करने के लिए contexts का इस्तेमाल करता है, और सरल शब्दों में इसे facade माना जा सकता है
      अगर आपको services पसंद हैं तो आप उनका इस्तेमाल कर सकते हैं, लेकिन MVC production-grade के लिए पर्याप्त नहीं है कहना थोड़ा गलत लगता है। भारी business processes को model callbacks से संभालना अच्छा नहीं, लेकिन data को सही shape में ढालने वाले छोटे कामों के लिए यह काफी ठीक है
    • दिलचस्प। कंपनी में हमने अपना PHP ORM बनाया था, क्योंकि Laravel जैसी open-source libraries का इस्तेमाल मना था, और मुझे hooks बहुत उपयोगी लगे
      खासकर क्योंकि मेरा programming अनुभव Wordpress के लिए PHP से शुरू हुआ था, जहां hooks का व्यापक इस्तेमाल होता है, इसलिए मेरा bias हो सकता है
      मैंने जो बनाया उसमें table specifications हैं जिन्हें SQL definitions में बदला जा सकता है या सुंदर format वाले HTML forms निकाले जा सकते हैं। एक अलग controller सभी DB connections और CRUD operations संभालता है, और जरूरत पड़ने पर दूसरी tables और constraints को आसानी से cross-reference करने के लिए before/after hooks हैं
      यह काफी अच्छा काम करता है, लेकिन अगर संभव हो तो मैं तुरंत Laravel पर switch कर दूंगा

  • REST framework हो तो मैं default रूप से Swagger/OpenAPI definition generation की उम्मीद करता हूं। मुझे लगता है कि यह FastAPI के killer features में से एक है
    साथ ही diesel.rs जैसे मौजूदा ORM के साथ integrate न करके खुद का ORM बनाने की वजह, और कोई popular मौजूदा template engine चुनने के बजाय अपनी template language बनाने की वजह भी मुझे ठीक से समझ नहीं आती
    बाकी project सच में बहुत interesting दिखता है और मैं इसे देखते रहूंगा
    [0] https://diesel.rs/
    [1] https://crates.io/categories/template-engine

    • कुछ साल पहले मैंने Diesel इस्तेमाल किया था, लेकिन मेरे लिए यह बहुत Rust-जैसा लगा। schema को दो बार define करना पड़ता था, और insert व query के लिए वही struct इस्तेमाल नहीं कर सकते थे, इसलिए असल में तीन बार define करने जैसा था
      कुल मिलाकर database types को Rust types से match कराने की एक अच्छी पहली कोशिश थी, लेकिन ORM को ज्यादा flexible और इस्तेमाल में आसान होना चाहिए। queries को कठिन नहीं, आसान बनाना चाहिए :)
      templates की बात करें तो अपनी language बनाना 30+ उम्र वाले nerd club में दीक्षा-समारोह जैसा है। मैंने Dragon Book नहीं पढ़ी, लेकिन स्कूल में वह class जरूर लेना चाहता था। एक ही चीज़ की हमेशा कई implementations होती हैं, और Rails के ERB द्वारा किए जाने वाले काम की बहुत नजदीकी नकल करने वाली इस implementation का इस्तेमाल करना सही लगा
    • https://github.com/poem-web/poem एक Rust framework है जो Swagger definitions built-in देता है
    • क्या किसी को ऐसा मिलता-जुलता framework पता है जो उलटी दिशा में काम करता हो? यानी OpenAPI definition को source of truth बनाए रखे, और verify करे कि server उसका पालन करता है या नहीं
    • server से OpenAPI generate करना 100% killer feature है। हम Dropshot के साथ इसे अच्छे से इस्तेमाल कर रहे हैं
    • मैं भी REST framework हो तो Swagger/OpenAPI definition default रूप से generate करने की उम्मीद करता हूं। हालांकि मेरी समझ में यह web API बनाने का framework नहीं, बल्कि HTML लौटाने वाला MVC framework है

  • SRE के नज़रिए से https://levkk.github.io/rwf/migrating-from-python/ ने ध्यान खींचा। एक तरफ़ यह वाकई शानदार है कि यह किया गया, लेकिन स्थिरता देखने वाले SRE दृष्टिकोण से अंदर ही अंदर चीख निकलती है
    स्केल बढ़ने पर यह काम Caddy, Nginx, Traefik जैसे reverse proxy को संभालना चाहिए

    • मैंने भी यही सोचा था, लेकिन इस तरीके में application engineer इधर-उधर जाए बिना बदलावों को local पर test कर सकता है। आखिरकार बात उसी पुराने monolith बनाम microservices विवाद पर लौट आती है
      स्थिर WSGI server लिखना संभव है, और thread count या vacuum, पुराने php-fpm की तरह हर n requests के बाद restart जैसी बारीकियों पर थोड़ा ध्यान दें तो यह बहुत मुश्किल नहीं है। मूल रूप से uwsgi के ज़्यादातर options implement कर दें, तो आप सही रास्ते पर हैं। Rwf को Gunicorn चलाने के बराबर तुलनीय बनाना roadmap में है
    • शायद लेखक ने मान लिया होगा कि technical readers को WSGI server के आगे reverse proxy की ज़रूरत अलग से बताने की ज़रूरत नहीं है

  • नाम का चुनाव सच में कमाल है। search results में सबसे ऊपर आने का एक तरीका तो है :P
    गंभीरता से कहें तो यह अच्छी तरह बनाया गया है। अच्छा framework बनाना हैरान करने लायक बड़ा काम है, और लोगों को design space explore करते हुए नए ideas आज़माते देखना हमेशा अच्छा लगता है

    • Rust projects में ऐसे व्यापक, generic और खुद को बहुत बड़ा दिखाने वाले नाम चुनने की प्रवृत्ति है, और सच कहूँ तो मुझे यह बड़ी गलती लगती है। Crates.io अच्छे लगने वाले नाम कब्ज़ा कर चुके छोड़े हुए projects का कब्रिस्तान बन जाएगा
    • “Row” भी अच्छा नाम है, और rwf से बोलने में आसान लगता है
      RustOnWeb.com भी $10 में खरीदा जा सकता है :) बस यूँ ही कह रहा हूँ

  • “Rails के बारे में सोचें, Flask के बारे में नहीं” वाली बात पसंद आई। statically typed languages में भी Rails/Django जैसे opinionated frameworks ज़्यादा या बेहतर होने चाहिए

  • अच्छी तरह बनाया गया है। https://www.arewewebyet.org/ पर शामिल कराने की कोशिश की जा सकती है

    • इस पेज पर loco.rs का न होना काफ़ी हैरान करने वाला है। Rust frameworks में यह सबसे ज़्यादा “Rails” जैसा दिखता है, फिर भी छूटा हुआ है

  • बढ़िया! एक top-tier language में Django/Rails
    सुझाव के तौर पर, async-trait अब शायद stabilize हो चुका होगा, इसलिए macro की अब ज़रूरत नहीं रह सकती, और default तौर पर metrics और tracing मिल सके इसके लिए OpenTelemetry integration जोड़ना अच्छा रहेगा। Linux targets पर jemalloc भी इस्तेमाल करना अच्छा रहेगा

    • धन्यवाद। standard async traits इस्तेमाल करने की कोशिश की थी, लेकिन वे Rwf द्वारा व्यापक रूप से इस्तेमाल किए जाने वाले dynamic dispatch को support नहीं करते
      tracing crate के functions में OpenTelemetry tags जोड़ने की योजना है। jemalloc को Rwf इस्तेमाल करने वाले binary app में जोड़ा जा सकता है, इसे library dependency के रूप में डालने की ज़रूरत नहीं है
      [1] https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-trait...
    • जिज्ञासा है कि Linux targets पर jemalloc क्यों इस्तेमाल करना चाहिए। या फिर दूसरे targets पर इसकी ज़रूरत क्यों नहीं है

  • Rust सीखने की कोशिश की थी, लेकिन शुरुआत में ही छोड़ दिया। C#, C/C++, Java, Python से आने पर Rust अजीब लगा
    मुझे तोड़ने वाली चीज़ अजीबपन नहीं था, बल्कि C#, Java, Python जैसी languages की तुलना में एक काम खत्म करने की गति धीमी होना था
    आजकल मैं ज़्यादातर web development करता हूँ, इसलिए ease of use और productivity सबसे ऊपर हैं। Rust throughput और speed में थोड़ा बेहतर हो सकता है, लेकिन modern web framework benchmarks देखें तो C# और Java भी इस मामले में काफ़ी अच्छे हैं
    इसे Rust की आलोचना या MVC framework को scratch से बनाने की बड़ी उपलब्धि को कम करके कहने जैसा न पढ़ें। यह “काम के लिए सही tool” वाली बात के ज़्यादा करीब है

    • आपकी बात पूरी तरह समझता हूँ। मेरे समेत कई लोगों का शुरुआत में ऐसा ही अनुभव था
      learning curve पार करने के लिए मजबूत motivation चाहिए। या तो आपको वह language इस्तेमाल करनी ही है, या type system और safety के फायदे आकर्षित करते हैं, या आपकी अपनी कोई ठोस वजह होनी चाहिए
      अगर ऐसी motivation नहीं है तो बिल्कुल ठीक है। मेरे पास भी शुरुआत में नहीं थी, इसलिए शुरुआती सीखने की कोशिशें बहुत आगे नहीं गईं। जैसा कई लोग महसूस करते हैं, Rust में Java या Python की तुलना में काम खत्म करने में ज़्यादा समय लगता है, और पहले से ज़्यादा सोचना पड़ता है। कुछ स्थितियों में यह मूल्यवान है, लेकिन अगर यह स्पष्ट नहीं है कि वह trade-off क्यों स्वीकार करना है, तो जारी रखने की मजबूत वजह नहीं बचती

  • हाल ही में webpack JS loader छोड़कर 50 गुना तेज़ Rust loader इस्तेमाल करने लगा, और मैं भी Rust में रम गया। Rust से performance improvement का असर बड़ा है, और अभी C++ और Rust मेरी सबसे पसंदीदा languages हैं

    • ओह, webpack छोड़कर आपने क्या इस्तेमाल करना शुरू किया, क्या share कर सकते हैं?

  • backend Rust काम के लिए आम तौर पर जिन candidates का ज़िक्र होता है, उन सबका evaluation किया और छोटे prototypes बनाए। अब तक, यह मेरी पसंद से थोड़ा low-level है, फिर भी कुल मिलाकर Axum सबसे अच्छा है—इस सामूहिक निष्कर्ष से अनिच्छा से सहमत होना पड़ा
    दूसरे candidates Loco और Rocket थे। Loco Rails से बहुत ज़्यादा मिलता-जुलता था, और Rocket में Rust ज़्यादा इस्तेमाल करने के बाद macros खटकने लगे
    यह framework मेरे “batteries included लेकिन बहुत ज़्यादा prescriptive नहीं” वाले मापदंड पर बिल्कुल फिट दिखता है। ecosystem में अच्छा addition है

    • Actix कैसा रहेगा? जहाँ तक याद है, पहले HN पर Actix और Axum को लेकर चर्चा हुई थी