ما أطلقناه هذا الشهر: الترميز الجغرافي وIP والمنطقة الزمنية والمزيد
ملخص للعمل الأخير في الواجهة: مضيفات توافق جديدة، واستعلامات أسرع للمنطقة الزمنية والارتفاع، وميزات جديدة في لوحة التحكم، ورؤية أوضح للحصة.
أوقات استجابة أسرع بعد ترقية البنية التحتية
يمر كل طلب إلى 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/.