Rails 7.1 जारी

• config.load_defaults 7.1 का उपयोग करने पर ActiveSupport::MessageVerifier और ActiveSupport::MessageEncryptor की डिफ़ॉल्ट serialization Marshal से ActiveSupport::JSON में बदल जाती है, और पुराने Marshal message अब भी पढ़े जा सकते हैं
• ActiveRecord::Base.serialize को डिफ़ॉल्ट रूप से YAML उपयोग न करने के लिए बदला गया है, और पुराना डिफ़ॉल्ट config.active_record.default_column_serializer = YAML से बहाल किया जा सकता है
• नया 7.1 cache format जोड़ा गया है और यह नए apps में डिफ़ॉल्ट रूप से उपयोग होगा; मौजूदा apps में इसे config.load_defaults 7.1 या config.active_support.cache_format_version = 7.1 से सक्रिय किया जा सकता है
  • 6.1 या 7.0 cache format में लिखी गई items को 7.1 format में पढ़ा जा सकता है
  • Rails 7.1 rolling deploy में पहले deploy पर cache format को यथावत रखना चाहिए, और उसके बाद वाले deploy में 7.1 cache format सक्रिय करना चाहिए
• :message_pack और :message_pack_allow_marshal serialization को MessageEncryptor, MessageVerifier, config.active_support.message_serializer में जोड़ा गया है, और इसके लिए msgpack gem >= 1.7.0 आवश्यक है
• ActiveSupport::KeyGenerator, MessageEncryptor, EncryptedConfiguration, और Active Record encryption objects के inspect में secret values exposure को रोका गया है, और ActionView::Helpers तथा ERB::Util की XSS सुरक्षा को मजबूत किया गया है
• has_secure_password में password_challenge validation और #{attribute}_salt method जोड़ा गया है, और authenticate_by को account existence के आधार पर होने वाले timing-based enumeration attacks को कम करने के लिए जोड़ा गया है
• Active Record में composite primary key·composite foreign key से संबंधित support बढ़ाया गया है, और tuple syntax where, composite key batch ordering, तथा schema में composite primary key inference का support जोड़ा गया है
• PostgreSQL support में enum name rename, value add, value change migration commands, exclusion constraint, unique constraint, INCLUDE index option, और NULLS [NOT] DISTINCT index support जोड़ा गया है
• SQLite3 adapter में Write-Ahead-Log normal syncing mode, capped journal size, shared memory buffer, shared cache settings के साथ औसतन 2× performance improvement बताया गया है, और double-quoted string literal को निष्क्रिय करने वाला strict strings mode डिफ़ॉल्ट रूप से सक्रिय है
• Active Record की full-table batch iteration अब डिफ़ॉल्ट रूप से range iteration का उपयोग करती है, जिससे performance बेहतर हुई है; PostgreSQL पर 1 करोड़ records के test में querying 253s→30s, updating 288s→124s, deleting 268s→83s के परिणाम दिए गए हैं
• MemCacheStore और RedisCacheStore में connection pooling डिफ़ॉल्ट रूप से सक्रिय है; इसे बंद करने के लिए cache store settings में pool: false देना होगा
• Trilogy database client के लिए adapter जोड़ा गया है, जिससे adapter: trilogy या trilogy:// फ़ॉर्मैट का DATABASE_URL उपयोग किया जा सकता है
• ActiveRecord::QueryLogs का डिफ़ॉल्ट tag format SQLCommenter format में बदल गया है, और config.active_record.query_log_tags_format = :legacy से पुराना format उपयोग किया जा सकता है
• deprecation और removal items में ActiveSupport::Deprecation singleton usage, SafeBuffer#clone_empty, #merge का rewhere argument, add_foreign_key का deferrable: true, TestFixtures#fixture_path, और कई deprecated Active Record settings व API cleanup शामिल हैं
• Action View tests में ActionView::TestCase.register_parser जोड़ा गया है, जिससे rendered result parsers register किए जा सकते हैं; डिफ़ॉल्ट parsers के रूप में :html और :json उपलब्ध हैं

[GN⁺]

Hacker News की राय

