Rust को आलसी डेवलपर्स के लिए एक वेब framework चाहिए

 (ntietz.com)
3 पॉइंट द्वारा GN⁺ 2024-10-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Rust में छोटा web app बनाते समय भी Django जैसा integrated experience नहीं मिलता, इसलिए routing, login, DB और admin features को खुद जोड़ने का बोझ बढ़ जाता है
  • जिस framework की ज़रूरत है, उसमें routing/handlers, templates, static file serving, login, permissions, DB interface, admin tools, WebSockets और hot reloading default रूप से साथ आने चाहिए
  • actix-web और axum जैसे minimal frameworks तथा Dioxus, Leptos, Yew जैसे SPA frameworks मौजूद हैं, लेकिन वे पूरे web app की संरचना को आपकी जगह assemble नहीं करते
  • starter templates शुरुआती setup घटाते हैं, फिर भी project अलग दिशा में बढ़ने के बाद changes merge करना और libraries update करना maintenance burden बना रहता है
  • newt मौजूदा components को opinionated तरीके से जोड़ने वाला web toolkit बनना चाहता है, जिसका लक्ष्य छोटे web apps को दिनों में नहीं बल्कि मिनटों में शुरू कराना है

Rust web development में integrated starting point की कमी

  • Rust में छोटा web project बनाते समय भी Django या मिलते-जुलते frameworks की तुलना में कहीं ज़्यादा initial wiring work चाहिए
  • Rust community का आम approach ज़रूरी parts को खुद जोड़ने जैसा है
    • Are We Web Yet? भी बताता है कि Rust web development में आम तौर पर चीज़ें खुद connect करनी पड़ती हैं, और शुरुआत में extra setup work की उम्मीद रखें
  • यह extra work सिर्फ “थोड़ा और” नहीं है; project शुरू करने से पहले असल में कई चीज़ें निपटानी पड़ती हैं
  • अगर integrated web framework हो, तो लोगों को web apps के लिए Rust इस्तेमाल करने के लिए मनाना आसान हो जाएगा
    • Rust के फायदों में type system, performance, और compile time के दौरान मिलने वाले coffee breaks का ज़िक्र है

लगभग हर web app के लिए ज़रूरी basic components

  • Routing/handlers

    • incoming requests को सही handler तक भेजना होता है
    • path parameters handle करने होते हैं, और type information हो तो बेहतर है
    • query parameters और forms की handling भी हो तो अच्छा है

  • Templates

    • HTML generate करना होता है, और कभी-कभी JSON या XML भी
    • conditionals, match/switch, loops जैसी basic logic चाहिए

  • Static file serving

    • CSS जैसे assets serve करने होते हैं
    • इसे अलग server से भी संभाला जा सकता है, लेकिन local development और small deployments में same web server में शामिल होना सुविधाजनक है

  • Login

    • apps आमतौर पर multi-user होते हैं या public network पर deploy होते हैं, इसलिए login feature लगभग हमेशा चाहिए
    • हर बार इसे खुद connect करना झंझट भरा है, इसलिए शुरुआत से ही आसानी से usable होना चाहिए
    • customization और opt-out संभव होने चाहिए

  • Permissions

    • कई users वाले systems में accessible data या roles अलग-अलग होते हैं
    • सिर्फ check(user, object, action) pattern से भी काफी दूर तक काम चल सकता है

  • DB interface

    • app data store करने का तरीका चाहिए
    • ORM के करीब कोई तरीका उपयोगी हो सकता है, लेकिन हल्का तरीका भी संभव है
    • यह login, permissions और admin tools में इस्तेमाल होता है, इसलिए basic component बन जाता है

  • Admin tools

    • local environment या production में application setup करते समय कम से कम एक user या कुछ data bootstrap करना पड़ता है
    • smooth experience के लिए कुछ common admin tasks built-in होने चाहिए

  • WebSockets

    • connected users को data अधिक real-time के करीब push करने की functionality बनाई जा सकती है

  • Hot reloading

    • code या template changes जितनी जल्दी हो सके reflect होने चाहिए, इसलिए developer experience में यह बहुत अहम है

