अपने सभी एपीआई अनुरोधों के लिए क्रेडेंशियल शेयर करने से परफ़ॉर्मेंस बेहतर होती है. साथ ही, इससे ज़्यादा ओवरहेड का इस्तेमाल नहीं किया जा सकता. साथ ही, इससे दर की सीमा से जुड़ी गड़बड़ियां भी हो सकती हैं. इस गाइड में बताया गया है कि OAuth2 क्रेडेंशियल मैनेजमेंट को कैसे ऑप्टिमाइज़ किया जाए, ताकि आपका ऐप्लिकेशन Google Ads API के साथ बेहतर तरीके से इंटरैक्ट कर सके.
आपकी क्रेडेंशियल शेयर करने की रणनीति इस बात पर निर्भर करेगी कि आपका ऐप्लिकेशन मल्टीथ्रेड है या मल्टीप्रोसेस (या डिस्ट्रिब्यूट किया गया) है. ऐसे ऐप्लिकेशन में दोनों रणनीतियां होनी चाहिए जिनमें मल्टीप्रोसेस और मल्टीथ्रेड, दोनों होते हैं. ये रणनीतियां कई Google Ads खातों के लिए भी अपनाई जा सकती हैं.
मल्टीथ्रेड
थ्रेड से बनाए गए हर सेशन या उपयोगकर्ता को एक ही क्रेडेंशियल ऑब्जेक्ट का इस्तेमाल करना चाहिए. रेस की शर्तों से बचने के लिए, ऐक्सेस टोकन को रीफ़्रेश भी करना ज़रूरी है.
हमारी क्लाइंट लाइब्रेरी यह पक्का करती हैं कि क्रेडेंशियल, थ्रेड-सुरक्षित ऑब्जेक्ट है. यह ऐक्सेस टोकन की समयसीमा खत्म होने पर, खुद को सिंक्रोनस रूप से रीफ़्रेश करता है. हमारी हर क्लाइंट लाइब्रेरी में
एक सेशन (या उपयोगकर्ता) ऑब्जेक्ट होता है, जिसमें क्रेडेंशियल होता है. इसे पूरे जीवनकाल में
इस्तेमाल किया जाता है. सभी थ्रेड में क्रेडेंशियल शेयर करने के लिए, आपको बस एक ही क्रेडेंशियल का इस्तेमाल
करके हर सेशन बनाना होगा. उदाहरण के लिए, Java की क्लाइंट लाइब्रेरी में, आपको एक Credential सिंगलटन बनाना होगा और उसे सभी सेशन में शेयर करना होगा.
मल्टीप्रोसेस या डिस्ट्रिब्यूट
एक से ज़्यादा प्रोसेस या डिस्ट्रिब्यूटेड प्रोसेस के लिए, आपको क्रेडेंशियल शेयर करने से पहले उसे बनाए रखना होगा. यह पक्का करने के लिए कि कई प्रोसेस या सर्वर क्रेडेंशियल को एक ही समय पर रीफ़्रेश न करें, आपको कई बार रीफ़्रेश करने के अनुरोध एक ही प्रोसेस के लिए असाइन करने चाहिए.
उदाहरण के लिए, समय-समय पर क्रेडेंशियल को रीफ़्रेश करने और उसे सर्वर के एक समूह से शेयर किए गए डेटा स्टोर में भेजने की ज़िम्मेदारी एक अलग जॉब या सेवा की हो सकती है. इसके बाद, एपीआई अनुरोध करते समय हर सर्वर, डेटा स्टोर से क्रेडेंशियल हासिल कर सकता है.
जॉब को रीफ़्रेश करें
रीफ़्रेश करने की प्रोसेस शुरू करने से पहले, रीफ़्रेश जॉब को मौजूदा क्रेडेंशियल के खत्म होने का इंतज़ार नहीं करना चाहिए. ऐसा करने से, हो सकता है कि मान्य क्रेडेंशियल न होने की वजह से ऐप्लिकेशन बंद हो जाए. हालांकि, अगर एपीआई अनुरोध को प्रोसेस होने के दौरान, किसी क्रेडेंशियल के ऐक्सेस टोकन की समयसीमा खत्म हो जाती है, तो भी अनुरोध पूरा होगा और नतीजे दिखाए जाएंगे.
हमारा सुझाव है कि आप अपने ऐक्सेस टोकन को आखिरी बार रीफ़्रेश करने के समय को ट्रैक करें. अगर किसी टोकन की समयसीमा खत्म होने में पांच मिनट से कम हैं, तो उसे रीफ़्रेश करें.
अगर आपको नहीं पता कि किसी ऐक्सेस टोकन को आखिरी बार कब रीफ़्रेश किया गया था, तो उसे यह मानते हुए रीफ़्रेश करें कि उसकी समयसीमा पहले ही खत्म हो चुकी है. अगर ऐक्सेस टोकन, लैप्सिंग के करीब नहीं होता है, तो सर्वर वही ऐक्सेस टोकन दिखाता है. साथ ही, टोकन की समयसीमा खत्म होने तक बचे रहने वाले मिलीसेकंड भी दिखाता है.
डेटा स्टोर
आप किसी मौजूदा डेटा स्टोर का इस्तेमाल कर सकते हैं या सर्वर के बीच क्रेडेंशियल शेयर करने के लिए, कोई खास डेटा स्टोर डिप्लॉय कर सकते हैं. इसमें कैश मेमोरी में सेव किए गए सर्वर शामिल होते हैं, जैसे कि Memcached या Infinispan या NoSQL डेटा स्टोर, जैसे कि MongoDB.
डेटा स्टोर को तेज़ी से पढ़ने की कार्रवाइयों के लिए ऑप्टिमाइज़ किया जाना चाहिए, क्योंकि उसमें लिखने के मुकाबले, पढ़ने के बहुत ज़्यादा अनुरोध होंगे. साथ ही, क्रेडेंशियल सुरक्षित तरीके से सेव किए जाने चाहिए.
क्रेडेंशियल को सेव करते समय, आपको आपके दिए गए फ़ॉर्मूला के आधार पर तैयार किए गए expiry_time (अब + expires_in) और refresh_token को access_token के साथ सेव करना चाहिए. expiry_time का हिसाब, access_token को रीफ़्रेश करने के अनुरोध और expires_in के समय को जोड़कर किया जाता है.
सर्वर पूल
अनुरोध करने से पहले, पूल का हर सर्वर या प्रोसेस, डेटा स्टोर से नया क्रेडेंशियल हासिल करता है. जब तक रीफ़्रेश करने का जॉब सही तरीके से चल रहा है, तब तक क्रेडेंशियल मान्य रहेगा. हालांकि, अगर रीफ़्रेश जॉब या डेटा स्टोर काम नहीं करता, तो आपके पास फ़ॉलबैक मैकेनिज़्म होना चाहिए.
अगर किसी सर्वर या प्रोसेस को डेटा स्टोर से क्रेडेंशियल नहीं मिल पाता है या क्रेडेंशियल की समयसीमा खत्म हो गई है, तो सर्वर को अपने क्रेडेंशियल रीफ़्रेश करने चाहिए, ताकि समस्या हल होने तक ऐप्लिकेशन एपीआई के साथ काम कर सके.
एक से ज़्यादा खातों के लिए क्रेडेंशियल मैनेजमेंट
Google Ads मैनेजर खाते के लिए जनरेट किए गए क्रेडेंशियल का इस्तेमाल, उसके सभी चाइल्ड खातों को ऐक्सेस करने के लिए किया जा सकता है. इसलिए, एक मैनेजर खाते की हैरारकी वाले उपयोगकर्ताओं के लिए, आम तौर पर टॉप-लेवल वाले मैनेजर खाते का क्रेडेंशियल जनरेट करना काफ़ी होता है. इस क्रेडेंशियल का इस्तेमाल उसके नीचे के सभी Google Ads खातों के लिए किया जा सकता है.
अगर आपके ऐप्लिकेशन को ऐसे Google Ads खातों को ऐक्सेस करना है जो मैनेजर खाते की किसी भी हैरारकी में एक-दूसरे से संबंधित नहीं हैं, तो आपको अलग-अलग खातों के लिए अलग-अलग क्रेडेंशियल जनरेट करने होंगे और उन्हें मैनेज करना होगा. जैसे- ऐक्सेस किए जाने वाले हर Google Ads क्लाइंट खाते के लिए या फिर ऐक्सेस किए जाने वाले स्वतंत्र पदानुक्रम के हर टॉप-लेवल मैनेजर खाते के लिए.
छोटे-मोटे बदलावों के साथ, मल्टीथ्रेड या मल्टीप्रोसेस / डिस्ट्रिब्यूटेड ऐप्लिकेशन के लिए, एक जैसी रणनीतियों का इस्तेमाल किया जा सकता है. शेयर किए गए डेटा स्टोर का इस्तेमाल करते समय, क्रेडेंशियल को खाता आइडेंटिफ़ायर customerId से इंडेक्स किया जाना चाहिए. इससे यह पक्का किया जा सकता है कि क्रेडेंशियल सही खाते से जुड़े हैं.
इसके अलावा, रीफ़्रेश करने पर सभी क्रेडेंशियल रीफ़्रेश होने चाहिए. अगर कोई नया खाता लिंक किया गया है, तो रीफ़्रेश जॉब को ट्रिगर करना पड़ सकता है.
आखिर में, मल्टीथ्रेड ऐप्लिकेशन में, आपको क्रेडेंशियल ऑब्जेक्ट को सिर्फ़ उन थ्रेड में शेयर करना चाहिए जो उसी खाते पर चल रहे हैं जिससे क्रेडेंशियल ऑब्जेक्ट जुड़ा है.