• Rails शानदार है, और अभी यह पहले से कहीं बेहतर हो गया है
  करियर की शुरुआत में मैं मुख्य रूप से Django और Laravel इस्तेमाल करता था, फिर बाद में आजकल आम तौर पर किए जाने वाले frontend काम की ओर चला गया, और इस साल फिर से Rails + Hotwire प्रोजेक्ट संभालना पड़ा
  यह कितना सरल हो गया है, देखकर सच में हैरानी हुई, और अफसोस है कि ज्यादातर लोग भूल चुके हैं कि चीजें इतनी आसान भी हो सकती हैं। यह भी डरावना है कि अभी industry में आने वाले लोग शायद ऐसी simplicity का अनुभव ही न कर पाएं
  अगर आपने Rails इस्तेमाल नहीं किया है, या “PHP बदसूरत है / Rails मर चुका है / JavaScript गंदी है” जैसी बातें सुनकर उसे छोड़ दिया है, तो सलाह है कि थोड़ी देर दूसरों की बातों को नजरअंदाज करके खुले दिमाग से एक बार इसे आजमाएं
  एक ही repository में 1,000 engineers के काम करने वाले माहौल के लिए यह शायद सबसे अच्छा न हो, लेकिन छोटी टीमों के लिए इसका कोई मुकाबला नहीं है और यह बाकी चीजों से बहुत आगे है। ईमानदारी से कहूं तो Laravel भी लगभग उतना ही अच्छा हो सकता है

  • इसमें Phoenix LiveView को भी शामिल करना चाहूंगा
    शुरुआती development speed में मुझे लगता है Rails हमेशा जीतता है। conventions इतने सघन और अच्छी तरह design किए गए हैं कि इसके करीब आने वाली चीजें बहुत कम हैं। Laravel करीब आ रहा है, लेकिन मेरी नजर में अभी वहां नहीं पहुंचा है
    हालांकि LiveView हर मायने में ज्यादा अच्छी तरह scale होता है। authentication, database access, job queues, mailers, पूरा testing toolset जैसी कई चीजें built-in हैं, direct JavaScript लगभग लिखनी नहीं पड़ती, और शानदार virtual machine BEAM भी है
    कम से कम यह अच्छा है कि ये सभी projects “एक कदम पीछे हटें” वाली लड़ाई लड़ रहे हैं। काम पर हम React और Relay इस्तेमाल करते हैं, और frontend JavaScript लंबे समय से इस्तेमाल करने और खुद को कुछ हद तक ठीक-ठाक मानने के बावजूद, पार करने के लिए इतनी बाधाएं हैं कि थकान हो जाती है
  • Django से तुलना करें तो यह दिलचस्प है कि कम से कम अभी दोनों को एक ही स्तर पर नहीं देखा जा रहा। जिज्ञासा है कि Rails को Django पर प्राथमिकता देने की कोई ठोस वजह है क्या
  • मुझे Rails पसंद है, लेकिन मेरे देश में लगभग कोई इसे इस्तेमाल नहीं करता, और जो कंपनियां इस्तेमाल करती हैं वे लगभग जादूगर-स्तर के developers ढूंढती हैं
    नौकरी नहीं मिलती, इसलिए पर्याप्त अनुभव भी नहीं बन पाता, और आखिरकार ऐसे जादूगरों से पीछे रह जाता हूं। वे job postings 12 महीने से ज्यादा समय तक खुली भी रहती हैं
    इसके बजाय, जहां demand है वहां दुनिया में और ज्यादा JavaScript फैला रहा हूं
  • मेरे जानने वाले काफी Rails developers ember.js पर चले गए। वजह यह है कि ember.js भी ऐसा convention-based framework है, न कि ऐसा जहां ढेरों third-party plugins लगातार टूटते रहें
    structural रूप से मुझे ember-data वाला approach पसंद है। datasets के left join/right join जैसे कामों में बहुत कुछ automate किया जा सकता है, और integrated mock server भी है
    हालांकि शायद यह इतना अच्छे से काम करता है कि बाकी चीजों जितना cool नहीं दिखता
    https://emberjs.com/

