Next.js में एक वेब बैकलिंक चेकर, कुंजी सर्वर पर रखी गई
CORS खुला है, इसलिए एक ब्राउज़र API को सीधे कॉल कर सकता है। भुगतान वाली कुंजी के साथ ऐसा करना एक गलती है। यह पेज उस पतले सर्वर लेयर को दिखाता है जो इसे ठीक करता है।
मिथक बनाम वास्तविकता
| मिथक | वास्तविकता |
|---|---|
| "खुला CORS मतलब कि मैं अपनी कुंजी अपने React बंडल में भेज सकता हूं।" | खुला CORS का मतलब है कि कॉल काम करती है। कोई भी नेटवर्क टैब से कुंजी पढ़ सकता है और आपका बैलेंस खर्च कर सकता है। |
| "लिंक्स की एक तालिका को क्लाइंट पर रेडर होना चाहिए क्योंकि यह एक डैशबोर्ड है।" | सर्वर पर फेच करें और HTML भेजें। आपका यूजर पहले पेनट पर पंक्तियां देखता है और आपकी कुंजी कभी भी बॉक्स से बाहर नहीं जाती। |
| "फ्री एक्शन्स को भी प्रोटेक्शन की जरूरत है।" | domain, overview, stats और suggest को कुंजी की जरूरत नहीं है, इसलिए एक ब्राउज़र उन्हें सीधे कॉल कर सकता है। |
| "मुझे हर पेज व्यू पर रीफेच करना चाहिए।" | इंडेक्स लगभग मासिक रूप से रीबिल्ड होता है। एक 24-घंटे का कैश कुछ भी खोता नहीं है। |
| "प्रॉक्सी को वह सब फॉरवर्ड करना चाहिए जो क्लाइंट भेजता है।" | अपने उपयोग वाले एक्शन्स की अलाउ-लिस्ट बनाएं। एक फॉरवर्डेड action=search 3 क्रेडिट्स खर्च करता है। |
रूट हैंडलर
एप रूटर, फाइल app/api/links/route.ts। एनवायरनमेंट वेरिएबल क्लाइंट बंडल तक नहीं पहुंचता क्योंकि इसके पास NEXT_PUBLIC_ प्रिफिक्स नहीं है।
import { NextRequest, NextResponse } from "next/server";
const ALLOWED = new Set(["refdomains", "anchors", "toppages"]);
export async function GET(req: NextRequest) {
const p = req.nextUrl.searchParams;
const action = p.get("action") ?? "";
const q = (p.get("q") ?? "").toLowerCase();
if (!ALLOWED.has(action) || !/^[a-z0-9.-]+$/.test(q)) {
return NextResponse.json({ ok: false, error: "bad request" }, { status: 400 });
}
const url = `https://seomasters.dev/api.php?action=${action}&q=${q}&per=100`;
const upstream = await fetch(url, {
headers: { Authorization: `Bearer ${process.env.SEO_API_KEY}` },
next: { revalidate: 86400 },
});
if (upstream.status === 402) {
return NextResponse.json({ ok: false, error: "data temporarily unavailable" }, { status: 503 });
}
return new NextResponse(upstream.body, { status: upstream.status, headers: { "content-type": "application/json" } });
}हैंडलर इस तरह क्यों दिखता है
एक्शन्स की अलाउ-लिस्ट
आपके UI में एक बग आपको एक्सीडेंटली 3-क्रेडिट के search कॉल को ट्रिगर करने की अनुमति नहीं देना चाहिए।
q पर रेगुलर एक्सप्रेशन
केवल एक बेयर होस्टनाम ही पास होता है। कोई स्कीम, कोई पाथ, कोई क्वेरी स्ट्रिंग अपस्ट्रीम स्मगल्ड नहीं होती।
revalidate: 86400
प्रति डोमेन प्रति दिन एक अपस्ट्रीम कॉल। मासिक डेटा के साथ, लंबा समय भी ठीक है।
402 को 503 में मैप करना
आपके विजिटर्स को यह नहीं जानने की जरूरत है कि आपका बैलेंस खाली है। आपको पता होना चाहिए, इसलिए इसे लॉग करें।
रेडरिंग: एक क्रॉलर और एक ग्राहक दोनों जो देखते हैं
यदि यह डैशबोर्ड लॉगिन के पीछे है, तो सर्वर या क्लाइंट रेडरिंग एक UX चॉइस है। यदि इसका कोई हिस्सा पब्लिक है, जैसे एक फ्री लुकअप पेज जिसे आप इंडेक्स करना चाहते हैं, तो पहली तालिका को सर्वर पर रेडर करें।
एक पेज जो एक खाली शेल के रूप में आता है और हाइड्रेशन के बाद भर जाता है, इंडेक्सिंग और स्लो फोन दोनों के लिए जोखिम है। Google जावास्क्रिप्ट चला सकता है, लेकिन वह उस स्टेप को क्यू में डालता है और हमेशा जल्दी उस तक नहीं पहुंच पाता।
फ्री ओवरव्यू को सर्वर पर रखें
सस्ते, फ्री overview कॉल को एक सर्वर कंपोनेंट में डालें और विजिटर से भुगतान वाले, गहरे ड्रॉल्स के लिए एक बटन ट्रिगर करें करें। वह स्प्लिट भी आपके क्रेडिट स्पेंड को प्रेडिक्टेबल रखता है।
फ्री कॉल्स की कोई लागत नहीं होती, इसलिए एक सर्वर-रेडरड ओवरव्यू कोई क्रेडिट स्पेंड नहीं जोड़ता। केवल भुगतान वाले ड्रॉल्स को एक बटन और एक सेशन की जरूरत होती है।
खाली स्टेट के बारे में पहले सोचें। एक विजिटर जो एक खाली तालिका पर आता है, वह मान लेगा कि टूल खराब है, और एक फास्ट सेकंड पेनट उस फर्स्ट इंप्रेशन को नहीं मिटाता।
पहली स्क्रीन के लिए फ्री एक्शन्स चुनें और ड्रिल-डाउन के लिए भुगतान वाले एक्शन्स। एक विजिटर जो एक पेज खोलता है और एक फ्री सारांश देखता है, उसके पास एक्सीडेंटली एक भुगतान वाले बटन को दबाने का कोई कारण नहीं है।
संख्या के साथ-साथ व्याख्या को भी लिंक करें
संख्याओं को वायर करना आसान हिस्सा है। उन्हें समझाना मुश्किल है, इसलिए टूलटिप से DR फॉर्मूला लिंक करें और बताएं कि इंडेक्स मासिक रूप से रिफ्रेश होता है।
एक विजिटर जो बिना फॉर्मूला के एक स्कोर देखता है, उसे अनुमान लगाएगा, इसलिए लिंक स्क्रीन पर संख्या के बगल में होना चाहिए।
एक डैशबोर्ड के सर्वर और क्लाइंट पार्ट्स
ज्यादातर डैशबोर्ड्स को दोनों तरह के कोड की जरूरत होती है। ओनरशिप स्प्लिट तय करती है। कुंजी, डेटा और एक्सेस नियमों का एक ही घर होता है। एक पब्लिक वेब बैकलिंक चेकर पेज को लॉगिन के पीछे वाले पेज की तरह ही स्प्लिट की जरूरत होती है।
सर्वर पर फेच करें, क्लाइंट पर सॉर्ट करें
जब लोग सॉर्ट, फिल्टर और पेजिंग करते हैं, तो एक बैकलिंक टेबल एक उचित क्लाइंट कंपोनेंट है। पंक्तियां एक सर्वर कंपोनेंट से आनी चाहिए जिसने पहले ही आपके रूट को कॉल किया हो, ताकि ब्राउज़र कभी भी कुंजी या अपस्ट्रीम URL न रखे।
दस पंक्तियों को सॉर्ट करना क्लाइंट पर तुरंत होता है। हर बार एक फ्रेश रिक्वेस्ट पर पांच हज़ार पंक्तियों को सॉर्ट करना धीमा है, इसलिए पूरा सेट उसी कंपोनेंट में रखें जिसे आपने पहले ही लोड किया है।
सरल रखें। एक तालिका जो तुरंत सॉर्ट होती है, उससे बेहतर है जो हर क्लिक पर री-फेच करती है।
क्लाइंट बाउंड्री को कम रखें
बाउंड्री को पेड़ में जितना नीचे हो सके धकेलें। एक डायनामिकली इम्पोर्टेड, क्लाइंट-ओनली विजेट ब्राउज़र में रेडर होता है, जबकि कंपोनेंट जिसने पंक्तियां फेच कीं, सर्वर पर रहता है। पंक्तियों को प्रॉप्स के रूप में पास करें, और फेच को बाउंड्री के ऊपर रखें।
यदि आप फेच को बाउंड्री के नीचे ले जाते हैं, तो ब्राउज़र खुद कॉल करता है। वही गलती है जिसके बारे में कुंजी लीक सेक्शन में चेतावनी दी गई है, इसलिए इस बाउंड्री में हर बदलाव के बाद नेटवर्क टैब जांचें।
लाइन सटीक कहाँ गिरती है? पहले कागज पर खींचें, फेच के लिए एक बॉक्स और हर इंटरैक्टिव कंट्रोल के लिए एक बॉक्स के साथ, और उन तीरों की गिनती करें जो उसे पार करते हैं।
शेल और सेशन चेक सर्वर पर रहते हैं
लेआउट और सेशन चेक तय करते हैं कि एक विजिटर को क्या दिख सकता है, इसलिए वे सर्वर पर होने चाहिए। इंटरैक्टिव टेबल्स, फॉर्म्स और चार्ट्स बाद में हाइड्रेट हो सकते हैं बिना उस फैसले को बदले।
एक क्लाइंट-साइड गार्ड एक बटन छुपा सकता है, लेकिन एक रिक्वेस्ट को नहीं रोक सकता। एक्सेस वास्तव में रूट हैंडलर और सर्वर लेआउट में एनफोर्स होता है।
फिर कुकी के बिना वही रिक्वेस्ट भेजें और पुष्टि करें कि सर्वर इसे रिफ्यूज करता है, केवल पेज नहीं।
वही नियम प्रॉक्सी को भी कवर करता है। एक सेशन चेक जो केवल ब्राउज़र में होता है, रूट को प्रोटेक्ट नहीं कर सकता, इसलिए रूट क्रेडिट खर्च करने से पहले सेशन की जांच करता है।
प्रति विजिटर नहीं, प्रति डोमेन कैश करें
रूट अपस्ट्रीम URL डोमेन से बनाता है, इसलिए कैश की कुंजी भी डोमेन की ही होती है। एक विजिटर जो एक साइट की खोज करता है, अगले विजिटर के लिए पेज को वार्म करता है जो उसी साइट के बारे में पूछता है।
हैंडलर में दैनिक रिवैलिडेट का ही मकसद है। एक ही डोमेन पर दो विजिटर्स की एक अपस्ट्रीम कॉस्ट होती है, और एक हज़ार डोमेन पर एक हज़ार विजिटर्स की एक हज़ार कॉल्स होती हैं, इसलिए कैश ही बजट है।
विपरीत मामले के लिए भी सावधान रहें। एक पेज जो टाइमस्टैम्प से अपनी क्वेरी स्ट्रिंग बदलता है, कैश को पूरी तरह हरा देता है, और बिल लॉग्स से पहले ही दिखाई देता है।
इंडेक्स से मेल खाने वाले शेड्यूल पर रिवैलिडेट करें। एक दैनिक विंडो मासिक डेटा के लिए उपयुक्त है, और एक छोटी विंडो केवल कॉल्स जोड़ती है बिना नए तथ्य जोड़े।
हार्डनिंग, उस क्रम में जिसे हम करेंगे
हैंडलर आसान हिस्सा है। हार्डनिंग वह जगह है जहां कुंजी लीक होती है या बैलेंस ड्रेन होता है, इसलिए इन क्रम में काम करें।
अपने नेटवर्क टैब को स्कैन करें
अपने डैशबोर्ड पर Chrome DevTools खोलें और नेटवर्क टैब पढ़ें। ध्यान से देखें। यदि वहां कोई रिक्वेस्ट sk_live_ दिखाता है, तो आज ही कुंजी बदल दें। वह चेक एक मिनट का है और सबसे आम लीक पाता है।
रिस्पॉन्स बॉडीज को भी खोजें, रिक्वेस्ट हेडर्स के साथ। एक एरर मेसेज में इको हुई कुंजी भी एक लीक है।
प्रति यूजर कॉल्स को कैप करें
अगला, प्रति-यूजर लिमिट जोड़ें। इसे रूट के सामने रखें। ऊपर वाला हैंडलर किसी भी व्यक्ति के लिए आपका क्रेडिट खर्च करता है जिस तक वह पहुंच सकता है, इसलिए इसे एक सेशन से बांधें और प्रति घंटे कॉल्स को कैप करें। क्रेडिट पेज पर बजट मैथ से कैप चुनें।
शुरुआत में उदार रहें और बाद में सख्त करें। एक कैप जो पहले दिन ही असली यूजर्स को ब्लॉक कर देता है, उन्हें एक अन्य टूल ढूंढने को कहता है।
टॉप-अप करने वाले का नाम बताएं
रनबुक में एक लाइन लिखना भी जरूरी है: जब बैलेंस एक तय स्तर से नीचे जाता है तो किसको पेज किया जाए, और कौन टॉप-अप करता है। व्यक्ति का नाम लिखें।
टॉप-अप स्टेप को एक चेकलिस्ट के रूप में लिखें जिसमें अकाउंट पेज लिंक और अपेक्षित टर्नअर टाइम हो। एक रनबुक जो केवल एक व्यक्ति के दिमाग में मौजूद है, उस व्यक्ति की छुट्टी पर जाने पर पहली बार फेल हो जाता है। स्टेप में ही मिनट लगते हैं, इसलिए लिखना ही बड़ा काम है।
बैलेंस खत्म होने से पहले लॉग करें
फिर हर अपस्ट्रीम रिस्पॉन्स से _credits को अपने मेट्रिक्स में लॉग करें। शेष बैलेंस का एक ग्राफ, दैनिक सैंपल के साथ, आपको HTTP 402 से एक सप्ताह पहले चेतावनी देता है।
अलर्ट लेवल अपनी साप्ताहिक उपयोग से चुनें। एक टेम्पलेट से चुना गया नंबर दुर्लभ ही आपके असली कॉल्स से मेल खाता है।
आखिरी वैल्यू जिसे आपने देखा है, उसे मेमोरी में और लॉग दोनों में रखें, ताकि रूट नंबर अलर्ट लेवल से नीचे गिरने पर भुगतान वाले ड्रॉल्स को रिफ्यूज कर सके। वह चेक एक लाइन का है, और यह ट्रैफिक के बर्स्ट को बाकी खर्च करने से रोकता है।
अलाउ-लिस्ट को एक जगह रखें
एक और आदत फायदा देती है। अलाउ-लिस्ट को एक शेयर्ड कॉन्स्टेंट में रखें, जो हैंडलर और टेस्ट्स दोनों द्वारा इम्पोर्ट होती है, ताकि एक नया एक्शन बिना किसी द्वारा दृश्यमान लिस्ट एडिट किए और एक रिव्यूअर के नोटिस के प्रोडक्शन तक न पहुंचे।
एक फाइल, एक इम्पोर्ट। किसी को यह जानने के लिए तीन कंपोनेंट्स में लिस्ट ढूंढने की जरूरत नहीं होनी चाहिए कि प्रॉक्सी क्या स्वीकार करेगा।
उस रनटाइम को टेस्ट करें जिसमें आप डिप्लॉय करते हैं
आखिर में, अपने पसंद के एज रनटाइम या Node 20 के तहत हैंडलर चलाएं और दोनों को टेस्ट करें। अपस्ट्रीम बॉडी को स्ट्रीमिंग करना, जैसा कि कोड करता है, दोनों में काम करता है, लेकिन हेडर हैंडलिंग अलग होती है और टेस्ट के लायक है।
एक टेस्ट जो बुरे एक्शन के साथ रूट को कॉल करता है और एक वैध एक्शन के साथ, जो स्टेटस कोड्स पर एसेर्ट करता है, जोड़ें। वे दो टेस्ट अलाउ-लिस्ट और हेडर हैंडलिंग में ज्यादातर रिग्रेशन पकड़ते हैं।
क्रम में प्रॉक्सी वायर करना
- 1
सर्वर पर कुंजी जोड़ें
कुंजी को एक पब्लिक प्रिफिक्स के बिना अपने सर्वर एनवायरनमेंट में स्टोर करें, फिर उसे लोड करने के लिए डेव सर्वर रीस्टार्ट करें।
- 2
पहले अलाउ-लिस्ट लिखें
उन एक्शन्स की लिस्ट बनाएं जो आपकी स्क्रीन वास्तव में कॉल करती हैं। बाकी सब कुछ आपके अपने रूट से 400 प्राप्त करता है, अपस्ट्रीम API तक पहुंचने से पहले।
- 3
अपने रूट को एक सर्वर कंपोनेंट से फेच करें
जहां डेटा आता है, वहां पंक्तियां रेडर करें। ब्राउज़र केवल अपने डोमेन को ही कॉल करता है, इसलिए अपस्ट्रीम एड्रेस पेज से बाहर रहता है।
- 4
बैलेंस की निगरानी करें
हर अपस्ट्रीम रिस्पॉन्स पर
_creditsलॉग करें और एक अलर्ट लेवल सेट करें जिस पर आप एक्शन ले सकें, एक 402 को एक विजिटर तक 503 के रूप में पहुंचने से पहले।