लंबे समय तक maintain होने वाले projects के लिए पूरक features

  • Background jobs

    • schedule के हिसाब से चलने वाली functionality की ज़रूरत आती है, इसलिए एक consistent तरीका हो तो development आसान होता है

  • Monitoring/observability

    • सबसे छोटे और कम critical systems को छोड़कर इसकी ज़रूरत पड़ती है
    • जब सच में इसकी सख्त ज़रूरत महसूस होती है, तब यह बहुत मदद करता है

  • Caching

    • इसे implement करने के कई तरीके हैं और सभी complexity बढ़ाते हैं; speed बढ़ेगी या नहीं, यह situation पर निर्भर करता है
    • framework level पर इसकी कोई कहानी हो तो अच्छा है, लेकिन users खुद भी संभाल सकते हैं

  • Email और notifications

    • अगर login feature है, तो password reset के कारण email functionality लगभग ज़रूरी हो सकती है
    • बाकी notifications ज़रूरत पड़ने पर जोड़ना कोई बड़ी समस्या नहीं है

  • Deployment tools

    • किसी specific जगह deploy करने का consistent तरीका हो तो अच्छा है
    • चुने हुए host पर इस्तेमाल हो सकने वाला auto-generated Dockerfile ही हो, तो भी उपयोगी है

  • CSS/JS bundling

    • web tool CSS और JS को पहचानकर naturally include कर सके तो अच्छा है
    • इसे अनिवार्य रूप से integrated होना चाहिए या नहीं, यह स्पष्ट नहीं है

मौजूदा Rust web ecosystem में बची खाली जगह

  • Rust में web development tools पहले से बहुत हैं, लेकिन वांछित integrated experience को लक्ष्य बनाने वाला tool नहीं है

  • Minimal web frameworks

    • actix-web और axum, Flask और Sinatra जैसे छोटे frameworks के करीब हैं
    • वे Rust type system का फायदा उठाकर अच्छा web development experience देते हैं, लेकिन handlers के अलावा अतिरिक्त features बहुत कम देते हैं
    • अधिकतर projects ऐसे minimal frameworks से बनाए जा सकते हैं, फिर भी ज़रूरी features हर बार खुद connect करने पड़ते हैं, जो झंझट भरा है

  • SPA frameworks

    • Dioxus, Leptos, Yew वह क्षेत्र भरते हैं जहाँ Rust को backend और frontend दोनों में इस्तेमाल किया जाता है, और frontend rendering के लिए WebAssembly इस्तेमाल होता है
    • Yew से digital vigil बनाने का अनुभव मज़ेदार था, लेकिन असली production environment में इसे इस्तेमाल करना चाहूँगा या नहीं, यह पक्का नहीं है
    • ये frameworks अपने-अपने purpose के लिए शानदार हैं, लेकिन फिर भी काफी wiring work चाहिए

  • Individual libraries का bundle

    • templates, login, permissions और WebSocket libraries बहुत हैं
    • कुछ projects और examples कुछ components को integrate करते हैं, लेकिन इस्तेमाल होने वाले सभी pieces को integrate करने वाला कुछ मिलना मुश्किल है
    • तेज़ी से बदलते ecosystem में कुछ examples outdated हो सकते हैं
    • “बस connect कर देना” आखिरकार हर library के काम करने के तरीके को खोजना और पर्याप्त समझना बन जाता है

Starter templates जिस maintenance को solve नहीं करते

  • मौजूदा तरीका आमतौर पर actix-web या axum जैसा base framework चुनने, फिर ज़रूरी pieces ढूँढकर जोड़ने और खुद connect करने का flow है
  • starter templates शुरुआती दर्द घटा सकते हैं, लेकिन maintenance burden बचा रहता है
    • libraries को up to date रखना पड़ता है
    • breaking changes से भी निपटना पड़ता है
    • project template से अलग हो जाए, तो template changes को फिर merge करना मुश्किल होता है
  • कई projects चलाने पर एक framework update करने के बजाय n custom frameworks को अलग-अलग update करना पड़ता है
  • पूरा जिम्मा लेने वाला web framework versions के बीच upgrade guidance दे, तो बेहतर है
    • breaking changes आ सकते हैं, लेकिन उन्हें document किया जा सकता है
    • दो ऐसे components की interaction changes से समस्या आने की स्थिति घट सकती है जिन्हें यह पता ही नहीं था कि वे एक-दूसरे के साथ integrate होंगे