• 13,000 लाइनों वाली Rails 7.0 app को 7.1 पर upgrade किया, और 7.0 व 7.1 के अंतर[0] को छोड़ दें तो test setup code की सिर्फ 1 line बदलकर सब कुछ चल गया
  आसान upgrade path के लिहाज से इसे सफलता मानता हूं। अब मजेदार हिस्सा 7.1 के नए features इस्तेमाल करने के लिए कुछ code refactor करना है
  अगर रुचि हो तो Rails / Docker example app को भी 7.1 पर upgrade कर दिया है https://github.com/nickjj/docker-rails-example
  Rails 7.1 में Dockerfile शामिल जरूर है, लेकिन Docker Compose इस्तेमाल करके development और production में तुरंत काम करने वाला experience बनाना, और Postgres, Redis, Action Cable, Sidekiq आदि शामिल करना—इस तरह अभी भी जोड़ने के लिए कई विकल्प हैं
  [0]: https://railsdiff.org/7.0.8/7.1.0

• काफ़ी बड़े Rails 6 codebase में React बहुत ज़्यादा जुड़ा हुआ है, और उसे Hotwire इस्तेमाल करने वाले नए “non” JavaScript तरीके पर ले जाने की कोशिश कर रहा/रही हूँ। शुभकामनाएँ देना
  Rails तब शानदार है जब आप defaults पर टिके रहते हैं, लेकिन जैसे ही उन defaults से बाहर जाते हैं, यह दर्द की ज़मीन बन जाता है

  • मैं अपेक्षाकृत हाल के Rails 7 codebase पर काम कर रहा/रही हूँ। शुरुआत में Stimulus इस्तेमाल करना शुरू किया था, लेकिन कुछ वजहों से React पर switch करने पर विचार कर रहे हैं
    frontend engineer hire करने के लिए React candidates का pool कई orders of magnitude बड़ा है। आम कामों के लिए vanilla JavaScript package ढूँढकर उसे Stimulus controller में wrap करना भी React package ढूँढने से लगातार मुश्किल होता जा रहा है
    Stimulus controller unit tests लिखने का कोई खास तरीका भी नहीं देता। React में हमेशा की तरह jest और react-test-renderer इस्तेमाल कर सकते हैं
    ऊपर से हाल की Turbo TypeScript controversy ने Hotwire ecosystem के long-term maintenance पर भरोसा नहीं दिलाया
    अभी फैसला नहीं लिया है। यह ज़रूर एक फायदा है कि Stimulus frontend code लिखने का बहुत Rails-जैसा तरीका लगता है, खासकर उन छोटी teams के लिए जो पहले से Rails से familiar हैं
  • “Rails defaults पर रहें तो अच्छा है और उनसे हटें तो दर्दनाक” — यह बात हर framework पर लागू होती है
    अगर application काफ़ी simple है और framework के तरीके से अच्छी तरह fit बैठती है, तो framework शानदार होता है। अगर ज़्यादा complex और flexible setup चाहिए, तो libraries देखनी चाहिए
  • Rails के JavaScript integration पर भरोसा खो चुका/चुकी हूँ
    अब या तो slim से server-side rendering करता/करती हूँ, या API-only बनाकर frontend अलग कर देता/देती हूँ
    Rails ने JavaScript करने के लिए CoffeeScript, asset precompilation, webpack आदि में बहुत बार दिशा बदली है
  • मौजूदा React frontend को Hotwire पर ले जाने का काम Rails के अपने upgrade के साथ-साथ करने की सलाह नहीं दूँगा/दूँगी। मेरे हिसाब से पहले independently Rails 7.1 तक upgrade करना बेहतर है
    वैसे Rails 7+ में single-page app JavaScript handle करने का तरीका भी पहले से कहीं ज़्यादा reasonable है। असल में जो build tool चाहें, उसे Rails app से अलग रखकर इस्तेमाल कर सकते हैं
    development के दौरान rails s के साथ yarn build --watch जैसा कुछ साथ में चलाना पड़ता है, लेकिन निजी तौर पर मुझे यह बुरा नहीं लगता और काफ़ी simpler लगता है
    हमारी company Rails upgrades automate करने वाला software बनाती है, और Rails upgrade आपके लिए कर देने वाली पूरी service भी देती है। दिलचस्पी हो तो steve (at) infield.ai पर contact करें या https://app.infield.ai/users/sign_up पर free Rails upgrade plan generate कर सकते हैं। credit card की ज़रूरत नहीं
    अधिक जानकारी के लिए https://docs.infield.ai/docs/creating-an-upgrade-path देखें
  • https://vite-ruby.netlify.app/guide/rails.html आज़माने की सलाह दूँगा/दूँगी
    मेरे मामले में यह लगभग webpack replacement की तरह सीधे fit हो गया

