إنشاء حزمة أدوات تطوير البرامج (SDK) لمتصفحات الويب: 3 دروس تعلمناها

تُعد حزم أدوات التطوير (SDK) المدمجة في المتصفح وسيلة رائعة لنقل مشروعك إلى الويب وتبسيط طريقة وصول مطوري التطبيقات إلى خدماتك.

في الواقع، قامت عدد من الشركات الكبرى بإنشاء مكتبة حول واجهات برمجة التطبيقات (API) الخاصة بها بهذه الطريقة.

تتيح «أمازون»، على سبيل المثال، للمطورين دمج خدمات AWS في تطبيقاتهم الويب باستخدام كود JavaScript الذي يعمل في المتصفح. وتقوم كل من «فيسبوك» و«سترايب» و«تويليو» بأمور مماثلة.

في Microblink، تعمل معظم منتجاتنا الآن عبر المتصفحات. أردنا أن يتمكن المطورون من إنشاء تجارب بسيطة لكنها فعالة مباشرةً على الواجهة الأمامية لتطبيقات الويب الخاصة بهم، وأردنا أن يستمتع مستخدمونا النهائيون بهذه التجارب دون الحاجة إلى مغادرة علامة التبويب التي يعملون عليها أبدًا.

كانت أكبر مشكلة واجهتنا في تحقيق هذا الهدف هي: أن جميع منتجاتنا تتطلب معالجة مكثفة للصور على الجهاز، وهو أمر لم تكن المتصفحات قادرة على التعامل معه… حتى وقت قريب.

نصيحة رقم 1: يُعد WebAssembly الخيار الأمثل إذا كان الكود الخاص بك يتطلب عمليات حسابية مكثفة

في الماضي، كان كل ما تستطيع المتصفحات فعله هو عرض الصفحات. أما اليوم، فهي تتيح لك البرمجة وتحرير مقاطع الفيديو وممارسة الألعاب من داخلها.

ويُعزى جزء كبير من هذا التحسن في الأداء إلى الانتشار الواسع لـ WebAssembly، وهو معيار ويب جديد يعمل جنبًا إلى جنب مع JavaScript لتجميع التعليمات البرمجية منخفضة المستوى، مما يتيح للمتصفحات تنفيذها بسرعة أكبر. (1)

نظرًا لتنسيقه الثنائي المضغوط، يُعد WebAssembly الخيار المثالي عندما تحتاج إلى إنشاء تجارب تشبه التطبيقات الأصلية على الويب. وفي حالتنا، يتعلق الأمر باستخراج البيانات في الوقت الفعلي مع استخدام قدر كبير من الذكاء الاصطناعي في الخلفية.

كما ترون، فإن WebAssembly سريع. فالمنطق المعقد المستخدم في الكشف عن بطاقات الائتمان والتعرف عليها وقراءتها من بث الفيديو الخاص بالمستخدم يعمل بسلاسة تامة، على الرغم من الدقة المنخفضة للصورة الواردة من كاميرا الكمبيوتر المحمول.

وبالنسبة لمستخدمينا النهائيين، فإن هذا يجعل عملية التسجيل أو الدفع عبر الإنترنت سهلة بقدر مسح البيانات ضوئيًا – حيث لا يتطلب الأمر سوى نقرة واحدة للوصول إلى التجربة بأكملها.

بالإضافة إلى تحسين الأداء، فإن ترجمة الكود إلى WebAssembly توفر لنا ما يلي:

• أمان معزز: يعمل WebAssembly في بيئة آمنة ومعزولة، كما أن إجراء الهندسة العكسية عليه أصعب بكثير من JavaScript بسبب تنسيق البايت كود الخاص به.
• إمكانية الوصول والتوافق التشغيلي: أصبح WebAssembly مؤخرًا المعيار الرسمي لاتحاد شبكة الويب العالمية (W3C) (تمامًا مثل HTML وCSS).
• قابلية التشغيل على أجهزة مختلفة: يمكن تشغيل WebAssembly خارج المتصفح أيضًا، على مجموعة متنوعة من أنظمة التشغيل وبنيات مجموعات الأوامر.

