रिएक्ट सर्वर कंपोनेंट्स के साथ रियल-टाइम व्यू काउंटर बनाएं

इस ट्यूटोरियल में, हम रिएक्ट सर्वर कंपोनेंट्स को समझेंगे और उस ज्ञान के साथ, मिलकर आपके ऐप के लिए एक सरल व्यू काउंटर बनाएंगे। यदि आप इम्प्लीमेंटेशन के साथ आगे बढ़ना चाहते हैं तो प्रोजेक्ट सेटअप पर जाने के लिए स्वतंत्र महसूस करें।

रिएक्ट सर्वर कंपोनेंट्स को समझना

यह समझने के लिए कि रिएक्ट सर्वर कंपोनेंट्स कैसे काम करते हैं, हम संक्षेप में क्लाइंट-साइड रेंडरिंग (CSR) और सर्वर-साइड रेंडरिंग (SSR) को देखेंगे।

क्लाइंट-साइड रेंडरिंग (CSR)

CSR में, अधिकांश रेंडरिंग कार्य ब्राउज़र में क्लाइंट-साइड पर होता है:

1. उपयोगकर्ता एक साइट का अनुरोध करता है।
2. सर्वर एक HTML फ़ाइल और CSS और JS फ़ाइलों के लिंक भेजता है।
3. क्लाइंट JS संसाधन डाउनलोड करता है।
4. क्लाइंट बिना कंटेंट के पेज रेंडर करता है।
5. क्लाइंट सर्वर में API से डेटा प्राप्त करता है।
6. क्लाइंट कंटेंट के साथ पेज को पुनः रेंडर करता है।

सर्वर-साइड रेंडरिंग (SSR)

SSR में, सर्वर प्रत्येक अनुरोध के लिए पूर्ण HTML कंटेंट जनरेट करता है और इसे क्लाइंट को भेजता है:

1. उपयोगकर्ता एक साइट का अनुरोध करता है।
2. सर्वर वास्तविक HTML फ़ाइलें रेंडर करता है लेकिन वे अभी तक इंटरैक्टिव नहीं हैं।
3. क्लाइंट JS संसाधन डाउनलोड करता है।
4. क्लाइंट में, hydrateRoot() फंक्शन का उपयोग करके, रिएक्ट कंपोनेंट्स के इवेंट लिसनर्स, स्टेट, और अन्य इंटरैक्टिविटी को सर्वर द्वारा जनरेट किए गए मौजूदा DOM एलिमेंट्स से जोड़ा जाता है, जिसे हाइड्रेशन के रूप में जाना जाता है।
5. क्लाइंट सर्वर में API से डेटा प्राप्त करता है।
6. क्लाइंट कंटेंट के साथ पेज को पुनः रेंडर करता है।

SSR के फायदे

• बेहतर SEO: क्योंकि सर्च इंजन क्रॉलर्स पूरी तरह से रेंडर किए गए HTML को पढ़ सकते हैं, SSR अधिक SEO-फ्रेंडली है।
• तेज़ प्रारंभिक लोड: चूंकि सर्वर से पूर्ण HTML कंटेंट रेंडर करके भेजा जाता है, उपयोगकर्ता पेज के कंटेंट को जल्दी देखते हैं।

SSR के नुकसान

• धीमी नेविगेशन: प्रत्येक नए पेज अनुरोध के लिए सर्वर से HTML के पूर्ण रीलोड के लिए राउंड-ट्रिप कम्युनिकेशन की आवश्यकता होती है।
• बढ़ा हुआ सर्वर लोड: चूंकि सर्वर पेज रेंडर करने में अधिकांश काम करता है, इसे कई अनुरोधों को संभालने के लिए अधिक संसाधनों की आवश्यकता हो सकती है।

रिएक्ट सर्वर कंपोनेंट्स

RSC रिएक्ट में एक फीचर है जो कंपोनेंट्स को पूरी तरह से सर्वर पर रेंडर करने की अनुमति देता है:

1. सर्वर डेटा प्राप्त करता है।
2. सर्वर कंटेंट के साथ ऐप रेंडर करता है।
3. क्लाइंट JS संसाधन डाउनलोड करता है।
4. क्लाइंट में हाइड्रेशन होता है।

नोट: सर्वर कंपोनेंट्स पूरी तरह से सर्वर पर रेंडर होते हैं, वे JS बंडल में शामिल नहीं होते हैं और वे हाइड्रेटेड नहीं होते हैं। इसलिए चरण 3 और 4 क्लाइंट कंपोनेंट्स के लिए होते हैं।

RSC के फायदे