• मुझे Rails पसंद है और Rails 2 के समय से इसे बीच-बीच में इस्तेमाल करता/करती आया/आई हूँ
  यह बहुत अच्छा framework है, और मेरे जैसे व्यक्ति के लिए, जिसे कभी-कभी website चालू करनी पड़ती है, यह सच में least resistance वाला path है
  लेकिन नए laptop पर Rails चलाने के लिए setup करना तकलीफ़देह है। node चाहिए, तो npm भी चाहिए। backend developer होने के कारण मुझे ठीक से नहीं पता कि node कैसे setup करना है, किस order में करना है
  यह काम अक्सर नहीं करता/करती, इसलिए हर बार लड़ाई जैसा लगता है। आखिरकार हो जाता है, लेकिन यह हमेशा साफ़ नहीं होता कि अंत में सब कुछ कैसे ठीक से match हो गया
  काश कोई installer हो जो ज़रूरी चीज़ें एक साथ setup कर दे ताकि rails बस चल पड़े। rvm installer ruby के ऊपर rails setup कर देता है, लेकिन उसके नीचे वाला node system setup नहीं करता

  • asdf नाम का version manager nodejs manage करने के लिए अच्छा है। Ruby के साथ मैंने इस्तेमाल नहीं किया है
    https://asdf-vm.com/
  • “backend developer हूँ इसलिए node setup नहीं जानता/जानती” वाली बात समझ आती है
    Node मुख्य रूप से frontend tooling के रूप में जाना जाता है और Rails भी इसे उसी काम के लिए इस्तेमाल करता है, लेकिन मेरी याद में Node कम-से-कम शुरुआत में JavaScript runtime को backend पर लाने के लिए बनाया गया था
    package manager के बिना भी Windows पर यह बस node.exe होता है, और मेरी जानकारी में npm download करके extract करना और node तथा npm को PATH environment variable में डालना ही होता है
  • Rails 7 का पूरा premise ही node dependency हटाना है
  • मैंने Rails कभी इस्तेमाल नहीं किया, इसलिए जिज्ञासा है कि “Ruby on Rails” को nodejs की ज़रूरत क्यों पड़ती है
    और node install करना काफ़ी आसान है। असल में बहुत ही आसान। काश यह बहुत ज़्यादा मुश्किल होता और इसके लिए degree चाहिए होती
  • Ruby/Rails community मैंने जितनी देखी हैं उनमें सबसे अच्छी और friendly communities में से है। लेकिन उसमें सबसे खराब चीज़ निस्संदेह JavaScript से नफ़रत है
    JavaScript भी बाकी चीज़ों की तरह एक tool ही है। पसंद हो या न हो, यह बहुत महत्वपूर्ण tool है, और पसंद हो या न हो, लंबे समय तक रहने वाला है
    थोड़ा open mind रखकर कम-से-कम basics सीख लें तो काम आसान हो जाएगा

• उम्मीद है Rails + HTMX और सिर्फ़ बहुत ज़्यादा interactive pages पर थोड़ा-सा JavaScript छिड़कने वाला तरीका फिर से popular होगा
  Rails को Slim/HAML के साथ इस्तेमाल करना सच में मज़ेदार है। चाहें तो ViewComponents जैसी library से partial rendering और आसान कर सकते हैं। इसमें web components जोड़ दें तो काफ़ी interactive pages बना सकते हैं, और किसी specific page पर सच में ज़रूरत हो तो React भी इस्तेमाल कर सकते हैं
  HATEOAS application complexity को काफ़ी कम कर देता है। फिर भी अगर API चाहिए, तो अलग-अलग MIME types का response देना भी बहुत आसान है, और चाहें तो वही endpoint share भी कर सकते हैं
  अनुभव के हिसाब से React इस्तेमाल करने वाली ज़्यादातर applications को असल में React की बिल्कुल ज़रूरत नहीं होती। कुछ popup menus की वजह से React इस्तेमाल किया जाता है
  इसलिए जब React के बिना, या बहुत थोड़े React के साथ बड़े apps आने लगेंगे, तो उम्मीद है कुछ लोगों को एहसास होगा कि आज हमारी applications कितनी unnecessary complex हैं
  लेकिन मैं पहले से ही “सब React इस्तेमाल करते हैं, इसलिए हमें React पर बदलना चाहिए” वाली बातें देख रहा/रही हूँ। आह निकलती है
  सपना तो देखा जा सकता है

