अपनी वेबसाइट के बैकलिंक्स की n8n या सादे Python में जाँच करें?

जब एक विजुअल फ्लो अपनी जगह कमाता है

कुछ जॉब्स में एक कैनवास अपने क्लटर के लायक होता है। यदि एक गैर-तकनीकी व्यक्ति को हर स्टेप और उसके आखिरी रन को देखना है, तो एक विजुअल फ्लो एक ऐसे रिपो से बेहतर है जिसे वे कभी नहीं खोलेंगे। इसे छोटा रखें।

ज्यादातर बैकलिंक जॉब्स एक फेच, एक चेक और एक राइट हैं। चार नोड्स इसे अच्छी तरह करते हैं। यदि आपकी जॉब एक क्लाइंट के लिए हर महीने अपनी वेबसाइट के बैकलिंक्स की जाँच करना है, तो यह आकार एक कैनवास के लिए फिट बैठता है। तब तक समस्या शुरू होती है जब कोई पेजिंग, रट्राइज और एक diff जोड़ता है, क्योंकि हर एक अपनी शाखा लाता है।

रिडर के लिए कैनवास चुनें, न कि राइटर के लिए।

फ्लो को कौन पढ़ता है

मार्केटिंग और सेल्स लोग आउटपुट के आधार पर फ्लो पढ़ते हैं, और वे आखिरी रन को स्पष्ट रूप से देखना चाहते हैं। एक कैनवास उन्हें यह बिना टिकट के देता है। वे कोड नहीं, आउटपुट पढ़ते हैं। एक स्क्रिप्ट उन्हें एक लॉग फाइल देती है जिसे वे नहीं खोलेंगे।

फ्लो को एक स्पष्ट नाम और एक लाइन विवरण दें, ताकि अगला रिडर इसे खोलने से पहले जान सके कि यह क्या वादा करता है। एक नोड जिसका लेबल अस्पष्ट है, किसी भी गैर-मौजूद फीचर से ज्यादा समय खर्च करता है।

शाखाएं जिन्हें एक नज़र में देखा जा सके

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

जहां कैनवास एक दायित्व बन जाता है

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

यदि आपको फ्लो ठीक करने के लिए JSON एक्सपोर्ट करते पाते हैं, तो जॉब कैनवास से बड़ी हो गई है। लॉजिक को कोड में ले जाएं और कैनवास को नोटिफिकेशन के लिए रखें।

चार लाइनों में n8n सेटअप

एक HTTP Request नोड, मेथड GET, URL https://linkzoid.pro/api.php. क्वेरी पैरामीटर action, q, key जोड़ें। जो भी व्यक्ति अपनी वेबसाइट के बैकलिंक्स इस तरह जांचना चाहता है, वह पांच मिनट में इसे कॉपी कर सकता है।

की को क्रेडेंशियल्स में स्टोर करें, नोड में नहीं। ok पर एक IF नोड जोड़ें, और फॉल्स ब्रांच को एक एरर वर्कफ्लो में भेजें जो आपको पिंग करे।

rows आर््रे को Item Lists या Split Out नोड के साथ स्प्लिट करें, फिर Google Sheets या Postgres में लिखें। एक्जीक्यूशन काउंट पर नज़र रखें, क्योंकि हर आइटम कुछ प्लान्स पर एक स्टेप के रूप में बिल कर सकता है।

यह पूरी जॉब है। यह तब टूटता है जब पेजिंग आती है: n8n में लूप काम करते हैं लेकिन लगभग दस नोड्स से आगे बुरी तरह पढ़ते हैं।

प्रति रन लागत

हमारी ओर से लागत हर तरफ समान है: एक refdomains पेज के लिए 2 क्रेडिट्स। बिल्डर जहां लागत अलग होती है।

एक सेल्फ-होस्टेड n8n चलाने के लिए मुफ्त है। क्लाउड प्लान एक्जीक्यूशन गिनते हैं। क्रोन पर एक सादा स्क्रिप्ट की कोई लागत नहीं होती।

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

डोमेन प्रति एक्जीक्यूशन गिनें

चालीस डोमेन पर एक लूप एक प्लान पर चालीस रन है जो एक्जीक्यूशन गिनता है। इसे एक शेड्यूल पर डालने से पहले जांचें कि आपका प्लान एक लूप को कैसे गिनता है, क्योंकि बिल गिनती को फॉलो करता है, न कि क्रेडिट्स को।

शेड्यूल के बगल में अपेक्षित गिनती लिखें। बिल पर एक हैरानी उस अनुमान की व्याख्या करना आसान है जो पहले से फाइल में था।

सेल्फ-होस्टिंग की अपनी बिल है

