इस महीने हमने क्या लॉन्च किया: जियोकोडिंग, IP, समय क्षेत्र और बहुत कुछ
पूरे API में हाल के काम का सार: नए कम्पैटिबिलिटी होस्ट, तेज़ समय क्षेत्र और ऊँचाई लुकअप, डैशबोर्ड की सुविधाएँ, और कोटा की ज़्यादा साफ़ जानकारी।
इन्फ्रास्ट्रक्चर अपग्रेड के बाद तेज़ रिस्पॉन्स समय
My Geocode पर हर अनुरोध जवाब लौटने से पहले उसी सर्विंग इंफ्रास्ट्रक्चर से गुज़रता है, चाहे वह किसी भी एंडपॉइंट पर जाए या किसी भी कम्पैटिबिलिटी होस्ट की संरचना में हो। हमने हाल ही में उस साझा इंफ्रास्ट्रक्चर का अपग्रेड पूरा किया है, और इसका नतीजा हर जगह तेज़ रिस्पॉन्स टाइम है।
यह किसी एक एंडपॉइंट तक सीमित बदलाव नहीं, बल्कि पूरे प्लेटफ़ॉर्म का बदलाव है। /v1/forward, /v1/reverse, /v1/ip, /v1/timezone, /v1/elevation, /v1/autocomplete और /v1/postcode सभी उसी अपग्रेड किए गए स्टैक पर हैं, और सभी सत्रह कम्पैटिबिलिटी होस्ट भी। इसके तहत अनुरोध पैरामीटर, रिस्पॉन्स फ़ील्ड, ऑथेंटिकेशन के तरीकों या कीमतों में कुछ नहीं बदला है। अपग्रेड पूरी तरह पर्दे के पीछे है, और सिर्फ़ इस बात में दिखता है कि रिस्पॉन्स कितनी जल्दी लौटता है।
ज़्यादातर इंटीग्रेशन के लिए इस तरह का सुधार सटीक रूप से मापा नहीं, बल्कि महसूस किया जाता है, एक आम एहसास कि कॉल पहले से थोड़ी जल्दी लौटती हैं। अच्छी-खासी मात्रा वाले इंटीग्रेशन के लिए, खासकर कई आइटम को क्रम से प्रोसेस करने वाले बैच जॉब, या यूज़र के टाइप करते समय बार-बार चलने वाले ऑटोकम्प्लीट जैसे ट्रैफ़िक के लिए, असर कई अनुरोधों में जुड़ता जाता है और सीधे देखना आसान हो जाता है। जो ऑटोकम्प्लीट फ़ील्ड आठ अक्षरों वाले सर्च शब्द के हर कीस्ट्रोक पर अनुरोध भेजता है, वह उसे टाइप करने के समय में आठ कॉल करता है, और हर कॉल से थोड़ा सा समय भी घटाना पूरे अनुभव को ऐसे बदल देता है जो एक अकेले लुकअप में बिल्कुल नहीं दिखता।
हम इस तरह के इन्फ्रास्ट्रक्चर कार्य को एक बार के प्रोजेक्ट के बजाय एक निरंतर ज़िम्मेदारी मानते हैं। जिस जियोकोडिंग API पर लोग वास्तविक प्रोडक्ट बनाते हैं, उसे सिर्फ़ लॉन्च के दिन नहीं, बल्कि उपयोग बढ़ने के साथ भी अच्छा प्रदर्शन करते रहना होता है, और इसका मतलब है कि सर्विंग स्टैक को अनिश्चित काल तक बिना छुए छोड़ने के बजाय समय-समय पर उस पर दोबारा काम करना। यह अपग्रेड उस चलती प्रक्रिया का एक कदम है, अंतिम मंज़िल नहीं।
चूँकि हर एंडपॉइंट और हर कम्पैटिबिलिटी होस्ट एक ही साझा स्टैक से होकर चलता है, इसलिए ऐसा अपग्रेड सिर्फ़ एक बार करना होता है और उसका लाभ सभी को मिलता है, उसे हर एंडपॉइंट या हर होस्ट के लिए अलग-अलग दोहराना नहीं पड़ता। यही साझा डिज़ाइन इस बात की वजह भी है कि यहाँ किया गया बदलाव कभी अनुरोध के फ़ॉर्मैट, रिस्पॉन्स फ़ील्ड या कोटा इंजन को नहीं छूता: वे पूरी तरह एक अलग लेयर पर रहते हैं।
इसके परिणामस्वरूप कोटा या बिलिंग की कोई भी व्यवस्था नहीं बदलती। हर रिस्पॉन्स में अब भी कोटा हेडर का वही पूरा सेट आता है, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining, X-Quota-Network-Used, X-Credits-Remaining, X-Key-IPs-Used, X-Key-IPs-Limit और X-Quota-Reset, और मुफ़्त कोटा, प्रीपेड क्रेडिट की दर और Unlimited पैकेज की कीमत सभी पहले जैसे हैं।
हर कम्पैटिबिलिटी होस्ट भी इसी साझा स्टैक पर चलता है, इसलिए TomTom जैसी बनावट वाली कॉल और /v1/forward पर की गई नेटिव कॉल, दोनों को एक जैसा लाभ मिलता है, और यह सुधार ऐसा कुछ नहीं है जिसे हर होस्ट के लिए माँगना पड़े या किसी खास इंटीग्रेशन के लिए अलग से तय करना पड़े।
अगर आपका इंटीग्रेशन रिस्पॉन्स टाइम के प्रति संवेदनशील है, चाहे इसलिए कि वह सीधे उपयोगकर्ताओं के सामने है या इसलिए कि वह बड़ी संख्या में बैच अनुरोध प्रोसेस करता है, तो आपको अपनी ओर से कुछ भी बदले बिना फ़र्क दिखना चाहिए। हर एंडपॉइंट का पूरा दस्तावेज़ बिल्कुल पहले जैसा है और /docs/ पर उपलब्ध है।