من 600 سطر React إلى 40 سطرًا JSON
داخل وقت تشغيل DEX توجد وحدة تسمى descriptor resolver — نحو 1,100 سطر من TypeScript مهمتها الوحيدة هي المرور عبر JSON descriptor وارد، وسحب الأذونات من سياق الجلسة، وإنتاج شجرة مكونات مُعروضة لديها بالفعل RBAC وخطافات التدقيق والتحقق مُوصّلة قبل أن تصل أول بكسل إلى المتصفح. هذا المحلّل هو السبب في أن واصف إعداد بائع من 43 سطرًا يمكن أن يحل محل 610 أسطر من React مكتوبة يدويًا و2,400 سطر من PL/SQL. الواصف لا يصف كل ما تفعله الشاشة. يصف فقط ما يختلف عن السلوك الافتراضي لوقت التشغيل.
الواصف ليس أقصر لأننا قطعنا ميزات. إنه أقصر لأن وقت التشغيل يحمل كل شيء لا يتغير بين الشاشات.
في أيام Oracle 10g، نحو عام 2009، انضممت إلى فريق أمضى ثلاث سنوات ينسخ وينسخ الكتلة نفسها من “رأس قياسي” من 140 سطرًا — فحص المصادقة، وختم التدقيق، ومحوّل اللغة، وحماية الدور — في كل وحدة Forms جديدة. عددتها مرة: 216 شاشة، 216 نسخة شبه متطابقة، كل واحدة منحرفة قليلًا عن الأخرى. عندما غيّر تنظيم جديد تنسيق التدقيق، احتجنا أربعة أشهر ومطوّرَين بدوام كامل لنشر الإصلاح. ذلك المشروع هو الشبح الذي يجلس على كتفي كلما اقترح أحد جعل وقت التشغيل أنحف والواصفات أغنى. الاهتمامات المشتركة تنتمي إلى كود مشترك، مُختبَر مرة واحدة.
ما يفعله وقت التشغيل فعليًا
وقت التشغيل هو الـ 90% المملّة. المصادقة ضد مزوّد هوية المؤسسة. إنفاذ RBAC على كل حقل وإجراء. تسجيل تدقيق بتنسيق يعرف مدققو SOX كيف يقرؤونه بالفعل. التحقق من النموذج برسائل الخطأ نفسها على العميل والخادم. الترجمة. التنقل بلوحة المفاتيح. التحديثات التفاؤلية مع التراجع. التصدير إلى Excel. تخطيطات الطباعة. إمكانية الوصول وصولًا إلى حلقة التركيز.
لا شيء من هذا ينتمي إلى الواصف. وضعه هناك سيحوّل كل شاشة إلى مسؤولية. يتعامل وقت التشغيل معها مرة واحدة، في TypeScript، في كود نملكه ونختبره.
مخطط الواصف
للواصف خمسة أقسام على المستوى الأعلى: البيانات، والتخطيط، والمنطق، والتكاملات، والوصول. كل واحد يُتحقق منه مقابل JSON Schema قبل أن يُعرض أي شيء. يعمل المُتحقق في المتصفح، وفي خط أنابيب البناء، وفي حلقة استخدام الأدوات الخاصة بـ LLM، لذا تفشل الواصفات المشوهة في المكان نفسه في كل مرة.
يُسمّي قسم البيانات الكيانات والحقول من الطبقة الدلالية. يصف قسم التخطيط المناطق، لا وحدات البكسل. يعلن قسم المنطق القواعد — “الموافقة مطلوبة عندما يتجاوز المبلغ الحد” — بدلًا من كود إلزامي. تُشير التكاملات إلى نقاط نهاية مُسمّاة من مستند OpenAPI. يُشير الوصول إلى الأدوار من نظام RBAC.
لا شيء في الواصف هو سلسلة حرة يجب على وقت التشغيل تفسيرها إرشاديًا. كل مرجع يُحلّ إلى شيء يعرفه وقت التشغيل بالفعل.
لماذا لم نبنِ محررًا مرئيًا أولًا
المنتج الواضح لهذه المعمارية هو باني سحب وإفلات. بنينا عمدًا وقت التشغيل ومخطط الواصف أولًا، مع محرر نصي عادي كسطح التأليف الوحيد، ثم أضفنا توليد الذكاء الاصطناعي قبل أن نضيف محررًا مرئيًا.
السبب ممل. يُقيّد محرر مرئي ما يمكنك التعبير عنه بما يمكن للمحرر رسمه. يُقيّد المخطط ما يمكنك التعبير عنه بما يمكن لوقت التشغيل تنفيذه. القيد الثاني هو ما يهم لأنظمة الإنتاج. بمجرد أن يكون المخطط صحيحًا، يكون المحرر المرئي مباشرًا. إذا كان المخطط خاطئًا، يُغطّي المحرر المرئي على المشكلة حتى يصطدم عميل بحالة استثنائية لم يُظهرها له المحرر أبدًا.
نقاط التمديد
كل شاشة مؤسسية لديها شيء واحد على الأقل لا يستطيع الواصف التعبير عنه. حساب مخصص. نقطة نهاية SOAP قديمة لا يريد أحد لمسها. عنصر واجهة خاص بتنظيم معين. يتعامل وقت التشغيل مع هذه عبر نقاط تمديد مُسمّاة — وحدات TypeScript يُشير إليها الواصف بالاسم.
هذا يُبقي الواصف إعلانيًا مع ترك فتحات هروب للواقع. وجدنا أن نحو 5% من الشاشات تحتاج إلى تمديد، وتلك التي تحتاج عادةً ما تحتاج إلى واحد بالضبط. تبقى الـ 95% الأخرى JSON خالص.
ما تكلفنا به هذه المعمارية
كل اختيار معماري له ثمن. ثمننا هو وقت التشغيل نفسه. إنه قطعة غير تافهة من TypeScript يجب صيانتها واختبارها وإصدارها بعناية، لأن كل شاشة في الإنتاج تعتمد عليها. خطأ في طبقة إنفاذ RBAC هو خطأ في كل شاشة في آن واحد.
نتعامل مع وقت التشغيل بالطريقة التي يتعامل بها مورد قاعدة بيانات مع مخطط استعلامات. إصدارات محافظة. مجموعات انحدار واسعة. توافق رجعي على مخطط الواصف يُقاس بالسنوات، لا الـ sprints. هذا ثمن جعل الواصفات رخيصة.
الخلاصة
JSON descriptors ليست حيلة. إنها تقسيم للعمل. يملك وقت التشغيل الأجزاء التي يجب أن تكون صحيحة في كل مرة. يملك الواصف الأجزاء التي تتغير لكل شاشة. يكتب LLM الواصف. يقرأ المدقق الواصف. يرى المستخدم واجهة إنتاج تتصرف كبرنامج مؤسسي لأن البرنامج المؤسسي هو ما بُني وقت التشغيل لعرضه.