- Hardcover टीम ने Next.js-आधारित संरचना में performance गिरावट, ऊँची लागत, और development speed कम होने की समस्याओं के कारण Ruby on Rails + Inertia.js पर migration किया
- SEO-सक्षम SSR support, सीधा DB connection, और React को बनाए रखना जैसी आवश्यकताओं को पूरा करने के लिए Inertia.js चुना गया
- Vercel और Cloud Run पर अनपेक्षित billing spike और Next.js की caching अनिश्चितता बदलाव का निर्णायक कारण बने
- Inertia.js, Rails backend और React frontend को जोड़ने का एक आदर्श तरीका साबित हुआ, जिससे SSR और cache management आसान हुआ
- बदलाव के बाद Google Pagespeed और SEO स्कोर बेहतर हुए, और site visit duration तथा search visibility बढ़ी
बदलाव की पृष्ठभूमि
- शुरुआत में SEO और SSR support देने वाले Next.js को चुनकर GraphQL API-आधारित architecture बनाया गया
- अधिकांश data ब्राउज़र में client-side request से लाया जाता था, जबकि static data को server पर cache किया जाता था
- समय के साथ caching की कमी के कारण API requests बढ़ीं, performance गिरी और development environment की speed भी धीमी हुई
Next.js में सामने आई समस्याएँ
- App Router में बदलाव के बाद भी speed improvement बहुत कम रहा, Apollo POST requests cache नहीं हुईं, इसलिए अपेक्षित असर नहीं मिला
- Vercel pricing policy बदलने से monthly cost $30 → $354 तक बढ़ गई
- Cloud Run भी शुरुआत में सस्ता था, लेकिन $524 तक पहुँच गया
- Next.js की caching structure को समझना कठिन था, इसलिए उसे प्रभावी ढंग से manage नहीं किया जा सका
- development speed काफ़ी धीमी हो गई, जिससे नए लोगों की onboarding मुश्किल हुई
Rails + Inertia.js चुनने की वजह
- SSR बनाए रखते हुए सीधे DB से data लाना चाहा गया
- React को जारी रखना था, और Remix, react-rails, react_on_rails भी देखे गए, लेकिन अंत में inertia-rails अपनाया गया
- Inertia.js में frontend routing के बिना Rails routing का इस्तेमाल किया जा सकता है, और SSR भी अपेक्षाकृत आसान है
- controller में
inertia: '페이지명' के साथ rendering संभाली गई, और caching को Rails.cache.fetch से लागू किया गया
- React components में
usePage() से props प्राप्त किए गए
SSR और build structure
- SSR के लिए
application.tsx में hydrateRoot / createRoot के बीच branching की गई
- Vite को एक स्वतंत्र server के रूप में चलाया गया, जिससे development के दौरान hot reload support मिला
- Docker और Kamal के ज़रिए Rails + Vite deployment automation किया गया, और staging व production को अलग रखा गया
- deployment के समय
make deploy command चलाई गई, और asset host के रूप में CloudFlare का उपयोग कर cache optimization किया गया
बदलाव का असर
- 18 मार्च 2025 को migration deploy होने के बाद Google search visibility बढ़ी और page speed बेहतर हुई
- Total Blocking Time में बड़ा सुधार हुआ, और Pagespeed score बढ़ा
- visitors का औसत time-on-site 3 मिनट → 6 मिनट की ओर बढ़ा
- traffic स्थिर रहा, और user sign-ups भी लगातार स्थिर बने रहे
आगे की चुनौतियाँ और सुधार बिंदु
- common layout reuse करना कठिन है, और हर page के पूरी तरह re-render होने की समस्या है
- SSR debugging कठिन है, और environment setup जटिल है
- Inertia.js और Rails के संयोजन पर documentation की कमी है, जिसे Discord community के सहारे सुलझाया गया
- Suspense के बजाय Inertia के तरीके के अनुरूप ढलने की ज़रूरत है
- अभी Hasura का उपयोग जारी है, इसलिए Inertia के form, flash जैसी कुछ features का इस्तेमाल नहीं हो रहा
निष्कर्ष और उम्मीदें
- React + Rails को स्वाभाविक रूप से एकीकृत करने वाली संरचना से development productivity और maintainability बेहतर हुई
- Inertia.js चुनकर speed, SSR, और type safety एक साथ हासिल किए गए
- आगे open source करने और contributors बढ़ाने की योजना है
2 टिप्पणियां
next.jsमेंLinkइस्तेमाल करने पर React Server Components के लिए URL में?_rsc=1ip3iजैसा हिस्सा बनकर प्रोसेस होने की वजह से विवाद हो रहा है। यह भी सुनने में आया है कि CDN उपयोग शुल्क बहुत बढ़ गया है, और कहा जा रहा है कि next.js डेवलपमेंट टीम भी इस समस्या से अवगत है, लेकिन इसे किस तरीके से और कब हल किया जाएगा, यह अभी तय नहीं है।Hacker News राय
server-side rendering (SSR) कभी गायब नहीं हुआ; वेब को अब बस याद आ रहा है कि यह शुरुआत से default क्यों था। पहला render और SEO आज भी तब बेहतर होता है जब markup server से आता है। Rails + Turbo, HTMX, Phoenix LiveView, React Server Components जैसे कई framework SSR को default मानते हैं। ज़्यादातर dashboard और CRUD apps को client router, global state, और 200kB hydration bundle की ज़रूरत नहीं होती; उन्हें सिर्फ़ partial HTML replacement चाहिए
असली प्रेरक शक्ति complexity की cost है। client JS की हर line के साथ build tools, npm audit का शोर, और supply-chain risk आता है। इस payload को कम करने से performance और security दोनों साथ में बेहतर होते हैं। बेशक, Figma या Gmail जैसे apps अब भी भारी client logic से फ़ायदा उठाते हैं। इसलिए "default में HTML, और JS सिर्फ़ जहाँ ज़रूरी हो" जैसा pattern उभर रहा है। पूरे SPA की बजाय islands के बारे में सोचना चाहिए
इसलिए server की ओर वापसी हो रही है, लेकिन यह 2004 के PHP के लिए nostalgia नहीं है। बात यह है कि JavaScript को सही जगह सीमित रखा जाए और HTML को वह 90% उबाऊ काम करने दिया जाए, जिसमें वह हमेशा से अच्छा रहा है
हमने कुछ projects में NextJS इस्तेमाल किया था, लेकिन अब हम इसे पहले से ही phase out कर रहे हैं। इसके कई कारण हैं, लेकिन कुछ मुख्य factors ये हैं
auth story मुश्किल है। next-auth में कुछ limitations थीं, इसलिए हमें iron-session इस्तेमाल करना पड़ा। उदाहरण के लिए, dynamic IdP domains इस्तेमाल नहीं कर सकते थे, इसलिए पूरा openid flow खुद संभालना पड़ा। यह संभव तो था, लेकिन एक mature framework से ऐसी अनपेक्षित time sink की उम्मीद नहीं थी
क्योंकि NextJS server हमारा मुख्य API gateway नहीं था, हमें हर request को proxy करना पड़ता था। docs साफ़ नहीं थे, और इसने request timeouts / max header size जैसी random समस्याएँ जोड़ दीं
framework cloud की ओर जाने के लिए बहुत आक्रामक push देता है, जो हमारे goals से टकराता था
maintainers खास तौर पर मददगार नहीं थे। बाकी tools/frameworks हम उनकी कमियों के बावजूद इसलिए इस्तेमाल करते हैं क्योंकि उनके maintainers बहुत approachable और helpful होते हैं (Chillicream/HotChocolate का धन्यवाद)
मुझे याद है कि पिछले साल Next.js के page router से app router पर जाने के बाद SEO में सुधार होने की एक blog post पढ़ी थी। इस बार हम Vercel की बढ़ती cost के कारण Next से React+Inertia.js पर जा रहे हैं। वही app अगर cloud provider की जगह अपने VPS पर deploy किया जाए तो समस्या हल हो जाएगी। लेकिन लोग यह complexity क्यों चाहते हैं, यह समझ नहीं आता। क्या book-tracking app को सच में GraphQL, अलग frontend framework और complex build process चाहिए, या यह काम शुरू से ही एक single RoR app को HTML templates के साथ VPS पर deploy करके हो सकता था?
जब भी मैं web और stack पर कोई article या discussion देखता हूँ, मैं खुद से पूछता हूँ, "असल में हम कौन-सी समस्या हल कर रहे हैं?" जवाब हमेशा होता है: "screen पर text दिखाना"
जब लोग JS full stack चाहते हैं, खासकर DB के साथ, तो वे क्या करते हैं, यह जानने की जिज्ञासा है। ORM की स्थिति काफ़ी fragmented है, या फिर आपको pure SQL लिखना पड़ता है। और फिर भी backend तय करना पड़ता है। क्या express इस्तेमाल करें? Next.js मशहूर है, लेकिन उसका agenda संदिग्ध लगता है। Remix, Astro, TanStack वगैरह। यह सब उलझाऊ है क्योंकि हमेशा दोबारा adjust और re-evaluate करना पड़ता है कि क्या इस्तेमाल किया जाए
personal projects में मैं अक्सर Ruby on Rails पर लौट आता हूँ। हमेशा आनंद आता है। दूसरी तरफ़, उपलब्ध Rails developers बहुत कम हैं (JS की तुलना में), इसलिए professional projects के लिए यह उतना उपयुक्त नहीं है। backend के लिए JS और अक्सर Java चुनना गैर-जिम्मेदाराना नहीं है
जानना चाहता हूँ कि क्या किसी और की भावना भी ऐसी ही है
frontend और backend developers लंबे समय से एक-दूसरे से ठीक से बात नहीं कर पाए हैं
ऐतिहासिक रूप से, backend developer के रूप में मुझे Html/JS/CSS से नफ़रत थी। यह Swing/Awt, WinForms, Android UX वगैरह से एक अर्थपूर्ण रूप से अलग paradigm है। सिर्फ़ इसी वजह से मैं frustrate हो जाता था और backend में ही बना रहा। frontend सीखने के लिए ये तीनों चीज़ें सीखनी पड़ती थीं। अब जाकर मैं इनके साथ सहज हो रहा हूँ
लेकिन frontend developers को "एक और भाषा" सीखनी पड़ती थी। कई भाषाओं के build systems nvm की तुलना में अलग और परेशान करने वाले होते हैं। और जैसा कि भाषा बदलने वाला हर व्यक्ति जानता है, आपको नए frameworks, paradigms वगैरह भी सीखने पड़ते हैं
इसके बजाय कुछ लोगों ने समझ लिया कि JavaScript को backend तक धकेला जा सकता है। इसमें बहुत-सी कमियाँ थीं, लेकिन "काम ख़त्म करो" वाले लोगों के लिए, खासकर उस दुनिया में जहाँ "और servers जोड़ दो" और "VC funding मुफ़्त है! infra पर जला दो!", ये कमियाँ चिंता की बात नहीं थीं
लेकिन frontend developers, जो अब "full stack developers" कहलाते हैं, जबकि असल में "everything in JavaScript" developers हैं, लगातार दिखाई देने वाले तरीक़े से चीज़ें बनाते रहे। यह आज LinkedIn job posts में दिखता है, जहाँ Next.JS/Node.JS/आदि roles माँगे जाते हैं। एक भाषा जो सब पर राज करे
बस कुछ विचार हैं, लेकिन मुझे लगता है कि ये काफ़ी मजबूती से इस बात से जुड़े हैं कि लोग Next.JS क्यों चुनते हैं
तकनीकी पक्ष पर मैं कुछ नहीं कह सकता (मैं सिर्फ़ Next.js से परिचित हूँ, Rails से नहीं, इसलिए यह साफ़ नहीं है कि यह लेख लेखक की Rails के साथ सहजता को दर्शाता है या तकनीकी रूप से अधिक उपयुक्त architecture को)। लेकिन मुझे यह अजीब लगता है कि कई software engineers वाली कोई company महीने के 1,000 डॉलर से कम infra cost की चिंता करे। hosting cost की चिंता करना समझदारी नहीं लगता
अगर Rails ने frontend frameworks के साथ interoperability के लिए असली first-class support पर ध्यान दिया होता, तो अब तक यह कहीं बड़ा होता। उसने Hotwire पर बहुत मेहनत की, लेकिन मैं React इस्तेमाल करना चाहता हूँ, और दूसरे लोग भी वही इस्तेमाल करना चाहेंगे जिसमें वे सहज हों
समझ नहीं आता कि Next.js vs. SSR पर बहस क्यों है। Next.js hybrid है और काफ़ी अच्छा काम करता है। दूसरे SPA frameworks के उलट, Next.js तेज़ first load के लिए pre-rendered HTML output देता है, efficient JS chunks, links पर hover करने या page render होने के बाद सभी n+1 links को preload करने जैसे config switches देता है, और breakpoints के हिसाब से efficient image (pre)loading भी देता है (जो pure SSR solutions के मुक़ाबले आम तौर पर Achilles' heel होती है)
मैंने थोड़ा Rails लिखा है, लेकिन लोग इसके लिए इतने उत्साहित क्यों होते हैं, यह मुझे ठीक से समझ नहीं आता। यह पूरी तरह ठीक था, लेकिन मुझे इसमें कुछ खास नहीं दिखा