تمت كتابة الكود المصدري الخاص بمجموعات أدوات التطوير (SDK) الخاصة بنا بلغة C++، ولكن يمكنك أيضًا ترجمة WebAssembly من لغات Rust وGo وAssemblyScript والعديد من اللغات الأخرى.

فيما يلي نظرة عامة على كيفية سير العملية. ستلاحظ أننا اخترنا متصفح «كروم» لتوضيح وجهة نظرنا، لأنه المتصفح المفضل لحوالي ثلثي مستخدمي الإنترنت في العالم. (2)

ومع ذلك، علينا أن نفكر في الثلث المتبقي. وهذا يعني التطوير مع مراعاة التوافق بين المتصفحات المختلفة.

نصيحة رقم 2: تعامل مع مشكلات التوافق مع المتصفحات من خلال التحسين التدريجي لحزمة SDK الخاصة بك

غالبًا ما يؤدي العمل مع واجهات برمجة التطبيقات (API) الجديدة للمتصفحات أو تقنيات مثل WebAssembly إلى فشل بعض ميزاتك في متصفحات معينة، إما لأنها محجوبة لسبب ما أو لأنها غير مدعومة على الإطلاق.

على سبيل المثال، لن ينجح استدعاء واجهة برمجة تطبيقات WebRTC لمعالجة الفيديو في الوقت الفعلي في متصفح Chrome على أي جهاز iPhone يعمل بنظام iOS 14.2 أو إصدار أقدم، لأن WebView من Apple لا يدعم هذه الميزة.

لنفترض أنك تعمل على تطوير حزمة تطوير تطبيقات (SDK) لمؤتمرات الفيديو على الويب. أنت الآن تواجه مشكلة؛ لأن مستخدمي iPhone الذين لم يقوموا بتحديث برامجهم منذ بضعة أشهر لن يتمكنوا من الانضمام إلى أي اجتماع إلا من خلال متصفح Safari.

لقد واجهنا المشكلة نفسها فيما يتعلق بدعم WebRTC، وقد لا يمتلك بعض مستخدمينا كاميرا ويب أصلاً. والطريقة التي تغلبنا بها على هذه المشكلة هي نفس الطريقة التي تتعامل بها مع أي مأزق: من خلال التراجع خطوة إلى الوراء وإعادة ترتيب الأولويات.

التحسين التدريجي في الممارسة العملية

في مجال تطوير الويب، يعني «التحسين التدريجي» أنك توفر الميزات الأساسية للجميع أولاً، في حين أن الوظائف الأكثر تقدمًا لا تتوفر إلا لمستخدمي أحدث المتصفحات.

نحن ندرك أن الميزة الأساسية لخدمتنا ليست عملية المسح الضوئي بحد ذاتها، بل عملية استخراج البيانات التي تليها. نحتاج إلى الحصول على صورة للمستند، لكن يمكن للمستخدم ببساطة تحميل صورة من معرض الصور بدلاً من تشغيل كاميرا الويب.

هذه الوظيفة الأساسية هي ما يراه جميع مستخدمينا. وبعد الانتهاء من تغطية الأساسيات، نتحقق مما إذا كان بإمكاننا الوصول إلى الكاميرا لإجراء المسح الضوئي الفعلي للمستند.

من المفيد أن ترسم خريطة لرحلة المستخدم منذ البداية، وأن تحدد ما الذي سيحدث في حالة فشل تحميل إحدى الميزات. وإليك كيف قمنا بتصميم مسارنا قبل بناء حزمة SDK:

التحقق مما إذا كان المتصفح يدعم إحدى الميزات

قبل تحديد المستوى الأساسي لتجربة المستخدم، يتعين علينا معرفة الميزات التي ستعمل عبر المتصفحات وتلك التي لن تعمل.