एक सेल्फ-होस्टेड n8n की लागत सर्वर, अपग्रेड्स और बैकअप की है। डेटाबेस आपका है जिसे आप जिंदा रखें। एक छोटी मशीन पर एक सादा स्क्रिप्ट कम मूविंग पार्ट्स रखता है, जो इसे एक फिक्स्ड मंथली जॉब के लिए चुनने का एक कारण है।

आमतौर पर सबसे पहले क्या टूटता है

n8n में यह पेजिंग और आइटम काउंट्स हैं। Python में वह चीज जिसे किसी ने टेस्ट नहीं किया: एक खाली rows, एक टाइमआउट, एक फील्ड जिसका नाम आपके अनुमान से अलग है।

कोई भी टूल गलत नहीं है। छह महीने बाद चीज को मेंटेन करने वाले के आधार पर चुनें। यदि वह आप अकेले हैं, तो कोड ग्रेप करने में आसान है। यदि वह एक मार्केटिंग टीम है जो पहले से कैनवास में रहती है, तो एक छोटा फ्लो जिसे वे देख सकते हैं, एक ऐसे रिपो से बेहतर है जिससे वे डरते हैं।

मिक्स्ड सेटअप भी काम करते हैं। Python को शेड्यूल पर CSV लिखने दें और n8n को फाइल पढ़ने और Slack में पोस्ट करने दें। हर टूल उस हिस्से को करता है जिसे वह सबसे अच्छा हैंडल करता है, और न तो फ्लो दस स्टेप्स से बड़ा होता है।

Python वर्जन को पठनीय रखना

कोड के लिए आम केस यह है कि छह महीने बाद किसी और को इसे बदलना है। इसे आसान बनाएं। एक छोटी स्क्रिप्ट जिसके स्पष्ट नाम हों और एक सेव्ड रिस्पॉन्स, एक स्मार्ट वन-लाइनर से बेहतर है जिसको कोई छूने की हिम्मत नहीं करता।

सेव्ड रिस्पॉन्स पर पार्सर टेस्ट करें

एक असली रिस्पॉन्स को एक फाइल में सेव करें और एक यूनिट टेस्ट को उसकी ओर पॉइंट करें। पार्सर अब बिना क्रेडिट खर्च किए चलता है, और एक रीनेम किया गया फील्ड टेस्ट रन में फेल हो जाता है, न कि सोमवार सुबह।

सेव्ड रिस्पॉन्स को छोटा रखें, क्योंकि एक दर्जन रोज़ काफी हैं। उस तारीख को नोट करें जब आपने इसे लिया था, ताकि आप जान सकें कि फील्ड नाम आखिरी बार कब बदले थे।

सेटिंग्स को एक जगह रखें

डोमेन, एक्शन्स और पेज साइज एक छोटे कॉन्फिग ब्लॉक में होने चाहिए, स्क्रिप्ट में फैले नहीं। एक सहकर्मी तब टार्गेट लिस्ट बदल सकता है बिना लॉजिक को छुए जो रोज़ को पार्स करता है।

सीक्रेट्स को उस ब्लॉक से भी बाहर रखें। उन्हें एनवायरनमेंट से लोड करें, उसी तरीके से जैसे की लोड होती है।

कमिट करने से पहले दो हफ्ते का ट्रायल चलाएं

इसे कागज पर तय न करें। हर टूल में जॉब का सबसे छोटा वर्शन बनाएं, दो हफ्ते तक हर दिन इसे चलाएं, और देखें कि कौन सा टूल आप बिना पूछे खोलते हैं।

देखें कि क्या टूटता है। उन बारों की गिनती करें जब आपको कुछ हैंड-एडिट करना पड़ा, और उन बारों जब आउटपुट गलत था बिना किसी एरर के। वह टूल जिसे कम हैंड फिक्स की जरूरत होती है, वही रखें।

हर मैन्युअल फिक्स को लॉग करें

हर बार जब आपने फ्लो या स्क्रिप्ट को हैंड से टच किया, उसकी एक सादी नोट रखें। दो हफ्तों के बाद एक छोटी लिस्ट किसी भी फीचर टेबल से ज्यादा बताएगी।

नोट करें कि किसने बदलाव मांगे

यदि रिक्वेस्ट उन लोगों से आई जो कोड नहीं पढ़ सकते, तो कैनवास जीत सकता है। यदि वे आपसे आए, तो रिपो रहने में आसान है।

कोई भी जवाब ठीक है जब तक कि आप उसे दिखा सकें। फ्लो या रिपो के बगल में कारण लिखें, और जब जॉब बड़ी हो तो उसे फिर से देखें।