Rails for Everything - हर चीज़ के लिए Rails की शक्ति

 (literallythevoid.com)
7 पॉइंट द्वारा GN⁺ 2025-01-03 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Rails 8 छोटे प्रोजेक्ट और अकेले डेवलपर के लिए बहुत उपयोगी है
  • नवीन शुरूआती गाइड के साथ production-level ऐप को आसानी से बनाया जा सकता है
  • SQLite में सुधार से अतिरिक्त server बिना मजबूत database environment सेटअप संभव है
  • built-in continuous integration (CI) और authentication generator से development efficiency और security दोनों बेहतर होते हैं
  • Kamal के जरिए आसान deployment से सेवा को तेज़ और सुरक्षित तरीके से चलाया जा सकता है

अवलोकन

  • Rails 8 के वास्तविक उपयोग अनुभव के आधार पर यह छोटे प्रोजेक्ट और व्यक्तिगत डेवलपर्स के लिए एक उत्कृष्ट वेब फ्रेमवर्क है
  • तेज़ निर्माण, efficient deployment और built-in modules की वजह से productivity में अन्य प्रतिस्पर्धी frameworks की तुलना में स्पष्ट बढ़त दिखाई देती है

नवीन स्टार्टिंग गाइड की ताकत

  • नया Getting Started with Rails गाइड ऐसा बनाया गया है कि शुरुआती लोग भी production ऐप बना सकें
  • Ruby install प्रक्रिया में अभी भी थोड़ी जटिलता है, लेकिन गाइड के निर्देशों का पालन करने पर authentication, caching, rich text, continuous integration, database सहित एक मजबूत सेवा बनाई जा सकती है
  • केवल ‘Hello World’ नहीं, बल्कि वास्तविक production-grade बेसिक्स और फीचर्स देने की क्षमता इसकी खासियत है
  • Rails से अनजान शुरुआती लोगों के लिए यह बेहतरीन starting point है

सिर्फ SQLite ही काफी है

  • SQLite डिफ़ॉल्ट रूप से एक अच्छा tool है, लेकिन पहले production में इसे आसानी से setup करना कठिन था
  • पहले अतिरिक्त gems install करने जैसे अलग काम करने पड़ते थे, जबकि Rails 8 में बिना अतिरिक्त सेटअप के भी production environment में इसे भरोसेमंद तरीके से चलाया जा सकता है
  • PostgreSQL या अलग server चलाने की जरूरत नहीं, और solid cache का इस्तेमाल करने पर redis server भी आवश्यक नहीं होता
  • केवल Rails और SQLite से सेवा चल सकती है, जिससे setup और ops की सरलता तथा cost efficiency बढ़ती है

आसान continuous integration (CI)

  • शुरुआती commit के बाद भी continuous integration (CI) failure alert आने तक की व्यवस्था है, क्योंकि Rails 8 में built-in integrated CI setup उपलब्ध है
  • बिना अतिरिक्त काम के GitHub Actions से जुड़ जाता है और हर महीने 2,000 मिनट का free रन टाइम मिल सकता है
  • अकेले डेवलपर के लिए यह पर्याप्त और आरामदेह समय है

authentication generator का समावेश

  • पहले Devise जैसे authentication gems शक्तिशाली थे, लेकिन सेटअप की जटिलता के कारण शुरुआत करने वालों को कठिन लगते थे
  • Rails 8 में आसान authentication generator जोड़ा गया है, जिससे console से उपयोगकर्ता जोड़कर आसान login flow implement किया जा सकता है
  • जेनरेट किया गया code सरल और आसानी से पढ़ने योग्य है, इसलिए शुरुआत करने वाला भी आसानी से समझ सकता है

