بناء منصة الأبلم القانونية — دراسة هندسية شاملة من الفكرة للإنتاج
كيف قمت بهندسة منصة قانونية متكاملة لمكتب محاماة رائد في دبي — من المتطلبات حتى النشر على الإنتاج.

نظرة عامة
حين تواصل معي مكتب المحامي عبد العزيز الأبلم للمحاماة والاستشارات القانونية، كانوا بحاجة إلى أكثر من مجرد موقع إلكتروني — كانوا يحتاجون إلى تحول رقمي كامل. كان الوضع القائم عبارة عن صفحة ثابتة لا تحتوي على أي قدرات تشغيلية. كان الهدف بناء منصة متكاملة، متعددة اللغات، ومدعومة بـ Backend قوي يتعامل مع استفسارات العملاء الحقيقية ويوفر لوحة تحكم إدارية للفريق القانوني.
هذا المقال يأخذك في رحلة القرارات التقنية والمعمارية والتحديات التي واجهتها في بناء alablam.org.
المتطلبات
قبل كتابة سطر واحد من الكود، أمضيت وقتاً في فهم طبيعة العمل:
- الجانب العام للموقع: ثنائي اللغة (عربي وإنجليزي) مع دعم RTL كامل وهوية بصرية احترافية تليق بمكتب محاماة.
- نظام الاستفسارات: يتقدم العملاء بطلبات القضايا ← تُوجَّه للفريق القانوني المختص.
- لوحة التحكم الإدارية: يتمكن الفريق غير التقني من إدارة المحتوى، ومراجعة الاستفسارات، وتحديث ملفات الفريق.
- الأمان: مكتب المحاماة يتعامل مع بيانات عملاء حساسة — الأمان لم يكن قابلاً للتنازل عنه.
- الأداء: أوقات تحميل أقل من ثانيتين، ودرجة Lighthouse لا تقل عن 90.
قرار اختيار التقنية
// الواجهة الأمامية
const frontend = {
framework: "React + Vite",
language: "TypeScript",
styling: "Tailwind CSS v4",
animation: "Framer Motion",
};
// الخادم
const backend = {
runtime: "Node.js",
framework: "Express.js",
auth: "JWT + bcrypt",
database: "MySQL (Supabase)",
monitoring: "Sentry",
};
اخترت Vite بدلاً من Next.js للواجهة الأمامية لأن الموقع لا يحتاج إلى SSR — كل البيانات الديناميكية تُجلب عبر API. هذا أبقى عملية البناء سريعة جداً.
المعمارية
يتبع النظام فصلاً نظيفاً بين المسؤوليات:
client/ → React SPA (Vite)
server/ → Express REST API
├── routes/ → /auth, /inquiries, /content, /admin
├── middleware/ → authMiddleware, rateLimiter, helmet
└── db/ → اتصال MySQL، الـ migrations
طبقات أمان الـ API
تم تطبيق الأمان على مستويات متعددة:
- Rate Limiting —
express-rate-limitعلى جميع النقاط العامة (10 طلبات/دقيقة عند إرسال الاستفسارات). - Helmet — رؤوس HTTP الأمنية جاهزة من البداية.
- التحقق من المدخلات — مخططات
zodللتحقق من كل جسم طلب. - JWT Rotation — رموز وصول قصيرة الأجل (15 دقيقة) مع تدوير رموز التحديث.
- Sentry — مراقبة الأخطاء مع تفعيل إخفاء البيانات الشخصية.
نظام الاستفسارات
كان أكثر الأجزاء تعقيداً هو بناء مسار استفسار القضية:
// server/routes/inquiries.ts
router.post("/submit", rateLimiter, validateBody(inquirySchema), async (req, res) => {
const { name, email, phone, caseType, description } = req.body;
// 1. حفظ في قاعدة البيانات
const inquiry = await db.inquiry.create({ data: req.body });
// 2. إرسال إشعار للفريق القانوني
await sendEmail({
to: process.env.LEGAL_TEAM_EMAIL,
subject: `استفسار ${caseType} جديد — ${inquiry.id}`,
template: "new-inquiry",
data: { name, caseType, inquiry },
});
// 3. إرسال تأكيد للعميل
await sendEmail({
to: email,
subject: "تم استلام استفسارك",
template: "inquiry-confirmation",
data: { name },
});
res.json({ success: true, inquiryId: inquiry.id });
});
هذا النمط — الحفظ ← إشعار الفريق ← تأكيد للعميل — تعامل مع كل شيء بشكل موثوق.
النتائج
بعد 4 أشهر من التطوير وأسبوعين من الاختبار:
| المقياس | النتيجة |
|---|---|
| أداء Lighthouse | 92 / 100 |
| وقت التحميل (3G) | أقل من 2.1 ثانية |
| الاستفسارات الشهرية المُدارة | 100+ |
| وقت التشغيل | 99.9% |
| رؤوس الأمان | A+ |
الدروس المستفادة
١. ابدأ بنموذج البيانات. كل خطأ واجهته في لوحة التحكم الإدارية نشأ عن مخطط غير محدد بشكل كافٍ. احصل على ذلك بشكل صحيح أولاً.
٢. موثوقية البريد الإلكتروني صعبة. مررت بثلاثة مزودي بريد إلكتروني قبل الاستقرار على واحد يوصل باستمرار دون الوقوع في مرشحات البريد المزعج.
٣. تجربة المستخدم ثنائية اللغة أكثر من مجرد RTL. المستخدمون العرب لا يحتاجون فقط إلى نص مقلوب — يتوقعون تسلسلاً هرمياً بصرياً مختلفاً، وأوزان خطوط مختلفة، وكثافة محتوى مختلفة. أشرك متحدثاً أصلياً في مراجعات التصميم.
٤. طبّق Rate Limiting بقوة. نموذج الاتصال في مكتب المحاماة هدف رئيسي للاستخراج والبريد المزعج. اشحن Rate Limiting من اليوم الأول.
الخلاصة
عزز هذا المشروع شيئاً أؤمن به بعمق: أفضل العمل الهندسي غير مرئي للمستخدم النهائي. لم يهتم العميل بتدوير JWT أو التحقق من المخطط — اهتموا بأن المنصة تعمل، وتبدو احترافية، وتساعدهم على خدمة عملائهم بشكل أفضل.
هذا هو الهدف الحقيقي.
شارك هذا المقال
يوسف محمود
Full-Stack Engineer & Project Engineer

