एक वेबहुक, एक HTTP कॉल, एक निर्णय। यह रनबुक एक हेडलेस CMS टीम को हुक, कॉल्स और फेल्योर केस के माध्यम से मार्गदर्शन करती है।
Contentin रिसर्च टीम ·
तय करें कि गेट क्या कर सकता है
रिलीज फ्लो के भीतर एक पेज बैकलिंक चेक एक छोटा काम है। इसे छोटा रखें। कठिन हिस्सा यह तय करना है कि उत्तर क्या बदल सकता है, क्योंकि एक ऐसा लिंक ग्राफ़ जो मासिक रूप से रिफ्रेश होता है, अकेले किसी पेज को वेटो नहीं कर सकता।
हम सुझाव देते हैं कि गेट चेतावनी दे, लॉग करें और बिल्ड को आगे बढ़ने दें। डिफ़ॉल्ट बदल सकते हैं। हार्ड ब्लॉक उन चीज़ों के लिए होते हैं जिन पर आपका नियंत्रण है, जैसे कि टूटा हुआ मार्कअप या एक गैर-मौजूद कैनोनिकल टैग। लिंक डेटा एक सिग्नल है, और सिग्नल बदलते रहते हैं।
इसे लिख लें। कोड करने से पहले ऐसा करें। "संपादक को चेतावनी दें, एंट्री को टैग करें, डिप्लॉय को कभी न रोकें" जैसी एक लाइन की नीति 6 बजे रिलीज डे पर लंबी बहस बचाती है। यह अगले इंजीनियर को भी बताता है कि कौन से फेल्योर इच्छित थे और कौन से बग थे, जो कि यह सुनने से अधिक महत्वपूर्ण है। इसे प्रति तिमाही एक बार समीक्षित करें।
पब्लिश क्लिक से स्टोर किए गए नोट तक छह कदम
1
ट्रिगर चुनें
अपने CMS के पब्लिश इवेंट के लिए सब्सक्राइब करें। Contentful, Sanity और Strapi किसी एंट्री के पब्लिश होने पर आपके स्वयं के URL को कॉल कर सकते हैं, और Storyblok और Payload में भी वेबहुक या हुक्स उपलब्ध हैं। आउटबाउंड या कैनोनिकल URL वाली कंटेंट टाइप्स के लिए फ़िल्टर करें।
2
URL को डोमेन में बदलें
API q में एक डोमेन लेती है, इसलिए https://www.example.com/blog/post?x=1 को पहले example.com बनना चाहिए। www को कैसे संभालना है, यह एक बार तय करें, और कुछ भी बनाने से पहले फ्री domain एक्शन पर एक असली डोमेन का टेस्ट करें।
3
पहले फ्री एक्शन कॉल करें
overview की कोई लागत नहीं है। यदि यह थिन (thin) लौटता है, तो डोमेन नया हो सकता है या हमारे इंडेक्स में अज्ञात हो सकता है। यह बुरी बात का सबूत नहीं है।
4
क्रेडिट्स तभी खर्च करें जब कोई नियम फायर हो
जब आपका नियम कहता है कि करीब से देखें, तो per=100 के साथ backlinks कॉल करें। यह 2 क्रेडिट्स का है, पंक्तियों की संख्या चाहे कुछ भी हो, इसलिए दस छोटी पंक्तियों के बजाय एक उपयोगी पंक्तियों का सेट मांगें।
5
कच्चा JSON नहीं, एक नोट लिखें
अपने स्वयं के फ़ील्ड में एक छोटा निर्णय और चेक की तारीख स्टोर करें। कच्चे रिस्पॉन्स एंट्रीज़ को भारी बनाते हैं और जल्दी पुराने पड़ जाते हैं, क्योंकि इंडेक्स हर महीने बदलता है।
6
सॉफ्टली फेल करें
HTTP 401 का मतलब है कि कुंजी गायब है या गलत है, इसलिए किसी इंसान को अलर्ट करें। HTTP 402 का मतलब है कि क्रेडिट खत्म हो गया है। कोई अन्य त्रुटि: इसे लॉग करें, चेक छोड़ दें, और पब्लिश को आगे बढ़ने दें।
कुंजी कहाँ रहती है और 402 को क्या करना चाहिए
हर पेड कॉल में आपकी कुंजी होती है, या तो क्वेरी स्ट्रिंग में या Bearer हेडर में। हेडर को प्राथमिकता दें। क्वेरी स्ट्रिंग सर्वर लॉग्स और प्रॉक्सी ट्रेस में जा सकती है, जबकि हेडर आमतौर पर उनमें नहीं रहता।
कुंजी को अपने होस्टिंग प्लेटफ़ॉर्म पर एक सीक्रेट के रूप में स्टोर करें, एंट्री में कभी नहीं। संपादक किसी भी फ़ील्ड को पढ़ सकते हैं जिसे वे खोल सकते हैं, लेकिन एक फंक्शन का एन्वायरनमेंट आमतौर पर केवल उन लोगों के लिए दिखाई देता है जो डिप्लॉयमेंट का प्रबंधन करते हैं।
कुंजी कहाँ रहनी चाहिए?
एक लीक हुई कुंजी आपके खाते पर बैलेंस खर्च कर सकती है, इसलिए इसे पासवर्ड की तरह मानें। इसे रिपॉजिटरी और CMS से बाहर रखें, और यदि कोई लॉग फ़ाइल इसे क्लियर टेक्स्ट में दिखाती है तो इसे रोटेट करें।
अपने लॉग्स को हुक के नाम से टैग करें। इससे खर्च को एक फंक्शन तक आसानी से ट्रैक किया जा सकता है, भले ही कई हुक्स एक ही खाते को शेयर करते हों।
क्या कोई नो-कोड टूल कॉल कर सकता है?
हाँ, जब टूल में एक साधारण HTTP रिक्वेस्ट स्टेप हो। कई ऑटोमेशन बिल्डर एक क्वेरी स्ट्रिंग के साथ GET भेज सकते हैं और JSON वापस पढ़ सकते हैं, इसलिए फ्री overview एक्शन के लिए किसी कोड की आवश्यकता नहीं है।
केवल फ्री एक्शन्स से शुरू करें। एक फ्लो जो हर ड्राफ्ट सेव पर फायर करता है, वह संपादक के ध्यान में आने से पहले ही क्रेडिट्स खर्च कर सकता है, इसलिए जब फ्री कॉलें कुछ समय के लिए शांति से चलती रहें, तभी एक पेड स्टेप जोड़ें।
एक 402 को क्या ट्रिगर करना चाहिए?
एक 402 का मतलब है कि बैलेंस खाली है। इसका मतलब पेज के बारे में कुछ नहीं है। पेड चेक छोड़ दें, इवेंट को लॉग करें और किसी ऐसे व्यक्ति को एक अलर्ट भेजें जो खाते में क्रेडिट जोड़ता है, फिर पब्लिश को आगे बढ़ने दें।
शून्य से काफी ऊपर एक बैलेंस अलार्म सेट करें, ताकि चेतावनी तब आ जाए जब क्रेडिट जोड़ने का समय अभी भी हो। एक रीट्राई लूप यहाँ मदद नहीं करेगा, क्योंकि हर कॉल तब तक उसी तरह फेल होगी जब तक कोई क्रेडिट न जोड़े। लागत तालिका में आंकड़े हैं।
टर्मिनल से दो कॉल्स का टेस्ट करें
इसे एक बार उस डोमेन के खिलाफ चलाएं जिसके बारे में आपको पहले से पता है, ताकि हुक इसे आपके लिए न चलाए। दूसरे रिस्पॉन्स पर _credits फ़ील्ड पढ़ें।
bash
# free, no key
curl -s "https://contentin.app/api.php?action=overview&q=example.com"
# 2 credits, key in a header
curl -s -H "Authorization: Bearer sk_live_..." \
"https://contentin.app/api.php?action=backlinks&q=example.com&per=100"
q पैरामीटर में कौन सा डोमेन जाता है
API q में एक खाली डोमेन लेती है, इसलिए एक पूर्ण URL को पहले कम करना पड़ता है। उस रीडक्शन को एक बार, एक फंक्शन में लिखें। फिर उसे असली URLs पर टेस्ट करें।
रिलेटिव लिंक्स और गैर-मौजूद स्कीम्स वे केस हैं जो आमतौर पर एक हुक को तोड़ देते हैं। एक रीडक्शन जो साफ उदाहरणों पर काम करता है, वह भी 5 बजे संपादक द्वारा पेस्ट किए गए अस्तव्यस्त URLs पर फेल हो सकता है।
क्या www उत्तर बदलता है?
शायद, और यह जानने का ईमानदार तरीका यह पूछना है। अपने ज्ञात एक साइट के दोनों रूपों पर फ्री डोमेन एक्शन चलाएं, फिर दोनों रिस्पॉन्स को साइड-बाय-साइड तुलना करें।
आप जो भी नियम चुनते हैं, उसे एक कोड कमेंट में लिखें ताकि अगला इंजीनियर अनुमान न लगाए। एक कमेंट की कोई लागत नहीं है और बाद में लंबी बहस बचाता है।
रिडायरेक्ट्स और सबडोमेन के बारे में?
वह होस्ट भेजें जिस पर आपके पाठक वास्तव में आते हैं, न कि वह लिंक जिसे संपादक सालों पहले पेस्ट किया था। यदि वह लिंक रिडायरेक्ट करता है, तो अंतिम पता कम करें और बीच के हॉप को अनदेखा करें।
अपने स्वयं के सबडोमेन पर एक ब्लॉग एक निर्णय का मामला है। पहले से तय करें कि इसे अकेले या अपने पैरेंट डोमेन के साथ मिलकर चेक किया जाता है, और उस नियम के बगल में उस चयन को लिखें।
हुक के लिए प्री-रिलीज चेकलिस्ट
हुक केवल पब्लिश पर फायर करता है, हर ड्राफ्ट सेव पर नहीं
कॉल से पहले URL को एक खाली डोमेन में कम कर दिया जाता है
फ्री एक्शन्स पहले चलते हैं और क्रेडिट्स केवल एक फ्लैग पर खर्च होते हैं
एक 401 और एक 402 का अपना अलर्ट और अपना संदेश होता है
एक टाइमआउट सेट किया जाता है, ताकि एक धीमी API कभी एक संपादक को अटक न जाए
स्टोर किया गया नोट एक तारीख लेता है, ताकि कोई इसे लाइव डेटा न समझे
एक ही एंट्री के दो बार पब्लिश होने पर दो बार बिल नहीं होता (देखें माइथ लिस्ट)
किसी ने आपके मासिक वॉल्यूम के लिए लागत तालिका पढ़ी है
क्या लॉग करना है, और एंट्री से बाहर क्या रहना है
हर छोड़े गए चेक के लिए एक लॉग लाइन वह सबसे सस्ता ऑडिट ट्रेल है जिसे आप बना सकते हैं। एंट्री ID, डोमेन जिसे आपने भेजा, स्टेटस कोड और क्या एक पेड स्टेप चला, उसकी रिकॉर्ड रखें। आमतौर पर वही काफी है।
स्टोर किया गया नोट छोटा और तारीख वाला रहता है, जैसा कि ऊपर के चरणों में कहा गया है। पूर्ण रिस्पॉन्स आपके स्वयं के लॉग्स में होने चाहिए, यदि उन्हें कहीं होना भी चाहिए, क्योंकि वे बड़े होते हैं और जल्दी पुराने पड़ जाते हैं।
एक लॉग लाइन में कौन से फ़ील्ड होने चाहिए?
एंट्री ID और पब्लिश वर्जन से शुरू करें। एक दोहराया गया वेबहुक फिर एक ही जोड़े के रूप में दो बार दिखाई देगा, जो कि वही है जिसे आप देखना चाहते हैं।
डोमेन, एक्शन नाम, स्टेटस कोड और कॉल शुरू होने का समय जोड़ें। कुंजी को बाहर रखें, क्योंकि एक लॉग जिसमें वह होता है, सीक्रेट्स के रहने का एक दूसरा स्थान बन जाता है।
एक स्टोर किए गए नोट कितने समय तक रहना चाहिए?
जब तक एंट्री है, जब तक कि एक नया चेक इसे बदल न दे। यह मायने रखता है कि एक पाठक यह बता सके कि नोट कितना पुराना है, क्योंकि महीनों पुराने नोट को लाइव डेटा समझा जा सकता है।
स्कोर फ़ील्ड गाइड उस नोट के लिए हमारे द्वारा सुझाए गए चार फ़ील्ड दिखाता है, जिसमें तारीख भी शामिल है।
लॉन्च से पहले स्टैगिंग पर हुक का टेस्ट करें
इन चार चेकों को किसी के हुक पर भरोसा करने से पहले चलाएं।
1
एक पिछले पब्लिश को रीप्ले करें
एक वेबहुक को उस एंट्री की कॉपी के साथ ट्रिगर करें जिसे आपने पहले ही पब्लिश कर दिया है। स्टोर किए गए नोट की तुलना अपनी उम्मीदों से करें, और पुष्टि करें कि उसी एंट्री पर दो बार बिल नहीं हुआ है।
2
हाल ही में रजिस्टर किए गए डोमेन की कोशिश करें
एक ऐसे भागीदार डोमेन का उपयोग करें जो आपके लिए नया है। एक खाली या थिन उत्तर को अज्ञात के रूप में स्टोर किया जाना चाहिए, विफलता के रूप में नहीं, और नोट में सादे शब्दों में ऐसा कहना चाहिए।
3
उद्देश्यपूर्ण रूप से एक 402 फोर्स करें
एक टेस्ट खाते पर हुक चलाएं जिसका बैलेंस आपने खाली कर दिया है। पुष्टि करें कि स्किप, लॉग लाइन और अलर्ट सभी फायर होते हैं, और पब्लिश बिल्ड तक पहुंचता है।
4
संपादक द्वारा देखे गए संदेश को पढ़ें
टीम के बाहर किसी व्यक्ति से कहें कि वह त्रुटि पाठ को ज़ोर से पढ़े। यदि वे यह नहीं कह सकते कि अगला कदम क्या उठाना है, तो लॉन्च डे से पहले संदेश को फिर से लिखें। पोस्ट-मॉर्टम दिखाता है कि एक अस्पष्ट संदेश ने एक काल्पनिक टीम को क्या खर्च किया।
हुक क्या नहीं देख सकता
हमारा इंडेक्स लगभग एक महीने में एक बार रिफ्रेश होता है। पिछले रिफ्रेश के बाद जोड़ा गया लिंक दिखाई नहीं देगा, और चूं हटाया गया लिंक अभी भी दिखाई दे सकता है। समान-दिन के प्रमाण के लिए, Google Search Console में लिंक्स रिपोर्ट का उपयोग करें।