• कुशल डेटा हैंडलिंग: डेटा फेचिंग सर्वर पर चली जाती है, आपके डेटाबेस के करीब। यह क्लाइंट-सर्वर राउंड ट्रिप को हटाकर परफॉरमेंस में सुधार करता है।
• क्लाइंट पर कम JavaScript साइज़: चूंकि रिएक्ट सर्वर कंपोनेंट्स क्लाइंट को कोई JavaScript नहीं भेजते, समग्र बंडल साइज़ कम हो जाता है, जिससे परफॉरमेंस में सुधार होता है।
• तेज़ प्रारंभिक पेज लोड: सर्वर पर कंपोनेंट्स को प्री-रेंडर करने का अर्थ है कि क्लाइंट को पूरी तरह से रेंडर किया गया HTML तेज़ी से प्राप्त होता है, जिससे फर्स्ट कंटेंटफुल पेंट (FCP) तक का समय सुधरता है।
• बेहतर SEO: कंटेंट पूरी तरह से सर्वर-साइड रेंडर होता है, जिससे सर्च इंजन के लिए कंटेंट को क्रॉल और इंडेक्स करना आसान हो जाता है।

RSC की चुनौतियाँ

• स्टेट और लाइफसाइकिल: रिएक्ट सर्वर कंपोनेंट्स के पास ब्राउज़र APIs (जैसे useState, useEffect) तक पहुंच नहीं होती, क्योंकि वे सर्वर पर रेंडर होते हैं।
• कोई क्लाइंट-साइड इंटरैक्टिविटी नहीं: रिएक्ट सर्वर कंपोनेंट्स डायनामिक अपडेट या इंटरैक्टिविटी के लिए नहीं बने हैं। आपको अपने ऐप के इंटरैक्टिव हिस्सों के लिए क्लाइंट कंपोनेंट्स का उपयोग करने की आवश्यकता है।

रिएक्ट सर्वर कंपोनेंट्स का उपयोग करना

Next.js में रिएक्ट सर्वर कंपोनेंट्स

डिफ़ॉल्ट रूप से, Next.js सर्वर कंपोनेंट्स का उपयोग करता है। वे 3 अलग-अलग तरीकों से रेंडर होते हैं:

• स्टेटिक रेंडरिंग (डिफ़ॉल्ट): रूट्स बिल्ड टाइम पर रेंडर होते हैं, या डेटा रीवैलिडेशन के बाद बैकग्राउंड में।
• डायनामिक रेंडरिंग: रूट्स प्रत्येक यूजर के लिए रिक्वेस्ट टाइम पर रेंडर होते हैं।
• स्ट्रीमिंग: UI सर्वर से प्रगतिशील रूप से रेंडर होता है।

आपको रिएक्ट सर्वर कंपोनेंट्स कब उपयोग करना चाहिए?

आपको रिएक्ट सर्वर कंपोनेंट्स का उपयोग करना चाहिए जब:

• आपके पास स्टेटिक, नॉन-इंटरैक्टिव कंटेंट है जो बार-बार नहीं बदलता।
• आप क्लाइंट को भेजे जाने वाले JavaScript को कम करके परफॉरमेंस में सुधार चाहते हैं।
• SEO आपके एप्लिकेशन के लिए महत्वपूर्ण है।
• आप भारी डेटा-फेचिंग या कम्प्यूटेशनल कार्यों को सर्वर पर ऑफलोड करना चाहते हैं।

आपको रिएक्ट सर्वर कंपोनेंट्स का उपयोग नहीं करना चाहिए जब:

• आपके कंपोनेंट्स को क्लाइंट-साइड इंटरैक्टिविटी, स्टेट, या हुक्स की आवश्यकता होती है।
• आपको ब्राउज़र APIs तक पहुंच या रियल-टाइम अपडेट की आवश्यकता है।
• आप भारी क्लाइंट-साइड लॉजिक या यूजर-विशिष्ट कंटेंट के साथ जटिल पेज बना रहे हैं।

सामान्य नुकसान

क्लाइंट कंपोनेंट्स पूरी तरह से क्लाइंट पर रेंडर नहीं होते

वे क्लाइंट और सर्वर दोनों पर रेंडर होते हैं। उन्हें सर्वर कंपोनेंट्स से अलग करने के लिए क्लाइंट कंपोनेंट्स नाम दिया गया है।

'use server' डायरेक्टिव सर्वर एक्शन्स के लिए है

डिफ़ॉल्ट रूप से, Next.js सर्वर कंपोनेंट्स का उपयोग करता है इसलिए आपको कुछ भी निर्दिष्ट करने की आवश्यकता नहीं है। यदि आप क्लाइंट कंपोनेंट्स का उपयोग करना चाहते हैं, तो आप सर्वर और क्लाइंट मॉड्यूल्स के बीच बाउंड्री घोषित करने के लिए 'use client' डायरेक्टिव जोड़ते हैं। 'use server' एक पूरी तरह से अलग डायरेक्टिव है जिसका उपयोग सर्वर एक्शन्स के लिए किया जाता है, जो इस ब्लॉगपोस्ट के दायरे से बाहर है।

