هندسة تطبيقات الويب: الأنماط الأساسية

معمارية تطبيقات الويب: دليل شامل

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

المعماريات الرئيسية

1. Monolithic Architecture (المعمارية المتكاملة)

كل شيء في تطبيق واحد: الـ frontend، backend، قاعدة البيانات.

myapp/
├── app/
│ ├── Http/Controllers/ # معالجة الطلبات
│ ├── Models/ # قاعدة البيانات
│ └── Services/ # منطق الأعمال
├── resources/views/ # HTML templates
└── database/ # Migrations

متى تختارها:

• مشاريع صغيرة ومتوسطة (حتى 100K مستخدم)
• فريق صغير (2-8 مطورين)
• Budget محدود
• تريد سرعة في التطوير

التكلفة على كلاود: VPS واحد، 6,900-أسعار تنافسية — الأسعار والباقات

2. Service-Oriented Architecture (SOA)

تقسيم التطبيق لخدمات كبيرة تتواصل عبر API.

Frontend App (React/Next.js)
 ↕
API Gateway
 ↕ ↕ ↕
User API Order API Payment API
 ↕
PostgreSQL

3. Microservices Architecture

كل خدمة مستقلة تماماً بقاعدة بياناتها.

Frontend → API Gateway → Services:
├── auth-service (JWT, OAuth)
├── user-service (CRUD, profiles)
├── order-service (ordering logic)
├── notification-service (email, SMS, WhatsApp)
├── payment-service (Noon integration)
└── report-service (analytics)

كل service له:
├── قاعدة بياناته الخاصة
├── Git repo مستقل
└── Docker container مستقل

متى تختارها:

• أكثر من 500K مستخدم نشط
• فريق كبير (20+ مطور) أو متعدد الفرق
• حاجة لـ deploy مستقل لكل خدمة

API Patterns

REST API (الأكثر شيوعاً)

// Laravel REST API
Route::apiResource('invoices', InvoiceController::class);

// يولد تلقائياً:
// GET /api/invoices → index
// POST /api/invoices → store
// GET /api/invoices/{id} → show
// PUT /api/invoices/{id} → update
// DELETE /api/invoices/{id} → destroy

GraphQL (للتطبيقات المعقدة)

# استعلام واحد يجلب بيانات متعددة بدون over-fetching
query GetUserWithInvoices($userId: ID!) {
 user(id: $userId) {
 name
 email
 invoices(status: "unpaid") {
 id
 amount
 dueDate
 }
 }
}

قواعد البيانات وأنماطها

CQRS (Command Query Responsibility Segregation)

الكتابة (Commands):
├── createInvoice
├── updateInvoice
└── تذهب لـ Primary DB (كتابة)

القراءة (Queries):
├── getInvoice
├── listInvoices
└── تذهب لـ Read Replica (قراءة)

// تطبيق في Laravel
// Command Handler
class CreateInvoiceHandler
{
 public function handle(CreateInvoiceCommand $command): Invoice
 {
 // يكتب في Primary DB
 return DB::connection('mysql_write')->table('invoices')->insert([...]);
 }
}

// Query Handler
class GetInvoiceQuery
{
 public function execute(int $id): Invoice
 {
 // يقرأ من Read Replica
 return DB::connection('mysql_read')->table('invoices')->find($id);
 }
}

Event-Driven Architecture

// عند وقوع حدث مهم
// OrderPaid.php
class OrderPaid implements ShouldBroadcast
{
 public $order;
 
 public function broadcastOn: array
 {
 return [new Channel('orders.' . $this->order->id)];
 }
}

// في Controller
event(new OrderPaid($order));

// Listeners مستقلة تستجيب للحدث
class SendInvoiceListener
{
 public function handle(OrderPaid $event): void
 {
 Mail::to($event->order->user)->send(new InvoiceEmail($event->order));
 }
}

class ActivateServiceListener
{
 public function handle(OrderPaid $event): void
 {
 ProvisioningService::activate($event->order->service);
 }
}

Cache Strategy

// Multi-layer caching
class ProductController
{
 public function show($id)
 {
 // Layer 1: Memory cache (fastest)
 return cache->remember("product:{$id}", 3600, function use ($id) {
 
 // Layer 2: Redis cache
 return redis->get("product:{$id}") ?? (function use ($id) {
 
 // Layer 3: Database (slowest)
 return Product::with('variants', 'reviews')->find($id);
 
 });
 });
 }
}

اختيار المعمارية المناسبة

سؤال 1: كم مطور في الفريق؟
├── 1-5: Monolith
├── 5-15: Modular Monolith أو SOA بسيطة
└── 15+: Microservices مقبولة

سؤال 2: كم مستخدم متوقع السنة الأولى؟
├── أقل من 50K: Monolith كافٍ
├── 50K-500K: قابل للتوسع مع Redis + Read Replica
└── 500K+: ابدأ التفكير في Microservices

سؤال 3: ما متطلبات الـ Compliance؟
├── حكومي/مالي: فصل بيانات صارم (SOA على الأقل)
└── عادي: Monolith مع تشفير البيانات

الخلاصة

ابدأ بـ Monolith. فكّر في التقسيم عند الحاجة الفعلية. سيرفر واحد على كلاود (cloud.net.sa) يكفي لـ 100K مستخدم مع معمارية صحيحة. الانتقال لـ SOA أو Microservices قرار مبني على نمو حقيقي، لا تخمين مستقبلي.

---

ابدأ الآن

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