نقل أتمتة Zapier أو Make إلى مضيف ترميز جغرافي جديد
تحتاج عمليات الأتمتة دون شيفرة المبنية على خطوة ترميز جغرافي إلى نهج ترحيل مختلف عن الشيفرة المخصصة. إليك كيفية التعامل مع هذا التحويل.
ترحيل استدعاءات الترميز الجغرافي في تطبيق للهاتف المحمول
ترحيل استدعاءات الترميز الجغرافي التي تُجرى مباشرة من تطبيق جوال يفرض بعض القيود التي لا يضطر الترحيل على الخادم وحده إلى التعامل معها، ومن المفيد تسميتها بوضوح قبل البدء، لأنها تغيّر شكل الخطة.
القيد الأول هو وتيرة الإصدار. فالتغيير على الخادم يمكن أن يصبح فعّالًا لحظة نشره. أما تغيير تطبيق الجوال فيجب أن يمر بمراجعة متجر التطبيقات، ثم يعتمد انتشاره على قيام المستخدمين بالتحديث فعلًا، وهو ما يستغرق في كثير من التطبيقات أسابيع للوصول إلى غالبية قاعدة التثبيت، وقد يستغرق وقتًا أطول بكثير للوصول إلى الجميع. وأي خطة ترحيل لتطبيق جوال تحتاج إلى أن تأخذ في الحسبان تشغيل مزودين اثنين، أو نسختين من التطبيق، جنبًا إلى جنب لمدة أطول مما يتطلبه ترحيل الخادم عادةً.
القيد الثاني هو كشف بيانات الاعتماد. فمفتاح API المضمّن مباشرة في الملف التنفيذي لتطبيق جوال يمكن استخراجه من قِبل أي شخص لديه الدافع للبحث، وهذا اعتبار أمني بغض النظر عن المزود المعني. وإذا كان تكاملك الحالي يستدعي API ترميز جغرافي مباشرة من العميل بمفتاح مضمّن، فإن الترحيل لحظة مناسبة لإعادة النظر في هذا النمط ونقل الاستدعاء خلف خادمك الخلفي بدلًا من ذلك، حتى لو أضاف ذلك قليلًا من زمن الاستجابة وقليلًا من العمل على الخادم الخلفي.
بعض الخطوات العملية التي تنطبق على معظم عمليات الترحيل في تطبيقات الجوال:
- إذا كنت ستنقل الاستدعاء إلى الخادم، فصمم نقطة النهاية الجديدة في الخادم الخلفي أولًا واجعل تطبيق الجوال يتواصل مع API الخاص بك قبل أن تهتم بالمزود الذي يقف خلفه، وبذلك تفصل التغيير في جانب التطبيق عن التغيير في جانب المزود فصلًا تامًا
- إذا كنت ستُبقي الاستدعاء في جانب العميل، فاستخدم قيمة تهيئة وقت البناء لمضيف API والمفتاح بدلًا من كتابتهما مباشرة في الشيفرة، حتى لا يتطلب أي ترحيل مستقبلي البحث عن سلسلة نصية حرفية واستبدالها عبر قاعدة الشيفرة مرة أخرى
- اختبر على نسخ التطبيق القديمة الفعلية التي لا تزال مستخدمة، لا على أحدث إصدار فقط، إذا كنت تخطط لدعم المزودين كليهما خلال فترة انتقالية، لأن نسخة قديمة من التطبيق تستدعي مضيفًا قديمًا سيُوقف قريبًا سيناريو واقعي يستحق قرارًا صريحًا بشأن المدة التي ستستمر فيها في دعمه
تعمل خيارات المصادقة في My Geocode، ترويسة X-API-Key أو ترويسة Authorization: Bearer أو مصادقة HTTP Basic أو معامل استعلام، بالطريقة نفسها سواء صدر الطلب من عميل جوال مباشرة أو من خادمك الخلفي الذي يمرر الاستدعاء بالوكالة، لذا فإن هذا القرار تحديدًا (جانب العميل مقابل جانب الخادم) لا يقيّد أسلوب المصادقة المتاح في أي من الحالتين. ويظهر استهلاك الحصة في كل استجابة عبر ترويسات مثل X-Quota-Used وX-Quota-Reset، الموثقة في /docs/rate-limits/، وهو أمر مفيد لمراقبة تقدم طرح ترحيل تطبيق الجوال إذا كان بإمكانك الوصول إلى هذه الترويسات من المكان الذي تصدر منه الطلبات.
تكافئ عمليات الترحيل في تطبيقات الجوال الصبر أكثر مما تكافئه عمليات الترحيل على الخادم، ويرجع ذلك أساسًا إلى أن دورة الإصدار والانتشار تفرض جدولًا زمنيًا لا يمكنك ضغطه بالعمل بشكل أسرع. والتخطيط لنافذة انتقالية أطول منذ البداية يجنبك الإحباط الناتج عن توقع وتيرة ترحيل الخادم من عملية لا تستطيع بنيويًا التحرك بتلك السرعة.