प्रोजेक्ट सेटअप

हम Vercel से ब्लॉग टेम्पलेट का उपयोग करेंगे:

pnpm create next-app --example https://github.com/vercel/examples/tree/main/solutions/blog blog

आप उदाहरण को स्थानीय रूप से चला सकते हैं और देख सकते हैं कि यह कैसा दिखता है:

cd blog 
pnpm dev

आइए @upstash/redis इंस्टॉल करें:

pnpm add @upstash/redis

एनवायरनमेंट सेटअप

1. अपस्टैश कंसोल → रेडिस पर जाएं और एक नया डेटाबेस बनाएं:

2. REST API सेक्शन तक नीचे स्क्रॉल करें, .env टैब पर स्विच करें और अगले चरण के लिए एनवायरनमेंट वेरिएबल्स कॉपी करें:

3. एक .env फ़ाइल बनाएं और अपने एनवायरनमेंट वेरिएबल्स पेस्ट करें:

UPSTASH_REDIS_REST_URL= 
UPSTASH_REDIS_REST_TOKEN=

व्यूज़ कंपोनेंट सेटअप करें

/app/components/views.tsx बनाएं:

import { headers } from 'next/headers' 
import { Redis } from "@upstash/redis" 
const redis = Redis.fromEnv(); 
async function view(slug: string, ip: string) { 
  // IP एड्रेस को हैश करके अनाम करें 
  const buf = await crypto.subtle.digest("SHA-256", new TextEncoder().encode(ip)); 
  const hash = Array.from(new Uint8Array(buf)).map((b) => b.toString(16).padStart(2, "0")).join(""); 
  // व्यूज़ को डिडुप्लिकेट करें 
  const newView = await redis.set(`deduplicate:${hash}:${slug}`, true, { 
    nx: true, // केवल तभी की सेट करें अगर यह मौजूद नहीं है 
    ex: 24 * 60 * 60, // 24 घंटे के बाद की एक्सपायर करें 
  }); 
  if (newView) { 
    await redis.incr(`pageviews:${slug}`); // व्यू काउंट बढ़ाएं 
  } 
} 
export default async function Views({ slug }: { slug: string }) { 
  // यूजर का IP एड्रेस प्राप्त करें 
  const header = headers() 
  const ip = (header.get('x-forwarded-for') ?? '127.0.0.1').split(',')[0] 
  // व्यू काउंट बढ़ाएं 
  await view(slug, ip) 
  // व्यू काउंट प्राप्त करें 
  const views = await redis.get(`pageviews:${slug}`) || 0 
  return ( 
    
 
      {views} views 
    
 
  ) 
} 

व्यूज़ कंपोनेंट इम्पोर्ट और डिस्प्ले करें

/app/blog/[slug]/page.tsx एडिट करें:

... 
import Views from 'app/components/views' 
... 
 
  
 
    {formatDate(post.metadata.publishedAt)} 
  
 
   
 
...

https://localhost:3000/blog/vim पर जाकर व्यू काउंटर को एक्शन में देखें:

क्लाइंट कंपोनेंट्स सेटअप के साथ तुलना

हमारे ब्लॉगपोस्ट "Adding a View Counter to your Next.js Blog" को देखें ताकि क्लाइंट कंपोनेंट्स के साथ इम्प्लीमेंटेशन देख सकें।

पिछले सेक्शन्स में उल्लिखित अन्य लाभों के साथ, रिएक्ट सर्वर कंपोनेंट्स का उपयोग करके:

• एक अलग API की आवश्यकता को हटा दिया।
• टाइप चेकिंग के लाभों के साथ कंपोनेंट और इसके लॉजिक का एक सरल एकीकृत दृश्य प्रदान किया।

डिप्लॉय करें

आप निम्न कमांड के साथ अपनी साइट को Vercel पर डिप्लॉय कर सकते हैं:

vercel

अंतिम शब्द

सर्वर और क्लाइंट कंपोनेंट्स दोनों की ताकत को मिलाकर, आप अपने एप्लिकेशन में परफॉरमेंस और इंटरैक्टिविटी के बीच सही संतुलन बना सकते हैं। मुझे उम्मीद है कि यह गाइड आपको रिएक्ट सर्वर कंपोनेंट्स का प्रभावी ढंग से लाभ उठाने के बारे में सूचित निर्णय लेने में मदद करता है।