بناء SDK لواجهة برمجة تطبيقات فيديو (Video API) آمن النوع (Type-Safe) بلغة Rust
فساد البيانات غالبًا ما يكون صامتًا.
في الربع الأخير، قام نظام الخلفية (backend) الخاص بي بسحب البيانات الوصفية للفيديو من ثماني مناطق. كان النظام القديم يستخدم نصًا برمجيًا بلغة PHP. استمر في العمل حتى قام أحد المزودين بتغيير أحد الحقول. تسبب طابع زمني واحد مشوه في كتابة صفوف غير صالحة في قاعدة بياناتنا.
لم نلاحظ ذلك لمدة ثلاثة أيام. لم يتوقف النظام عن العمل، بل اكتفى بعرض عناوين فارغة للمستخدمين.
قمت باستبدال طبقة جلب البيانات (fetch layer) بـ Rust SDK. اخترت Rust لأن reqwest و serde يفرضان عقد بيانات (data contract) صارمًا. إذا كانت البيانات خاطئة، سيفشل النظام بشكل صريح عند نقطة الحدود، ولن يقوم بكتابة بيانات سيئة في قاعدة البيانات.
إليك كيف قمنا ببنائه:
• تحديد عقد البيانات (Data Contract) استخدمت serde لتحديد شكل الفيديو بدقة. استخدمت Option للحقول التي قد تكون مفقودة. واستخدمت مُحلل تسلسل مخصص (custom deserializer) للطوابع الزمنية للتعامل مع تنسيقات التاريخ المختلفة. هذا يمنع خطأ "1970-01-01" الشائع في الأنظمة القديمة.
• تصنيف الأخطاء الـ SDK الجيد يخبرك لماذا فشل الطلب. استخدمت thiserror لإنشاء قائمة أخطاء محددة. قمت بفصل الأخطاء العابرة (transient errors) مثل حدود معدل الطلبات (rate limits) عن الأخطاء القاتلة مثل الوصول غير المصرح به. يتيح ذلك للنظام اتخاذ قرارات ذكية لإعادة المحاولة بدلاً من إهدار الموارد.
• إدارة الاتصالات استخدمت reqwest::Client للحفاظ على مجمع اتصالات (connection pool). وهذا يتجنب العبء الإضافي الناتج عن بدء مصافحات TLS جديدة لكل طلب.
• تبسيط المنطق باستخدام التدفقات (Streams) استخدمت async_stream للتعامل مع الترقيم (pagination). لا يحتاج المستدعي (caller) إلى إدارة رموز الصفحات (page tokens)، بل يقوم ببساطة بالتكرار عبر تدفق (stream) من الفيديوهات.
النتيجة هي نظام يحمي قاعدة البيانات. لا يزال الموقع الرئيسي يعمل بلغة PHP، ولا تزال قاعدة البيانات هي SQLite، ولكن البيانات التي تدخل قاعدة البيانات مضمونة الآن بأنها نظيفة.
لست بحاجة إلى إعادة كتابة تطبيقك بالكامل للحصول على أمان النوع (type safety). كل ما تحتاجه هو نقل عملية التحقق (validation) إلى النقطة التي تدخل عندها البيانات إلى نظامك.