React एक full-stack framework है (या बनता जा रहा है)

• Server Components और Server Actions जोड़ने वाला React, full-stack framework के रूप में विकसित हो रहा है

2010 में framework युद्ध की शुरुआत

• 2010 में Backbone, Knockout, Ember से शुरू हुआ framework युद्ध, जिसके बाद Angular और React तेज़ी से आए, और इसका नतीजा कोई नहीं जानता था
• लंबे समय तक client-side rendering (CSR) JavaScript applications का प्रभुत्व रहा
• इन applications को single-page applications (SPA) भी कहा जाता है, और ये आम तौर पर छोटे HTML files और बड़े JavaScript files से बने होते थे
• code splitting आने से पहले तक यही स्थिति थी

फ्रंटएंड और बैकएंड का अलगाव

• इस दौरान frontend development पर कई तरह के JavaScript frameworks और libraries का दबदबा था
• backend आम तौर पर किसी एक भाषा से बंधा नहीं था, और API communication के लिए REST मानक बन गया
• एक freelance web developer के रूप में, मैंने मुख्य रूप से .NET, Java, Python, PHP backends के साथ काम किया
• TypeScript/JavaScript backend में मुझे केवल greenfield projects या ऐसे छोटे projects में दिखा जहाँ backend को नियंत्रित किया जा सकता था
• लेकिन full-stack React के उभार से यह बदल सकता है
• यह दिलचस्प है कि 2010 से 2020 के बीच के दौर को लेकर developers की धारणा इस बात पर निर्भर करती है कि उन्होंने अपने career की शुरुआत कब की
• 2010 से पहले शुरुआत करने वाले developers server-side rendering (SSR) माहौल में थे, इसलिए हाल की server-side technologies की वापसी के साथ वे अधिक सहज दिखते हैं
• दूसरी ओर, कई अन्य लोग लगभग 10 साल तक client-side rendering (CSR) applications में केवल REST API के साथ काम करते रहे
• अब वे समझ नहीं पा रहे कि इस नए full-stack React संसार को कैसे अपनाएँ

TypeScript का industry standard बनना

• पिछले कुछ वर्षों में TypeScript industry standard के रूप में उभरा है
• TypeScript frontend developers को typed और शक्तिशाली programming language देता है
• जब developers ने TypeScript को अपनाया, तब वापस लौटना लगभग असंभव हो गया
• यह दिलचस्प है कि code में छोटा बदलाव भी व्यक्ति और पूरे industry पर बड़ा प्रभाव डाल सकता है

TypeScript और REST की कठिनाइयाँ

• TypeScript का REST पर प्रभाव कई तदर्थ समाधानों से भरा हुआ है
• OpenAPI (पहले Swagger) REST API documentation के लिए मौजूद था, लेकिन अब इसका उपयोग मुख्य रूप से typed API interfaces बनाने के लिए होता है
• client-server architecture में perfect type interfaces बनाना संभव होने के बावजूद, कई projects शुरुआत से इसे सही तरह लागू करने में असफल रहते हैं
•  व्यक्तिगत नोट: "हो सकता है कुछ developers को OpenAPI-आधारित architecture में अच्छा अनुभव मिला हो, लेकिन दुर्भाग्य से लेखक का अनुभव ऐसा नहीं रहा"

TypeScript ने माहौल बदल दिया

• यह देखना काफ़ी रोचक है कि TypeScript ने यहाँ माहौल कैसे बदल दिया
• एक तरफ़, REST (documentation के लिए OpenAPI) इस्तेमाल करने वाले untyped SPA "ठीक-ठाक" लगते थे
• लेकिन जब TypeScript standard और norm बन गया, तब generated type interfaces को संभालना अप्रिय लगने लगा, क्योंकि frontend codebases अब ऊँचे मानकों के आदी हो चुके थे
• generated type interfaces की कमियाँ स्पष्ट हैं:
  • इनमें हमेशा generation step शामिल होता है
  • generated output जटिल होता है
  • शुरुआती setup के आधार पर generated code हमेशा सही नहीं होता

RPC और tRPC का उभार

• RPC कोई नया विचार नहीं है, लेकिन tRPC की वजह से यह React ecosystem में लोकप्रिय हुआ
• 80,000 lines code वाले application पर 6 महीनों तक solo developer के रूप में काम करने के अनुभव में, backend पर functions को call करके data पढ़ना और लिखना किसी revelation जैसा लगा
• TypeScript इस्तेमाल करने वाले stack के दोनों तरफ़ मैंने इससे अधिक productive कभी महसूस नहीं किया
• व्यक्तिगत रूप से, कुछ साल पहले केवल (generated) typed GraphQL architecture में ही मुझे ऐसा ही productivity का अनुभव हुआ था
• 2023 के पूरे साल में tRPC से बेहतर कुछ सोचना मुश्किल था
• backend पर functions को call करके data पढ़ना और लिखना क्रांतिकारी लगा
• लेकिन क्या वही सब कुछ था जिसकी मुझे ज़रूरत थी? नहीं