newt जिस web toolkit की ओर बढ़ रहा है

  • ideal Rust web framework में ऊपर सूचीबद्ध features के साथ अच्छी documentation, changelog, सावधान version management, breaking changes handling और community होनी चाहिए
  • अभी ऐसा tool मौजूद नहीं है, और कोई और इसे बना रहा है या नहीं यह भी स्पष्ट नहीं है
  • जिस tool पर काम चल रहा है, वह framework से ज़्यादा मौजूदा building blocks को opinionated तरीके से जोड़ने वाला web toolkit है
  • इस toolkit का नाम nicole's web toolkit, संक्षेप में newt है
    • यह public repository में उपलब्ध है
    • अभी इस्तेमाल करने लायक स्थिति में नहीं है, और latest changes भी अभी push नहीं किए गए हैं
    • यह अभी contributions लेने के लिए भी तैयार नहीं है
  • newt का लक्ष्य है कि नया छोटा web app बनाते समय कई दिनों तक wiring work करने के बजाय, कुछ ही मिनटों में actual project work शुरू हो सके
  • कुछ components ज़रूरत के हिसाब से scratch से बनाने की योजना भी है
    • ऐसा करना आसान हो सकता है या ज़्यादा cohesive fit दे सकता है
  • Rust ecosystem को ऐसी कई toolkits वाली healthy स्थिति चाहिए, और उम्मीद है कि दूसरे tools भी साथ आएँगे

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

