لقد قمنا بشحن ضمادة مصادقة في الساعة 2 صباحًا. لن تتدفق ملفات تعريف الارتباط بين Platform.ginilab.com وبوابتنا، التي كانت تعمل ضمن نطاق مختلف قابل للتسجيل. المتصفحات حظرتهم، بشكل صحيح. كانت الحزمة التي فتحت العرض التوضيحي عبارة عن رمز مميز لحامل مدته 5 دقائق محفوظ في متجر Zustand على الواجهة الأمامية، ويتم إرفاقه يدويًا بكل طلب. لقد نجحت.
وفي غضون 24 ساعة، قمنا بشحن أربعة علاقات عامة من الحلول البديلة لنطاق ملفات تعريف الارتباط. ثم طرح أحدهم السؤال الواضح: "لماذا لا يكون api.ginilab.com مجرد اسم مضيف آخر على نفس البوابة؟" لقد كان. لقد تعمقنا في مشكلة قمنا بحلها في سجل DNS واحد.
هذا الخطأ - عدم تطابق مجال ملفات تعريف الارتباط في نظام أساسي متعدد العلامات التجارية - هو نسخة من فقرة واحدة توضح سبب وجود هذا المنشور.
تحذير واحد قبل أن نذهب أبعد من ذلك. الإصدار 3 قيد التدريج. لم تتم معالجة المدفوعات المباشرة بعد. يعمل أكثر من 300 مطعم على مجموعة PHP/MySQL القديمة الخاصة بنا اليوم، ولم تبدأ عملية ترحيل المجموعة بعد. ما يلي هو الهندسة المعمارية التي نراهن عليها والألم الذي ضربناه للوصول إلى هنا، وليس حضن النصر. إذا كنت تريد قصة "لقد قمنا بالتوسيع إلى مليار طلب"، فهذه ليست هي القصة. إذا كنت تريد حسابًا صادقًا أثناء الهجرة من فريق صغير، فتابع القراءة.
Ginilab عبارة عن منصة خلفية واحدة تدير أربعة منتجات. Tomafood هو خدمة طلب المطاعم، مع وجود أكثر من 300 مطعم في المجموعة القديمة وإعادة الكتابة الكاملة إلى الإصدار الثالث قيد التقدم. CloudPOS هو نقطة بيع بالتجزئة غير الغذائية. iSchool هي إدارة المدرسة. التجارة الإلكترونية هي التجارة الإلكترونية العامة. Tomafood هو إعادة الكتابة الكاملة. الثلاثة الأخرى تستهلك الخدمات المشتركة عبر REST أو SDK. إنها ليست قواعد تعليمات برمجية منفصلة. فهي ليست واجهات خلفية منفصلة. إنها منتجات مختلفة مثبتة على نفس المنصة.
هذا غير عادي. تقوم معظم فرق SaaS إما ببناء منتج واحد والبقاء فيه، أو إنشاء منصات منفصلة لكل منتج عند وصول المنتج الثاني. أما شكل النظام الأساسي المشترك عبر المنتجات فهو المسار الثالث، وله ضريبة: كل قرار معماري يجب أن يفترض أكثر من مستهلك واحد، وأكثر من علامة تجارية واحدة، وأكثر من مجال واحد. تظهر الضريبة مبكرًا ولا تختفي أبدًا.