Kamal से आसान और तेज़ deployment

  • deployment प्रक्रिया की जिम्मेदारी Kamal संभालता है; deploy.yml फ़ाइल का थोड़ा हिस्सा बदलकर और निर्देशों का पालन करके तुरंत SSL environment में app चलाई जा सकती है
  • GitHub Pages पर SSL जोड़ने से भी तेज़ web app deployment अनुभव मिलता है
  • continuous integration (CI) और आसान deployment का मेल Rails 8 की सबसे उभरती खूबियों में से एक है
  • सिर्फ introduction/guide follow करने पर भी latest best practices के हिसाब से development experience मिल जाता है

निष्कर्ष

  • Rails अभी भी एक शक्तिशाली और evolving framework है
  • अगर इस साल नया project शुरू करने पर विचार कर रहे हैं, तो Rails 8 पर development शुरू करना वाकई कोशिश करने लायक है

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

2 टिप्पणियां

 
aer0700 2025-01-06

पिछले कुछ समय से SQLite पर बहुत-सी पोस्ट्स दिख रही थीं, अब तो जैसे हर चीज़ ही SQLite हो गई है। इसे पुराने दौर के ट्रेंड की वापसी कहा जाए क्या?
 
GN⁺ 2025-01-03
Hacker News टिप्पणियाँ
  • अभी मैं Spring Boot और Micronaut स्टैक से ऐप्स बना रहा हूँ, और साथ में React फ्रंटएंड भी चला कर देख रहा हूँ। Rails का omakase (सब कुछ पहले से उपलब्ध/बिल्ट-इन) तरीका सच में बहुत काम आता है। बैकएंड से आने वाली बेसिक फॉर्म वैलिडेशन या flash messages जैसी सरल features को framework सीधे नहीं संभालता, इसलिए उन्हें खुद implement करना पड़ता है या तीसरे पक्ष की dependency खोजनी पड़ती है। Rails वेब ऐप्स के करीब 90% सामान्य problems पहले से ही solve कर देता है। इसे बिल्कुल perfect नहीं कहा जा सकता, लेकिन ज़्यादातर मामलों में built-in विकल्प पर्याप्त होते हैं और ज़रूरत हो तो किसी भी समय replace किया जा सकता है।
    • Spring Boot में फॉर्म वैलिडेशन लगभग डिफ़ॉल्ट में उपलब्ध है और annotation के साथ सीधे use किया जा सकता है।
  • Rails और Django दोनों ही बेहतरीन frameworks हैं। मैं Python से mission-critical apps भी बना चुका हूँ। लेकिन बड़े monolith development के लिए Go की ओर जाना चाहता हूँ क्योंकि Go का type system और concurrency मुझे ज्यादा मजबूत लगता है। समस्या यह है कि Go ecosystem Rails या Django जैसे framework ecosystem नहीं बना पाया। Go से networking tools या CLI लिखना बहुत अच्छा हो सकता है, लेकिन जल्दी full-stack web app build करनी हो तो अभी भी Rails या Django choose करता हूँ। इसलिए “Rails खत्म हो गया” जैसा statement मुझे अभी तक सच नहीं लगा।
    • ogen जैसे tools की मदद से एक ही OpenAPI document से static router, request/response validation, Prometheus monitoring, OpenTelemetry tracing जैसी लगभग सारी चीज़ें auto-generate की जा सकती हैं। client और webhook code generation भी हो जाती है; auth के लिए बस एक फीचर और जोड़ना पड़ता है। sqlc और SQLite के pragma user_version को combine करने पर type-safe DB code और migration भी आसान हो जाते हैं। SQLite जोड़ना भी सिर्फ main.go में दो import lines डालने जितना आसान है। Go के standard templates से ही frontend text handling पर्याप्त है, और embed की वजह से static assets को binary में आसान तरीके से शामिल किया जा सकता है। सीधे deployment में सिर्फ go build करके binary move कर दीजिए और काम हो गया—deployment बहुत simple हो जाता है। code generation tools की वजह से Go backend development बहुत तेज़ और आसान हो गया।
    • मैं भी static type वाला complete stack चाहता था, लेकिन Go या Rust की तुलना में ASP.NET ही साफ़-साफ़ सही जवाब लगा। Microsoft कई बार नए products (जैसे Aspire.NET) का प्रचार करता है, लेकिन असल में .NET Core (C#, ASP.NET Minimal API/MVC, EF Core) ही सच में battery-included और ज्यादा reliable है। थोड़ा सा OOP और DI mindset shift लगता है, पर experienced developer के लिए कोई बड़ी समस्या नहीं।
    • Go ecosystem की समस्या सिर्फ anti-framework mindset नहीं, बल्कि anti-modern features mindset भी है। Java, Kotlin, Scala, C#, F# आदि network tools या CLI development के लिए अच्छे हैं। आजकल Java AOT में भी commercial license को लेकर चिंता कम है और .NET भी सिर्फ Windows तक सीमित नहीं रहा।
    • मैं Encore recommend करना चाहूँगा। खासकर जब PaaS integration करना हो (NextJS+Vercel combo की तरह), यह बहुत powerful है। Go के core principles से थोड़ा अलग हो सकता है, लेकिन छोटे टीमों या 1-person teams के लिए बेहद अच्छा विकल्प है। चाहो तो BYOC से सीधे deploy करो या stdlib से direct API layer भी चला सकते हो—कोई बड़ी दिक्कत नहीं। Frontend के लिए NextJS या Remix/RR7 चाहिए, लेकिन TypeScript client SDK auto generation से integration बहुत आसान है। Encore में Vercel PR integration भी है, जो बड़ा plus है।
    • Go में Django जैसा अनुभव देने वाला framework खोजें तो beego शायद अब तक का सबसे बेहतर विकल्प लगता है। फिर भी इसकी maturity अभी पर्याप्त नहीं, इसलिए इसे Django या Rails के लेवल का नहीं कह सकता।
    • अभी मैं एक Go project पर काम कर रहा हूँ और सच में clean code देखकर खुश हूँ। AI ने framework adoption का entry barrier पार करने में बहुत मदद की। फिर भी मुझे लगता है कि customer-facing services में Rails, जबकि internal tools/data work में Django अधिक intuitive है।
    • Ruby में भी Sorbet से type check संभव है, और Fiber से supported concurrency फंक्शन लगभग complete stage में है। नया Falcon नाम का web server Fiber पर build हो रहा है। अभी यह Puma जितना mature नहीं है, लेकिन जल्द ही full production use के लिए ready हो जाएगा।
    • Stanza language के author ने एक interesting insight लिखी कि Rails जैसे strong framework के लिए language-level constraints जरूरी होते हैं। Go या Java में ऐसे frameworks न होना भाषा की सीमा (या programmer की सीमा) का combined परिणाम लगता है।
    • Go शुरुआत से ही Rails/Django जैसी full-stack framework orientation के लिए design नहीं था।
    • Node/Express local developers के लिए pico-service level के लिए ठीक हैं, जबकि ASP.NET WebAPI/MVC मेरे लिए ideal backend है।
    • goravel dev भी एक बार use करके देखना चाहिए।
  • Rails Guides को start से end तक follow करो तो authentication, caching, rich text, CI, DB शामिल करके तुरंत एक actual service रिलीज़ की जा सकती है। लेकिन GitHub, Airbnb जैसे giant services के लिए भले ठीक हो, initial startup में Devise auth, turbo, tests जैसी अतिरिक्त/built-in features शुरू से सब जोड़ना शायद उल्टा समय की बर्बादी हो। turbo में page load तेज होने का benefit है, लेकिन devise feature से टकराकर development time बढ़ भी सकता है। Public launch से पहले सिर्फ idea validation stage में (banking/healthcare apps को छोड़कर) tests या CI को बाद में रखने से कोई बड़ा issue नहीं। default bias (available है इसलिए use करना) में मत फंसो और confidently कहो कि “अभी नहीं उपयोग करेंगे” अगर जरूरत न हो।
    • अगर आप SaaS app बना रहे हैं तो Jumpstart Pro या Bullet Train जैसे Rails विशेषज्ञ templates से शुरुआत करने पर कई महीनों का development time बच सकता है। इनमें पहले से billing, auth जैसी बेसिक functionalities आती हैं और बाद में expand करना आसान रहता है।
    • टेस्टिंग पर मेरा मत अलग है। लगभग छोटे app में भी test code होने पर उल्टा समय बचता है। CI भी आमतौर पर सिर्फ 20 लाइन की file से सेट हो जाती है; पुराने projects में मैंने copy-paste करके use किया है।
    • CI development speed increase करने वाला factor है। इसे project के शुरुआती चरण में ज़रूर डालना चाहिए।
    • Flask/Express/Sinatra/Gradio/Hono आदि से Rails में switch करने का सही point क्या होता है, यह जानना चाहता हूँ।
  • नए Rails को देखकर सच में अच्छा लगता है कि पहले से ज्यादा चमकदार लग रहा है। मैंने Rails 2.3 के बाद से लगभग 12 साल तक कई अलग apps maintain की हैं; अभी का Rails एकदम अलग evolving Pokémon जैसा महसूस होता है। Rails Upgrade Guide बहुत साफ़ और structured है, इसलिए बिना बड़े refactor के मैं एक साथ upgrade कर पाया। यह पूर्णतः backward compatible नहीं है, लेकिन बदलावों का clear documentation होना बड़ा advantage है। ActiveStorage की वजह से file attachments में भी significant improvement हुआ। Webpacker migration में थोड़ा struggle हुआ था, पर Import Maps feature के बाद अब आसान लग रहा है। इस साल 8.1 पर upgrade करने का plan है।
    • चार साल पहले budget कम वाले ग्राहक के लिए pay-cut accept करके पुराने Rails app को maintain करने का decision लिया था (Ruby 2.3 के ज़माने में)। इसलिए overall upgrade और feature additions सच में काफी आसान रहे और मैं बहुत satisfied हूँ।
  • मैं एक open-source Rails project अकेले develop करके महीने के 120k users support कर रहा हूँ, इसलिए ऊपर वाली बातों से मैं काफी strongly agree करता हूँ। एक और बात, ActiveStorage के attachment features शानदार हैं। Deployment में मुख्यतः Dokku use किया, लेकिन Kamal देखने का excitement है। Rails लगातार evolve हो रहा है और Ruby भी धीरे-धीरे तेज़ हो रहा है।
    • अगर आपको Dokku पसंद है तो क्या आपने Cloud Native Buildpacks आजमाया है? इससे सीधे OCI image बनाना possible है।
  • Ruby सीखने पर मैं पहले ज्यादा फोकस नहीं दे पाया क्योंकि web dev share बड़ा नहीं था, इसलिए मुझे mostly Django ही पता था। दोनों frameworks compare करके फर्क क्या है, जानने की जिज्ञासा है।
    • दोनों ecosystems में मेरा लंबा अनुभव है (हाल में rails कम किया है)। Django python से, rails ruby/gem से tightly जुड़ा है, इसलिए ecosystem का असर बहुत महत्वपूर्ण है। Django admin CMS rails से काफी मजबूत है, कई संगठन अपना पूरा internal CMS भी django पर करते हैं। Rails में massive scaffolding CLI है जिससे CRUD बनाना बहुत तेज़ है। Rails का abstraction level ज्यादा high है और structure/architecture लगभग तय हो जाती है, जबकि Django में खुद चुनना ज्यादा पड़ता है। DRY और duplication हटाने पर Rails ज्यादा जोर देता है। Pythonic intuition को प्राथमिकता देने वालों को Rails की magic थोड़ी भारी लग सकती है, जबकि Rails side में वालों को Python की repetition थोड़ा rough लग सकता है। मूल रूप से दोनों अलग style के हैं।
    • अगर मुझे एक web app (consumer facing product) बनानी हो तो पहले rails चुनूँगा। मुझे लगता है कि scaffolding और market launch तक पहुंचना आसान है (हालाँकि मेरे पास real large-scale service का अनुभव नहीं)। internal tools, data work, geospatial systems के लिए शायद python/django बेहतर है।
    • सबसे बड़ा फर्क python vs ruby है। python ecosystem बहुत बड़ा है और Django में auth तथा built-in admin उपलब्ध है।
    • test environment में rails का अनुभव बेहतर लगता है। Rails में CI setup और test code auto-generation दोनों मिलते हैं।
    • Django Admin मुझे अनुभव से ruby alternatives से कहीं ज्यादा flexible और आसान लगता है। जबकि testing और routing में Rails बेहतर है और conventions भी strong हैं। मुझे ActiveRecord+arel Django ORM से ज्यादा पसंद है (personally मुझे Ruby में code लिखना Python से ज्यादा मज़ेदार लगता है)।
    • Ruby सीखना बहुत कठिन नहीं है, और Rails Django की तुलना में कहीं ज्यादा structure और conventions पहले से दे देता है।
  • बहुत से लोग Rails के साथ लगभग romance-जैसा attachment रखते हैं, जबकि मैं उस level तक नहीं पहुँच पाता और कभी-कभी jealous feel करता हूँ। किसी भी language/framework की fan base होती है, लेकिन Rails वाली heat थोड़ा अलग लगती है।
    • Rails की conventions से मुझे कई बार discomfort होता है, लेकिन JavaScript backend पर वही productivity निकालने की कोशिश करो तो लगभग असंभव लगेगा। दूसरी तरफ, जब rails code handle करना पड़ता है, तो कई बार बिना जरूरत के rails की default features (जैसे Active Job) को हमने खुद से reimplement किया हुआ भी देखा। conventions follow करना अक्सर ज्यादा efficient होता है।
  • जब मैंने SQLite को production में use किया, migration से आखिरी में काफी परेशानी हुई। उदाहरण के लिए, existing column में NOT NULL constraint जोड़ने के लिए temporary table बना कर पूरा table rewrite करना पड़ता है।
    • SQLite में ADD CONSTRAINT भी नहीं होता, और PL language या simple stored proc support नहीं करता, इसलिए बार-बार host language roundtrip करना पड़ता है—खासकर statically typed languages में यह भारी पड़ता है।
    • मुझे लगता है कि Postgres सबसे अच्छा विकल्प है, इसलिए उसे छोड़ना आसान नहीं है। फिर भी Rails में sqlite3 का first-class option बनना सकारात्मक बदलाव है।
    • Rails की default recommendation में कहीं-कहीं लगता है कि sqlite Redis को replace कर सकता है, लेकिन practically यह सिर्फ small service शुरुआत के लिए ठीक है। अगर बाद में DB बदलनी पड़े तो शुरुआत sqlite से नहीं करनी चाहिए क्योंकि migration हमेशा painful होती है।
    • Rails में ActiveRecord validation से अधिकांश चीजें manage हो जाती हैं, लेकिन fundamental constraints reflect करने में limits हैं।
  • Ruby installation guide थोड़ी complex है। मैंने 15 साल बाद jekyll blog setup करते समय gems आदि में काफी देर लगा दी। इसमें मेरी गलती भी थी, लेकिन अगर यह थोड़ा आसान होता तो बेहतर होता। फिर भी यही कारण बना कि मैं Ruby फिर से try करना चाहता हूँ।
    • setup किसी के लिए भी easy होना चाहिए। Jekyll जल्दी सीख पाया क्योंकि मेरे environment में पहले से Ruby और RubyGems मौजूद थे।
  • अगर केवल sqlite use करना है तो litestack को एक बार check कर सकते हैं। मैंने सीधे नहीं use किया, लेकिन personal project को postgres से litestack पर shift करने का plan है। benchmark performance सच में impressive है।
    • Rails 8 में sqlite काफी मजबूत हुआ है, फिर भी क्यों जरूरत पड़ेगी litestack की? कोई differentiation क्या है, यह जानने की इच्छा है।