1 टिप्पणियां

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

  • हैरानी हुई कि Rocket(https://rocket.rs/) लेखक द्वारा सूचीबद्ध frameworks में नहीं था
    मैंने खुद इसे इस्तेमाल नहीं किया है, और मुझे ज़्यादा गैर-नियमबद्ध axum/actix-web पसंद हैं, लेकिन मेरी समझ में Rocket का लक्ष्य लेखक जिस batteries-included framework को चाहते हैं, उसके कहीं ज़्यादा करीब है और यह पहले से ही काफ़ी पुराना project है

    • Rocket शुरुआती Rust frameworks में से एक था जिसने procedural macros के जरिए अच्छा developer experience आगे बढ़ाया, लेकिन लगता है community के कई हिस्सों में इसकी लोकप्रियता काफ़ी ठंडी पड़ गई है
      बहुत लंबे समय तक build के लिए nightly Rust चाहिए था, और production में framework इस्तेमाल करना चाहने वालों के लिए यह बड़ी कमी थी
      साथ ही यह लगभग 2 साल तक 0.5.0 release candidate स्थिति में अटका रहा, और latest stable release दूसरे Rust web frameworks से काफ़ी पीछे था। इसमें nightly चाहिए था और async support भी अभी नहीं था
      अब जब 0.5 की बाधा पार हो गई है तो शायद स्थिति बेहतर हुई हो, लेकिन Rocket का development history Axum जैसे विकल्पों की तुलना में इसे अपनाने में झिझक पैदा करता है

  • एक तो है: Poem[1]
    लेखक Flask का ज़िक्र करते हैं, लेकिन “ज़रूरत” वाले section को देखें तो Flask भी उन मांगों को पूरा करता है, ऐसा कहना मुश्किल है। मुझे Django वाकई पसंद नहीं है, लेकिन ऐसी requirements के लिए लेखक जो वर्णन कर रहे हैं, उसके सबसे करीब Django ही लगता है
    उस लिहाज से Poem भी बहुत अच्छा candidate नहीं है। कुल मिलाकर Poem काफी हद तक FastAPI जैसा है, और यह बात तारीफ़ जैसी ही है। मैंने आधा दर्जन के करीब Rust web frameworks इस्तेमाल किए हैं और ज़्यादातर में शुरुआती setup में बहुत boilerplate छेड़ना पड़ता है। अगर जल्दी result चाहिए तो यह समस्या है, और उस मामले में Poem अच्छा fit बैठता है
    actix की performance काफ़ी अच्छी है, लेकिन अगर लक्ष्य 30ms से कम response नहीं है, तो शुरुआत में ही actix देखने की वजह कम है। अगर Pydantic जैसी चीज़ चाहिए, तो कुछ हद तक वह करने वाला crate भी है: https://crates.io/crates/poem-openapi
    [1] https://github.com/poem-web/poem

    • सिर्फ Django ही नहीं, Rails, ASP .NET Core, और कई दूसरे full-featured batteries-included web frameworks भी इसी में आते हैं
      मुख्य बात यह है कि यह “framework” है

  • F# भी एक बार आज़माने लायक है
    मनचाही type system वाली लगभग सारी मस्ती इसमें है, और ज़रूरी tools व सुविधाएं भी मौजूद हैं। बड़ा downside अगर कुछ है तो यह कि async processing और memory management Rust जितना समय नहीं खाता, इसलिए असल में business requirements हल कर देने का ख़तरा है
    फिर भी Microsoft से निपटने की प्रक्रिया में कहीं न कहीं वह खाली जगह भर सकती है

    • क्या F# के लिए .NET virtual machine नहीं चाहिए? जिन ज़्यादातर Rust चुनने वालों को मैं जानता हूं, वे यह पसंद करते हैं कि यह हमेशा native code में compile होता है, predictable है, और garbage collection recovery time की randomness नहीं होती
    • मैं लगातार सोच रहा हूं कि F# आज़माऊं या नहीं
      OCaml या Haskell की तुलना में यह कैसा है?

  • अलोकप्रिय हो सकने वाला विचार: Rust एक systems language है, और Rust से web काम करना मेहनत की बर्बादी है
    उस उपयोग के लिए कहीं बेहतर languages और ecosystem हैं

    • प्रतिवाद: Rust में web services develop करना Go या Java जितना आसान है, और साथ में बेहतरीन type system (sum types!), शानदार package manager, और बहुत अच्छी performance भी मिलती है
      Java की तरह Rust में भी connection pool sharing के लिए dependency injection किया जा सकता है, और thread-based background jobs भी बहुत आसानी से लिखे जा सकते हैं
      Google ने हाल की presentation में बताया कि उनके माप के अनुसार Rust developers, Go developers से कम efficient या कम productive नहीं हैं [1]
      Rust एक बेहतरीन language है, और इसे सिर्फ systems programming तक सीमित करने की कोई ज़रूरत नहीं है। यह उससे कहीं ज़्यादा काम कर सकता है
      [1] https://www.ardanlabs.com/news/2024/rust-at-google/
    • मैं web servers के लिए हमेशा C/C++ इस्तेमाल करता हूं
      यह lightweight है, C/C++ और low-level code को आसानी और तेज़ी से call कर सकता है, और networking में भी काफी control देता है। PHP जैसी application-specific language या nginx/apache config files सीखने की ज़रूरत नहीं, लगभग कुछ भी general-purpose और intuitive तरीके से किया जा सकता है
      libmicrohttpd जैसी चीज़ का कोई Rust alternative हो तो अच्छा होगा, और अगर है तो शायद मैं इस्तेमाल करूंगा
    • मैं लगभग पूरी तरह सहमत हूं, लेकिन यह कहना चाहूंगा कि systems programming और web programming का intersection खाली नहीं है
      embedded programming और web programming का intersection भी ऐसा ही है
      फिर भी अगर Django, .Net, Go जैसे विकल्प संभव हों, तो Rust आम तौर पर खराब विकल्प होने की संभावना रखता है
    • यह energy efficiency में निवेश है
    • उन systems में यह समझ में आता है जहां memory या CPU सामान्य मामलों से ज़्यादा constrained हों
      statically compiled web framework, Rails, Django, Flask जैसी चीज़ों की तुलना में memory/CPU आसानी से 1/10 से 1/100 तक ही इस्तेमाल कर सकता है

  • Python के पास Django है, C# के पास ASP .NET Core है, Ruby के पास Rails है
    अगर Rust को web development में सचमुच बहुत बड़ा बनाना है, तो full-featured solution बनाना होगा
    Rocket शायद सबसे करीब हो सकता है, लेकिन ऊपर बताए गए frameworks जितना batteries-included नहीं है

  • लेखक जो ढूंढ रहे हैं वह ASP.NET Core का Rust version है, और इसमें कोई समस्या नहीं है
    कुछ लोगों को choices और assembling पसंद होती है, लेकिन कई environments में choices को पहले से curate कर देना कहीं ज़्यादा productive होता है
    “अगर अलग X चाहिए तो क्या? Y% बेहतर हो सकता है!” जैसी प्रतिक्रिया आम है, लेकिन इसमें यह बात छूट जाती है कि integration अपने आप में बहुत बड़ा value देता है। अलग-अलग libraries अलग से देखने पर best हो सकती हैं, लेकिन अगर वे आपस में smoothly fit नहीं होतीं, तो वे कूड़े का ढेर बन सकती हैं
    ASP.NET 8 में programming करना मुझे इसलिए पसंद है क्योंकि मुझे बिल्कुल चिंता नहीं करनी पड़ती कि template system, authentication, injection, routing वगैरह के साथ ठीक बैठेगा या नहीं

  • loco-rs, poem, rocket का ज़िक्र नहीं है? पहले से ही batteries-included experience को target करने वाले काफी projects हैं
    इन projects और leptos जैसे frameworks में फर्क यह है कि इनमें guide करने वाला CLI होता है। Symfony में भी मुझे यही बात पसंद है, और मेरी नज़र में “lazy” हिस्सा भी यही है

  • https://shuttle.rs मौजूद है
    यह सिर्फ framework नहीं है, बल्कि आसपास के web boilerplate को generate करने वाला tool भी है, इसलिए मेरे हिसाब से यह काफ़ी lazy तरीका है

  • यह लेख कई अलग-अलग मुद्दों को एक साथ कवर कर रहा है, इसलिए आदर्श रूप से हर एक को अलग-अलग संभालना चाहिए
    अगर pattern matching हो, तो router अनिवार्य नहीं होता। URL को बाँटकर static/dynamic variables को ज़रूरत के हिसाब से match किया जा सकता है
    authentication किसी भी भाषा में आम तौर पर खुद बनाते हैं या Firebase/Auth0 जैसी SaaS का इस्तेमाल करते हैं, इसलिए यह ज़रूरी नहीं कि भाषा या framework की समस्या हो
    CSS/JS tools, Dominator जैसे कई Rust frontend frameworks के साथ अच्छी तरह फिट नहीं बैठते। Dominator JS नहीं, बल्कि Rust में बना है, और signal में styles जोड़कर उन्हें real-time में बदलने जैसा उसका अपना styling approach है
    लेखक की बात समझ में आती है। लेख में बताई गई कई चीज़ों को हल करने के लिए मैं सच में कई बार इधर-उधर भटका हूँ, और यह दर्दनाक भी रहा। उदाहरण के लिए https://github.com/dakom/dominator-workers-fluent-auth Cloudflare Workers framework के ऊपर यहाँ बताए गए कई काम संभालता है, और एक अतिरिक्त इच्छा—Fluent आधारित localization—भी जोड़ता है
    सब कुछ देने वाला batteries-included full framework हो तो अच्छा होगा, लेकिन कई वास्तविक projects ऐसे prescriptive फैसलों को बदलकर खुद implement करने का रास्ता चाहेंगे। Rust frontend web में भी काफ़ी mature है, और अगर पता हो कि कहाँ देखना है, तो wasm-bindgen आदि से सब कुछ संभाला जा सकता है

    • “pattern matching हो तो router की ज़रूरत नहीं” कहना पर्याप्त नहीं है
      web framework URL redirects, trailing slash handling, case-sensitive URL management, complex regex matching जैसी कहीं ज़्यादा चीज़ें देता है
      “authentication किसी भी भाषा में आम तौर पर खुद बनाते हैं या SaaS इस्तेमाल करते हैं” यह गलत है। Django, Laravel, Rails और batteries-included भाषाओं में authentication management बहुत अच्छा होता है। निजी तौर पर मुझे लगता है कि 90% संगठनों में authentication को बाहरी vendor को सौंपना बहुत बड़ी गलती है
      अनुभवी web developer बिना अनावश्यक complexity से जूझे एक दिन में 10 basic CRUD तुरंत चला सके—यह छोटे businesses के लिए सच में बहुत बड़ा advantage है

  • अगर यह लेख Rust के बजाय C++ पर केंद्रित होता, तो क्या मोटे तौर पर यही बात लागू होती?
    यह ऊँची entry barrier वाली systems language है, compile time भी है, और ऐसी भाषा जो 10 साल से भी कम समय से व्यापक रूप से इस्तेमाल हो रही है, उससे Rails जैसी चीज़ों के साथ accessibility में compete करने की उम्मीद करना ज़्यादा है