ولتحقيق ذلك، يمكنك إما تنفيذ اختباراتك الخاصة أو استخدام مكتبة موجودة مسبقًا مثل wasm-feature-detect من Google. ونحن نستخدمها لتحميل حزمة WebAssembly المناسبة لمستخدمينا أثناء التشغيل، بدءًا من الأكثر توافقًا وصولًا إلى الأكثر أداءً. فيما يلي مثال يوضح كيفية التحقق مما إذا كانت ميزة SIMD، وهي إحدى ميزات WebAssembly، مدعومة أم لا.

<script type="module">
import { simd } from "https://unpkg.com/wasm-feature-detect?module";
simd().then(simdSupported => {
if (simdSupported) {
/* SIMD is supported */
} else {
/* SIMD isn't supported */
}
});
</script>

قم بإجراء اختبار عبر المتصفحات لكل ميزة من ميزاتك، وقم بإنشاء منطق حلول بديلة للتغلب على حالات عدم الدعم، وقبل أن تدرك ذلك، ستكون قد بدأت في تحسين حزمة SDK الخاصة بك بشكل تدريجي.

نصيحة رقم 3: تجنب الأعمال الرتيبة باستخدام البرمجة التلوية

إذا كنت تخطط لإنشاء عدة حزم SDK (أو حتى تطبيقات ويب) تشترك في وظائف متشابهة، فقد ترغب في الاطلاع على موضوع البرمجة التلوية.

البرمجة التلوية هي تقنية يتعامل فيها برنامج حاسوبي مع البرامج الأخرى باعتبارها بيانات له. وهي تتيح أتمتة الأعمال التي تستغرق وقتًا طويلاً وتكون مملة في كثير من الأحيان، وذلك عن طريق كتابة برامج تقوم هي نفسها بكتابة برامج أخرى.

على سبيل المثال، تتميز حزم SDK الخاصة بنا المدمجة في المتصفح ببنية مشابهة، لكنها تعالج مشكلات مختلفة تمامًا. وتساعدنا البرمجة التلوية على تحويل ملفات JavaScript الحالية، بل وحتى إنشاء ملفات جديدة لكل حزمة SDK من أجل:

• إنشاء كود نموذجي من مستودع ميتا واحد
• أضف ميزة جديدة مرة واحدة لتعمل في كل مكان
• إصلاح خطأ في مكان واحد وتغيير السلوك غير المرغوب فيه في جميع حزم SDK
• تغيير مفاتيح الترخيص بشكل جماعي، وتعديل مسارات ملفات WebAssembly، وما إلى ذلك.

نستخدم تقنيتين مختلفتين للبرمجة التلوية، اعتمادًا على نطاق التغييرات التي يتعين إجراؤها: البرمجة التلوية القوالب (TMP) ومعالجة شجرة الصياغة المجردة (AST).

تُعد البرمجة الفوقية القوالب مفيدة عندما تحتاج إلى إنشاء ملفات JavaScript متعددة من ملف واحد عام.

يُعد استخدام ASTs لتعديل الكود أمراً مفيداً في تعديل ملفات الكود المصدري الحالية مع الحفاظ على أسلوبها وبنية الكود.

سنلقي نظرة أكثر تفصيلاً على كيفية تطبيق هاتين التقنيتين في مقال قادم على المدونة.

المتصفحات: المكان الذي لا بد من التواجد فيه

مع استمرار تطور المتصفحات، من المؤكد أننا سنشهد زيادة في عدد حزم أدوات التطوير (SDK) التي ستوفر تجارب أبسط وأكثر تخصيصًا عبر شبكة الإنترنت.

نأمل أن تساعدك النتائج التي أوضحناها أعلاه على تصميم نموذج خاص بك — مع مراعاة الأداء وسهولة الاستخدام والتصميم الهندسي الذكي.

هل تستمتع بالعمل على حزم تطوير البرامج (SDK) الرائعة التي تعمل داخل المتصفح؟ تعال وانضم إلينا