• आधिकारिक घोषणा यहाँ है: https://rubyonrails.org/2023/10/5/Rails-7-1-0-has-been-released
  इसमें high-level details थोड़ी और हैं, और नए बदलावों में से कुछ को आज़माने को लेकर उत्साहित हूँ। खास तौर पर नया async query methods तेज़ performance सुधार के लिए काफ़ी उपयोगी लगता है

• backend में Rails को जितनी सराहना मिलनी चाहिए, उतनी नहीं मिलती
  लेकिन frontend वाला हिस्सा बहुत लंबे समय तक बिखरा हुआ था

  • “frontend वाला हिस्सा लंबे समय तक बिखरा था” इससे असहमति नहीं है, लेकिन frontend खुद भी लंबे समय तक बिखरा ही था
    अब Rails 7.1 + Hotwired + Importmaps के साथ काम करना मज़ेदार है
    मगर browsers में कम-से-कम ES6 और Import Maps का support अच्छा होने तक इंतज़ार करना पड़ा
    इस लेख की तारीख देखें तो https://web.dev/import-maps-in-all-modern-browsers/ में 28 मार्च 2023 को घोषणा हुई कि सभी modern browsers में importmaps इस्तेमाल किए जा सकते हैं
    इसलिए अब तक Webpack, Yarn और बाकी JavaScript सहायक tools से बचने का कोई तरीका नहीं था
    अब importmaps हैं और browser का ES6 support भी काफ़ी अच्छा है, इसलिए https://caniuse.com/?search=es6, लगभग बिना extra tools के modern JavaScript इस्तेमाल की जा सकती है
  • सहमत हूँ। यहाँ विकल्प क्या हैं? Rails का API-only mode?
  • नए Hotwire features पसंद हैं। frontend में क्या पसंद नहीं आ रहा, यह जानने की उत्सुकता है

• कुछ हफ्ते पहले एक दोस्त ने मज़ाक में कहा, “अगर Rails release announce हो गया और तुमने upgrade PR नहीं डाला, तो क्या वह सच में हुआ भी?”
  चलो, अब PR डालने का समय है। भले ही उसे कई महीनों से pending 7.0 PR के पीछे stack करना पड़े

• अनुभव से, कई teams को ActiveRecord के साथ साफ़ codebase बनाने में मुश्किल होती है

• कृपया मारना मत, लेकिन मैं अभी भी Rails 4.2 इस्तेमाल कर रहा हूँ और संतुष्ट हूँ
  बिना JavaScript या कम JavaScript वाले backend SaaS काम के लिए, जो मैं खुद करता हूँ या B2B companies के लिए करता हूँ, इसमें सब कुछ मिल जाता है, और यह low-spec VPS पर भी चलता है
  अगर जवाब देने का समय हो, तो जानना चाहूँगा कि upgrade क्यों करना चाहिए

  • मैं भी पुराना version इस्तेमाल करता हूँ। पहले यह देखना चाहिए कि latest patch/minor version तक जा सकते हैं या नहीं
    पुराने version की मुख्य समस्या उससे जुड़े gems की vulnerabilities हैं। उदाहरण के लिए nokogiri को Rails major upgrade के बिना upgrade नहीं किया जा सकता हो सकता है
    हालांकि ज़्यादातर apps, मान लें complex XML parsing नहीं करते, इसलिए काफी vulnerabilities लागू नहीं होतीं। इसलिए यह पक्का करने के लिए थोड़ा maintenance चाहिए कि यह सुरक्षित है। bugs रोकने के लिए monkey patches डालना भी अक्सर होता है
    upgrade करने से security बेहतर होती है और maintenance time घटता है। लेकिन लगातार upgrades की लागत भी ध्यान में रखनी चाहिए। एक और factor यह है कि नए versions में तेज़ Ruby का support मिल सकता है
    आम तौर पर Rails app बनाते समय latest release इस्तेमाल करता हूँ, लेकिन जब तक app लोकप्रिय न हो या इतना पुराना न हो कि नए systems पर कुछ काम न करे, बाद के Rails versions पर upgrade नहीं करता
  • security की वजह से upgrade करना चाहिए