Server Components और Server Actions का नवाचार

• मेरे लिए असली breakthrough 2024 में Server Components और Server Actions से आया
• ये सिर्फ़ server को call नहीं करते, बल्कि दूसरी तरफ़ code implement और execute करने की सुविधा देकर server के साथ की दूरी को भी कम करते हैं
• Server Components, React components को server पर चलाने देते हैं, ताकि JSX में UI return करने से पहले data sources (जैसे database) तक सीधे पहुँचा जा सके
• Server Actions अंदर ही अंदर HTTP API endpoints बनाते हैं, जिससे functions को remote procedure call की तरह execute करके call किया जा सकता है
• Server Components और Server Actions, React को full-stack framework में बदल देते हैं
• frontend को full-stack environment में बदलने का यह बेहद रोमांचक समय है

React में Server Components और Server Actions का समर्थन

• React खुद केवल Server Components और Server Actions के लिए building blocks और specification प्रदान करता है
• React के ऊपर बने meta-frameworks, bundler के रूप में client और server के बीच directives की व्याख्या करके इस अंतर को भर सकते हैं
• Next.js, Server Components और Server Actions के implementation में अग्रणी है
• Next.js पहले भी server-side rendering (SSR) को support करता था, लेकिन अब Server Components और Server Actions के ज़रिए developers database और message queue जैसे server-side resources तक पहुँच सकते हैं

Full-stack development की शुरुआत

• React के साथ full-stack development अभी बस शुरुआत के चरण में है
• जैसे-जैसे developers Server Components और Server Actions के माध्यम से database तक सीधे पहुँचने लगेंगे, simple CRUD applications से आगे की complexity को काबू करने की प्रक्रिया भी आएगी
• गहन शिक्षा के साथ frontend developers जल्द ही layers, design patterns और best practices का उपयोग करके backend architecture implementation में महारत हासिल कर लेंगे
• सच कहें तो कोई भी React component के भीतर ORM function calls नहीं देखना चाहता

paradigm shift से अपेक्षाएँ

• मैं इस paradigm shift को लेकर बहुत उत्साहित हूँ
• React developers एक ऐसे नए युग की तैयारी करेंगे जहाँ वे UI से database तक vertical features को implement करेंगे

[t7vonn]

फुलस्टैक सब कुछ तो कर ही दिया था

[wan2land]

अगर आप app development की तरह दूसरी languages के साथ compatibility भी सोच रहे हैं, तो tRPC मुझे उतना अच्छा विकल्प नहीं लगता। 😅
मेरे हिसाब से GraphQL सबसे बेहतर है।

[click]

nextjs server action में यह समस्या है कि यह ऐसे random API endpoints को public रूप से expose कर देता है जिन पर developer का control नहीं होता, और मुझे लगता है कि यह काफ़ी गंभीर vulnerability है।

[pasg0725]

क्या आप बता सकते हैं कि आपने किस vulnerability का ज़िक्र किया था? सर्च करने पर SSRF vulnerability दिख रही है, लेकिन मुझे ठीक से समझ नहीं आ रहा कि क्या वही है। मैं अभी next js पढ़ रहा हूँ, इसलिए जिज्ञासा में पूछ रहा हूँ।

[savvykang]

शुरुआत में SPA को आगे बढ़ाने वालों का इरादा आखिर क्या था? jquery से DOM manipulate करने वाले दौर की तुलना में यह कहीं बेहतर है, लेकिन backend और frontend की design और development के लिए जिन concepts की ज़रूरत होती है, वे गायब नहीं हुए—बस लगता है उनकी जगह बदल गई है। सिर्फ routing को ही देखें, तो उसे server से client पर ले गए, और फिर server-side rendering के चलन की वजह से उसे दोबारा server पर ले जाने की कोशिश हो रही है.

मुझे इस बात पर भी संदेह है कि 3 साल बाद भी coding academy या courses में SPA शैली का React सिखाया जाएगा या नहीं।

[superwoou]

क्या पेज नेविगेशन की स्मूदनेस ही सबसे बड़ा फ़ायदा नहीं था? (उस समय तो)

[xguru]

मूल लेख का आख़िरी हिस्सा लेखक द्वारा शुरू किए जाने वाले full-stack web development कोर्स The Road to Next के प्रचार के साथ समाप्त होता है ^^;