أفضل ممارسات تصميم الـ APIs في 2026: REST و GraphQL و tRPC

"هل نستخدم REST ولا GraphQL؟" ده سؤال غلط من الأساس. بعد ما شحنت أكتر من 25 API على البرودكشن في سبع دول، أقدر أقولك إن أفضل ممارسات تصميم API في 2026 بتبدأ بسؤال تاني خالص: إيه طبيعة العلاقة بين المنتج للـ API والمستهلك له؟ لو ضبطت ده، الاختيار بين REST و GraphQL و tRPC و gRPC هيبقى واضح أوتوماتيكي. لو غلطت فيه، هتقضي السنتين الجايين تعتذر لفريقك ولعملائك.

أنا خالد أحمد، مطور ويب Full Stack سينيور مقيم في القاهرة. خلال الخمس سنين اللي فاتت صممت APIs لشركات فينتك في سويسرا، ومنصات رعاية صحية في ألمانيا، وأنظمة e-commerce في السعودية والإمارات، وبوابات حكومية في مصر، ومنتجات SaaS في بريطانيا وفرنسا والكويت. الأنماط اللي بتنجح متشابهة بشكل مفاجئ. والأخطاء اللي بتقتل المشاريع متشابهة أكتر. المقال ده هو دليل اللعب اللي كنت نفسي يكون معايا لما بدأت — رأي صريح، محدد، ومتجرب تحت ضغط إنتاج حقيقي.

إيه معنى "تصميم API" فعلياً في 2026 (وليه نقاش REST مقابل GraphQL خلص)

من عشر سنين، "تصميم API" كان معناه تختار endpoints وتكتب توثيق Swagger. في 2026 بقى معناه حاجة أكبر بكتير: تعريف العقد بين أنظمة ممكن تكون مملوكة لفرق مختلفة، مكتوبة بلغات مختلفة، منشورة على سحابات مختلفة، ومستهلكة من كلاينتس بتتراوح من تطبيق React Native لحد agent ذكاء اصطناعي بيعمل 4000 طلب في الدقيقة.

مبادئ تصميم API الحديثة اللي بتبعها في كل مشروع بتغطي ست اهتمامات ماكانتش موجودة في كتب 2015:

• أمان الأنواع من البداية للنهاية — أنواع الباك إند بتاعتك المفروض تتدفق للفرونت إند من غير تكرار يدوي.
• عقود تبدأ بالـ schema أو بالكود — مواصفة OpenAPI 3.1، أو GraphQL SDL، أو Protocol Buffers، مولّدة من الكود علشان ما تنحرفش أبداً.
• الـ Idempotency — أي عملية تعديل لازم تتعامل مع إعادة المحاولة بأمان، لأن الشبكات مش موثوقة وagents الذكاء الاصطناعي مش فاهمين معنى "اضغط مرة واحدة".
• القابلية للملاحظة — تتبع موزع، ولوجز منظمة، ومقاييس مدمجة في سطح الـ API، مش ملصوقة بعدين.
• الوعي بالتكلفة — لما agent ذكاء اصطناعي يقدر يبعت 1000 استعلام GraphQL قبل الغدا، بتحتاج persisted queries وحدود تعقيد.
• التوافق العكسي كميزة — استراتيجية تعيين الإصدارات بتاعتك قرار منتج، مش حاجة هندسية بتتحط بعدين.

صياغة "REST مقابل GraphQL مقابل tRPC" بتعاملهم كأنهم أديان متنافسة. مش كده. دي أدوات بتحل مشاكل مختلفة لمستهلكين مختلفين. بطّل تتخانق على مين "أحسن" وابدأ تسأل مين فعلياً هيستدعي الـ API بتاعك.

السؤال الوحيد المهم: مين بيستهلك الـ API بتاعك؟

كل قرار معماري بيتفرع من السؤال الواحد ده. بأخلي الفريق كله يجاوب عليه كتابياً قبل ما نرسم endpoint واحد:

1. أطراف ثالثة مش بتتحكم فيهم (مطورين، شركاء، مستخدمين عامين عندهم API keys) ← REST، دايماً. متوقعين endpoints صديقة للـ curl، ودلالات HTTP قياسية، وURLs ثابتة يقدروا يحفظوها.
2. فريق الفرونت إند الخاص بيك في نفس الشركة، بيشارك نموذج مجال معقد عبر كلاينتس ويب وموبايل وإدارة ← GraphQL غالباً هو الإجابة الصح.
3. فريقك بالكامل، كله TypeScript، كله في monorepo واحد ← tRPC هيشحن أسرع من أي حاجة تانية ويلقط البقات وقت compile.
4. microservices داخلية بتكلم بعضها بمعدل ضخم وبـ schemas صارمة ← gRPC مع Protocol Buffers.
5. agents الذكاء الاصطناعي وأدوات LLM ← REST مع وصف OpenAPI غني، لأن ده اللي نماذج استدعاء الأدوات بتستهلكه أصلاً في 2026.

التصنيف الواحد ده منع أخطاء معمارية أكتر من كل كتب "الكود النضيف" مجتمعة. شفت فرق اختارت GraphQL لأنه كان شكله موديرن وبعدين قضت 18 شهر تتقاتل مع الكاش والصلاحيات واستعلامات N+1 — في حين إن REST API مملة كانت هتشحن في تلات شهور.

REST في 2026: لسه الاختيار الافتراضي للـ APIs العامة وللأطراف الثالثة

REST عمره 26 سنة وبشكل أو بآخر لسه هو الاختيار الصح في أغلب الوقت. السبب: HTTP هو البروتوكول الوحيد اللي ممكن تفترض إن كل كلاينت وبروكسي وCDN ومتصفح وأداة بيفهموه من غير إعداد. ده ضخم. قابل للكاش بطبيعته، قابل للتصحيح بـ curl، قابل للمراقبة من كل أداة APM اتعملت في التاريخ.

للـ APIs العامة، وتكاملات الأطراف الثالثة، وأي API بيستهلكه طرف مش بتتحكم فيه — REST لسه هو الإجابة الصح. الشركات اللي حاولت تعمل "GraphQL لكل حاجة" للـ APIs العامة (Shopify, GitHub) فضلت تحافظ على REST APIs بتاعتها بشكل موازي بهدوء لأن عملاءها طلبوها. Stripe و Twilio و AWS — المعيار الذهبي لتجربة المطور — كلهم REST. الأنماط بتاعدك معنى.

لو الـ API بتاعك بيستهلكه ناس مش هتقدر تحضر مراجعة الكود بتاعتهم، اديلهم REST. أي حاجة تانية ضريبة على عملائك، وفي الآخر هيمشوا لبديل مش هيفرض عليهم الضريبة دي.

REST بشكل صحيح: الموارد، الأفعال، أكواد الحالة، وHATEOAS

"REST" بيتم استخدامه ليعني "أي JSON فوق HTTP"، بس REST الحقيقي عنده قواعد. ده إزاي تصمم REST API مش هيحرجك بعد سنتين:

• URLs مبنية على الموارد — /api/v1/users/123/orders، مش /api/getUserOrders?id=123. أسماء، مش أفعال.
• استخدم أفعال HTTP بشكل صحيح — GET (آمن، idempotent)، POST (إنشاء)، PUT (استبدال كامل، idempotent)، PATCH (تحديث جزئي)، DELETE (idempotent). لو DELETE بتاعك مش idempotent، عندك باج.
• رجّع أكواد حالة مناسبة — 200 للنجاح، 201 للإنشاء مع Location header، 204 للا محتوى، 400 لأخطاء التحقق، 401 للغير مصادق، 403 للغير مصرح، 404 للغير موجود، 409 للتعارضات، 422 للكيانات اللي ما تنفعش تتعالج، 429 لتحديد المعدل، 500 لأخطاء السيرفر. أي حاجة تانية بتحتاج تبرير.
• عيّن الإصدار من اليوم الأول — /api/v1/ في الـ URL مملة وبتشتغل. تعيين الإصدارات بـ headers أكاديمياً نقي وتشغيلياً مؤلم.
• الـ pagination والفلترة والترتيب عن طريق query params — ?page=2&per_page=50&sort=-created_at&filter[status]=active.
• headers تحديد المعدل — X-RateLimit-Limit، X-RateLimit-Remaining، X-RateLimit-Reset، وRetry-After على 429.
• HATEOAS لما يكون منطقي — رجّع روابط للموارد المرتبطة في الردود. HATEOAS النقي مبالغ فيه لأغلب التطبيقات، بس object اسمه _links بيشاور على الصفحات التالية/السابقة والموارد المرتبطة بيقلل اقتران الكلاينت.
• مفاتيح Idempotency على طلبات POST اللي بتنشئ موارد، علشان إعادة المحاولة ماتعملش خصم مزدوج من العملاء.

دي شكل endpoint POST مصمم كويس في Laravel — الفريمورك اللي بأستخدمه لأغلب شغل الباك إند:

// routes/api.php
Route::middleware(['auth:sanctum', 'throttle:60,1'])
    ->prefix('v1')
    ->group(function () {
        Route::post('orders', [OrderController::class, 'store']);
    });

// app/Http/Controllers/Api/V1/OrderController.php
public function store(StoreOrderRequest $request)
{
    $idempotencyKey = $request->header('Idempotency-Key');

    if ($idempotencyKey && $existing = Order::where('idempotency_key', $idempotencyKey)->first()) {
        return new OrderResource($existing);
    }

    $order = DB::transaction(function () use ($request, $idempotencyKey) {
        return Order::create([
            ...$request->validated(),
            'user_id' => $request->user()->id,
            'idempotency_key' => $idempotencyKey,
        ]);
    });

    return (new OrderResource($order))
        ->response()
        ->setStatusCode(201)
        ->header('Location', route('api.v1.orders.show', $order));
}

ده أقل من 30 سطر وبيغطي المصادقة، وتحديد المعدل، والتحقق، والـ idempotency، والتعاملات، وأكواد الحالة الصحيحة، وLocation header. ده الحد الأدنى. أي حاجة أقل من كده ناقصة.

ورقة سريعة لأكواد حالة HTTP (200, 201, 400, 401, 403, 404, 409, 422, 429, 500)

مش فاكر كام مراجعة كود سبت فيها كومنت "ده المفروض يكون 422، مش 400". أكواد الحالة مش تفضيلات جمالية — دي العقد اللي الكلاينتس بتعتمد عليه ليعرف يعمل إيه بعدين.

• 200 OK — GET أو PUT أو PATCH أو DELETE ناجح مع body في الرد.
• 201 Created — POST ناجح أنشأ مورد. ضمّن Location header.
• 202 Accepted — الطلب اتحط في طابور للمعالجة غير المتزامنة. رجّع URL للحالة.
• 204 No Content — DELETE ناجح من غير body، أو PUT/PATCH ناجح والكلاينت مش محتاج المورد المحدث.
• 301/302 — بس لتغييرات الـ URL. أبداً لتدفق API عادي.
• 400 Bad Request — JSON ملخبط، أو حقول مطلوبة ناقصة وقت parse. استخدم 422 لأخطاء التحقق التجارية.
• 401 Unauthorized — مصادقة ناقصة أو غير صالحة. المستخدم محتاج يسجل دخول.
• 403 Forbidden — مصادق بس مش مسموح. ماتسربش وجود المورد.
• 404 Not Found — المورد مش موجود، أو 403 متنكر كـ 404 لمنع التعداد.
• 409 Conflict — تعارض في الحالة، زي تكرار slug أو إصدار قفل تفاؤلي قديم.
• 410 Gone — مورد اتشال بشكل متعمد. استخدمه لما تحذف endpoint مهجور في إصدار مستقبلي.
• 422 Unprocessable Entity — صياغة صحيحة بس قواعد العمل رفضتها. أغلب أخطاء التحقق بتعيش هنا.
• 429 Too Many Requests — اتحدد المعدل. دايماً ضمّن Retry-After.
• 500 Internal Server Error — exception مش متعالج. ده المفروض يعمل page للـ on-call بتاعك.
• 503 Service Unavailable — صيانة مخططة أو حمل زائد مؤقت. ضمّن Retry-After.

أنماط الـ Pagination: offset مقابل cursor مقابل keyset (مع قياسات)

دي الغلطة الأكتر شيوعاً اللي بأشوفها في مراجعات الكود: LIMIT 50 OFFSET 100000. على جدول فيه 10 ملايين صف الاستعلام ده بياخد 2.4 ثانية في PostgreSQL لأن قاعدة البيانات مضطرة تمسح 100,050 صف علشان ترمي 100,000. الـ cursor pagination على نفس الجدول بتشتغل في 3 ميلي ثانية. ده تسريع 800 ضعف من ريفاكتور يوم واحد.

دي امتى تستخدم كل واحد:

• Offset pagination (?page=2&per_page=50) — كويسة لمجموعات بيانات صغيرة (أقل من 10,000 صف) وجداول إدارة فيها المستخدمين بيقفزوا للصفحة 47. سهلة التنفيذ، سهلة الفهم، بطيئة على المقياس الكبير.
• Cursor pagination (?cursor=eyJpZCI6MTIzfQ&limit=50) — الافتراضي الصح لأي endpoint شبه فيد. بيرمّز آخر مفتاح ترتيب مرئي كـ cursor base64 مبهم. ثابت لما عناصر جديدة تتضاف، سريع على أي مقياس.
• Keyset pagination (?after_id=12345&limit=50) — cursor pagination بمفتاح شفاف. استخدمها لما المستهلكين يستفيدوا من تكوين الـ URL التالي يدوياً.

ده تنفيذ cursor pagination بأستخدمه في البرودكشن لمنصة e-commerce بتخدم 80,000 مستخدم يومي:

// app/Services/CursorPaginator.php
public function paginate(Builder $query, ?string $cursor, int $limit = 50): array
{
    $decoded = $cursor ? json_decode(base64_decode($cursor), true) : null;

    if ($decoded) {
        $query->where(function ($q) use ($decoded) {
            $q->where('created_at', '<', $decoded['created_at'])
              ->orWhere(function ($q2) use ($decoded) {
                  $q2->where('created_at', '=', $decoded['created_at'])
                     ->where('id', '<', $decoded['id']);
              });
        });
    }

    $items = $query->orderByDesc('created_at')
                   ->orderByDesc('id')
                   ->limit($limit + 1)
                   ->get();

    $hasMore = $items->count() > $limit;
    $items = $items->take($limit);

    $nextCursor = $hasMore ? base64_encode(json_encode([
        'created_at' => $items->last()->created_at->toIso8601String(),
        'id' => $items->last()->id,
    ])) : null;

    return ['data' => $items, 'next_cursor' => $nextCursor];
}

كاسر التعادل على id مهم — من غيره، صفين بنفس الـ timestamp بيخلوا الـ paginator يفوّت عناصر. صححت الباج ده بالظبط تلات مرات في تلات شركات مختلفة.

GraphQL في 2026: لما schema واحدة بتغلب خمسين endpoint

GraphQL بيلمع لما الفرونت إند والباك إند مملوكين لنفس المنظمة والفرونت إند عنده احتياجات بيانات متنوعة — تطبيق موبايل، وتطبيق ويب، ولوحة إدارة، كلهم بيضربوا على نفس الـ API. بيقضي على الجلب الزائد، بيقضي على الجلب الناقص، وبيخلي فرق المنتج تتحرك من غير تنسيق باك إند لكل شاشة جديدة.

شحنت GraphQL بنجاح على تلات مشاريع:

• منصة عقارية في دبي حيث نفس بيانات العقارات بتغذي صفحة بحث عامة، ولوحة تحكم لمستخدمين مسجلين دخول، وCMS داخلية — كل واحدة محتاجة حقول مختلفة.
• لوحة لوجستيات في ألمانيا حيث شاشات الإدارة بتركّب بيانات من خمس microservices ورا بوابة Apollo Federation واحدة.
• أداة إدارة داخلية في القاهرة حيث فريق المنتج عاوز يبني شاشات من غير ما يستنى تذكرة باك إند على كل حقل جديد.

امتى ما تستخدمش GraphQL: الـ API بيستهلكه أطراف ثالثة، الكاش حرج، فريقك ما استخدمهوش قبل كده، أو بياناتك تعاملية أكتر منها شبه رسم. التعقيد التشغيلي حقيقي ومستهان بيه. الصلاحيات على مستوى الحقل أصعب من الصلاحيات على مستوى المسار. تحديد المعدل بيبقى تحليل تعقيد استعلام. المراقبة بتبقى تتبع عبر الـ resolvers بدل مسارات HTTP.

عثرات GraphQL: استعلامات N+1، كوابيس الكاش، وأساطير الجلب الزائد

كل مشروع GraphQL ورّثته كان عنده على الأقل تلاتة من المشاكل دي:

1. استعلامات N+1 في كل مكان — resolvers شكلها بريء (posts -> author) بتشغّل فعلياً استعلام SQL لكل بوست. الحل: DataLoader على كل علاقة. مش اختياري.
2. ما فيش حدود عمق أو تعقيد للاستعلام — كلاينت خبيث بيبعت users { friends { friends { friends { ... } } } } وبيركع قاعدة البيانات. الحل: تقييم تعقيد بسقف صارم (بأستخدم 1000 كخط أساس).
3. الصلاحيات مبعترة عبر الـ resolvers — كل resolver بيعيد فحص "هل المستخدم ده يقدر يشوف الحقل ده؟" الحل: طبقة سياسة مركزية، أو استخدم schema directives بتاعت Apollo.
4. كاش HTTP متخلى عنه — كل حاجة POST، فكاش CDN ميت. الحل: persisted queries مع طلبات GET للاستعلامات اللي ينفع تتكاش.
5. فوضى الإصدارات — "GraphQL مش محتاج إصدارات" دي الكدبة اللي بتنتج أنواع بـ 80 حقل فيها 40 حقل مهجور محدش بيجرؤ يشيلهم. الحل: استخدم @deprecated فعلاً وشغّل تحليلات استخدام علشان تعرف امتى الحقول آمنة للحذف.

ادعاء "GraphQL بيقضي على الجلب الزائد" صحيح تقنياً بس مضلل عملياً. من تجربتي، الوفر الأكبر بييجي من القضاء على الجلب الناقص — تجميع ست جولات ذهاب وعودة في واحدة. تقليل الجلب الزائد هامشي لأن أغلب الحقول رخيصة في التسلسل أصلاً.

Apollo Federation مقابل schema stitching مقابل GraphQL أحادي

تلات طرق لتوسيع GraphQL API عبر الفرق. ده تقييمي الصريح بعد استخدامي للتلاتة في البرودكشن:

• GraphQL أحادي — schema واحدة، سيرفر واحد، نشر واحد. ممل وصحيح لفرق تحت 30 مهندس. ما تبالغش في الهندسة.
• Apollo Federation v2 — subgraphs متعددة مركّبة من gateway. الاختيار الصح لما يكون عندك فرق باك إند متعددة بتمتلك مجالات مختلفة. أدوات قوية، تكلفة تشغيلية حقيقية (الـ gateway بقى نقطة فشل واحدة في المسار الحرج لازم يتوسع لـ 100% من الترافيك).
• Schema stitching — الطريقة القديمة. تجنبها. استخدم Federation v2 بدلها.

اخترت Federation لمشروع اللوجستيات لأنه كان عندنا خمس فرق باك إند بالفعل. ما كنتش هاختاره لفريق واحد — الـ gateway بيضيف 15 ميلي ثانية تأخير وقابل للنشر جديد كامل محتاج SLO خاص بيه. تصميم قاعدة بيانات كويس أهم من توبولوجي GraphQL بتاعتك للأداء.

tRPC: أمان أنواع من البداية للنهاية لمشاريع TypeScript الموحدة

لو الطرفين TypeScript — Next.js قدام، Node ورا، ريبو واحد — tRPC بيديك أمان أنواع من البداية للنهاية بصفر تكرار schema. ما فيش توليد كود، ما فيش ملفات schema، ما فيش خطوة مزامنة. الفرونت إند بتاعك بيكمل أنواع الباك إند تلقائياً لأنها حرفياً أنواع الباك إند.

استخدمت tRPC في خمس مشاريع في الـ 18 شهر اللي فاتت، كلها منتجات SaaS من الصفر في إيكوسيستم Next.js. سرعة البناء بتعلى بحوالي 30% لأن ما فيش انحراف عقد، ما فيش أنواع TypeScript يدوية لردود API، وما فيش مجموعة Postman للصيانة. الريفاكتور آمن فعلاً — غيّر اسم حقل على السيرفر والفرونت إند هيوقف يكومبايل لحد ما تصلحه.

راوتر tRPC نموذجي شكله كده:

// server/routers/orders.ts
import { z } from 'zod';
import { protectedProcedure, router } from '../trpc';

export const ordersRouter = router({
  list: protectedProcedure
    .input(z.object({
      cursor: z.string().nullish(),
      limit: z.number().min(1).max(100).default(50),
    }))
    .query(async ({ ctx, input }) => {
      const items = await ctx.db.order.findMany({
        where: { userId: ctx.user.id },
        take: input.limit + 1,
        cursor: input.cursor ? { id: input.cursor } : undefined,
        orderBy: { createdAt: 'desc' },
      });

      const nextCursor = items.length > input.limit ? items.pop()!.id : null;
      return { items, nextCursor };
    }),

  create: protectedProcedure
    .input(z.object({
      productId: z.string().uuid(),
      quantity: z.number().int().positive(),
    }))
    .mutation(async ({ ctx, input }) => {
      return ctx.db.order.create({
        data: { ...input, userId: ctx.user.id },
      });
    }),
});

على الفرونت إند:

// app/orders/page.tsx
'use client';
import { trpc } from '@/lib/trpc';

export default function OrdersPage() {
  const { data, fetchNextPage, hasNextPage } = trpc.orders.list.useInfiniteQuery(
    { limit: 50 },
    { getNextPageParam: (last) => last.nextCursor }
  );

  // data.pages is fully typed. No types file. No codegen.
  return (...);
}

تحقق Zod schema بيشتغل على الحدود، ونوع رجوع Prisma بيتدفق للفرونت إند، وتكامل React Query بيتعامل مع الكاش وإعادة الجلب. ده شكل تطوير الباك إند في 2026 لما تتحكم في الطرفين. لو بتـبني MVP لـ SaaS بفريق صغير، tRPC غالباً هو أسرع طريق للإنتاج.

امتى ما تستخدمش tRPC: APIs عامة (ما فيش schema قياسية للمستهلكين الخارجيين)، باك إند متعدد اللغات (مصمم TypeScript بس)، أو لما تتوقع إن الباك إند هيتعاد كتابته بلغة تانية. tRPC مضاعف إنتاجية للحالة المحددة اللي اتصمم عشانها — ما تمطّطوش.

tRPC مقابل GraphQL مقابل REST: مقارنة جنباً إلى جنب

دي المقارنة اللي بأشاركها مع العملاء وهم بيقرروا الستاك بتاعهم. هاسردها كقائمة منظمة لأن النية الأصلية للـ "جدول" أهم من الشكل البصري:

• REST — أمان الأنواع: يدوي عبر مولّدات OpenAPI. الكاش: HTTP أصلي. الأدوات: عالمية. API عام: نعم. منحنى التعلم: منخفض. الأفضل لـ: APIs الأطراف الثالثة، SDKs الموبايل، أدوات agents الذكاء الاصطناعي.
• GraphQL — أمان الأنواع: مبني على schema مع codegen. الكاش: من جهة الكلاينت عبر Apollo/Relay، ما فيش كاش HTTP. الأدوات: ممتازة (GraphiQL, Apollo Studio). API عام: تقنياً نعم، عملياً مؤلم. منحنى التعلم: متوسط-عالي. الأفضل لـ: فرونت إند كبيرة باحتياجات بيانات متنوعة، microservices اتحادية.
• tRPC — أمان الأنواع: من البداية للنهاية تلقائي. الكاش: تكامل React Query. الأدوات: أصلية TypeScript، ما فيش IDE منفصلة محتاجة. API عام: لا. منحنى التعلم: منخفض لو بتعرف TypeScript. الأفضل لـ: TypeScript monorepos، APIs داخلية، تكرار سريع.
• gRPC — أمان الأنواع: Protocol Buffers مولّدة. الكاش: محدود (بروتوكول ثنائي). الأدوات: قوية للباك إند، ضعيفة للمتصفحات. API عام: نادر، بيستخدمه مشاريع شبه Google/etcd. منحنى التعلم: عالي. الأفضل لـ: ترافيك microservice لـ microservice داخلي، بث ثنائي الاتجاه في الوقت الفعلي.

gRPC و Protocol Buffers: لما البروتوكولات الثنائية بتكسب

gRPC و Protocol Buffers بيكسبوا مكانهم في حالتين محددتين: تواصل microservice داخلي بمعدل ضخم، وبث ثنائي الاتجاه حيث WebSockets بتبقى محسوس إنها غير محددة كفاية. التسلسل الثنائي حوالي 5-7 مرات أصغر من JSON و3-4 مرات أسرع في الـ parse. لخدمة طلبات بتستوعب 50,000 حدث في الثانية من خدمة دفع، ده مهم.

اللي اتعلمته عن gRPC بعد نشره على مشروع فينتك سويسري:

• قصة دعم المتصفح لسه مفوضضة. gRPC-Web بتشتغل بس بتحتاج بروكسي. للـ APIs اللي بتواجه المتصفح، فضل مع REST أو GraphQL.
• ملف الـ proto بيبقى أداة مشاركة حرجة. عامله زي حزمة معينة الإصدار، مش ملف بتعمله check in في كل خدمة.
• المواعيد النهائية وانتشار الإلغاء من الدرجة الأولى. دي منطقة gRPC بتكسب فيها فعلياً على HTTP.
• القابلية للملاحظة بتحتاج أدوات بتفهم gRPC. أغلب منتجات APM بتتعامل معاها دلوقتي، بس تأكد قبل ما تلتزم.

APIs الوقت الفعلي: WebSockets و Server-Sent Events واشتراكات GraphQL

"الوقت الفعلي" بيعني تلات حاجات مختلفة في 2026، واختيار الواحدة الغلط بيضيع أسابيع:

1. Server-Sent Events (SSE) — السيرفر بيدفع أحداث للكلاينت عبر HTTP عادي. اتجاه واحد، بسيط، بيشتغل عبر كل بروكسي. استخدمه للإشعارات، الداشبوردات الحية، ردود بث الذكاء الاصطناعي. ده اللي تأثيرات كتابة شبه ChatGPT بتستخدمه.
2. WebSockets — اتصال مستمر ثنائي الاتجاه. استخدمه للشات، التحرير التعاوني، ألعاب الـ multiplayer. تعقيد تشغيلي أكبر (sticky sessions، منطق إعادة الاتصال، اعتبارات التوسيع).
3. اشتراكات GraphQL — عادة WebSockets تحت الكابوت، مع schema. استخدمها لما تكون أصلاً على GraphQL وعاوز الاتساق.
4. Long polling — ارجع ليها لما WebSockets وSSE اتحجبوا بواسطة بروكسيات الشركات. لسه موجودة. لسه شغالة.
5. HTTP/2 server push — فعلياً مهجور. ما تصممش حواليه.

افتراضي في 2026 هو SSE لبث من السيرفر للكلاينت وWebSockets بس لما الترافيك ثنائي الاتجاه يكون محتاج فعلياً. SSE مستهان بيها إجرامياً — بتحل 80% من متطلبات "الوقت الفعلي" بـ 20% من تعقيد WebSockets.

شجرة القرار: اختيار REST أو GraphQL أو tRPC أو gRPC في 5 أسئلة

دي شجرة قرار تصميم API اللي بأمشي بيها كل عميل:

1. هل الـ API ده بيستهلكه أطراف مش بتتحكم فيها؟ ← REST. توقف هنا.
2. هل الباك إند والفرونت إند بتاعك التنين TypeScript في monorepo واحد؟ ← tRPC. اشحن أسرع من البدائل.
3. هل عندك كلاينتس فرونت إند متعددين (ويب، موبايل، إدارة) بيضربوا على نفس رسم البيانات، كلهم مملوكين لفريقك؟ ← GraphQL.
4. هل ده ترافيك microservice لـ microservice داخلي بمعدل ضخم؟ ← gRPC.
5. هل محتاج وقت فعلي؟ ← ضيف SSE أو WebSockets فوق اللي اخترته في 1-4.

كده. خمس أسئلة، إجابات قابلة للدفاع. الغلطة اللي بأشوفها أكتر هي إن الفرق بتتخطى السؤال الأول وتختار GraphQL لـ API عام لأن شكله موديرن. وبعدين بتقضي سنتين تعيد بناء REST endpoints لأن العملاء طلبوها. ما تكونش الفريق ده.

المصادقة والصلاحيات: JWT و sessions و OAuth 2.1 و API keys

أفضل ممارسات مصادقة API في 2026 بتتقسم حسب حالة الاستخدام:

• تطبيقات ويب من الطرف الأول — session cookies مع HttpOnly و Secure و SameSite=Lax. مملة وصحيحة. JWT في localStorage غلطة أمنية الناس بتفضل تعملها لأن الدروس علمتهم غلط.
• تطبيقات موبايل وSPAs — رموز JWT access قصيرة العمر (15 دقيقة) مع رموز refresh مخزنة في تخزين آمن. دوّر رموز refresh عند الاستخدام.
• تكاملات الأطراف الثالثة (APIs المطورين) — API keys بـ scopes. اعرض مرة واحدة، اعمل hash في قاعدة البيانات، اسمح بحدود معدل لكل مفتاح وإلغاء.
• سيرفر لسيرفر — mTLS أو JWTs موقعة بـ TTL قصير. API keys بتشتغل كمان بس أصعب في التدوير.
• وصول مفوض من المستخدم (مستخدميك بيسمحوا لتطبيق تاني يوصل لبياناتهم) — OAuth 2.1 مع PKCE. تدفق PKCE بقى إلزامي لكل الكلاينتس في OAuth 2.1، مش بس العامة.

نقاش JWT مقابل session cookies اتحسم لحد كبير: كوكيز للكلاينتس المتصفح، JWT لكل حاجة تانية. الكوكيز بتديك حماية CSRF عبر SameSite، تعامل متصفح تلقائي، وانتهاء صلاحية مدمج. JWT بيديك اللاحالة، اللي مهم لما سيرفر المصادقة بتاعك والـ API بتاعك خدمات مختلفة. اختار على أساس المعمارية، مش الجماليات. اقرا قائمة فحص أمان الموقع بتاعتي للصورة الأشمل.

استراتيجيات تحديد المعدل: token bucket، sliding window، وتنفيذ Redis

كل API بيواجه الجمهور محتاج تحديد معدل، وقفة كاملة. السؤال خوارزمية إيه:

• Fixed window — عد الطلبات في الدقيقة، إعادة تعيين على الدقيقة. بسيط، بس بيسمح بدفعة 2x على حدود النافذة. مش موصى بيه.
• Sliding window log — تخزين timestamp لكل طلب، عد اللي في آخر N ثانية. دقيق بس جوعان للذاكرة.
• Sliding window counter — متوسط مرجح للنافذة الحالية والسابقة. أرضية وسط كويسة. ده اللي Cloudflare بتستخدمه.
• Token bucket — تجديد الرموز بمعدل ثابت، الطلبات بتستهلك الرموز. بيسمح بدفعات متحكم فيها. افتراضي بتاعي لأغلب الـ APIs.

ده تنفيذ token bucket مدعوم بـ Redis في PHP بأستخدمه عبر مشاريع Laravel متعددة:

// app/Services/RateLimiter.php
public function consume(string $key, int $capacity, int $refillPerSecond): bool
{
    $now = microtime(true);
    $lua = <<<LUA
local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local refill = tonumber(ARGV[2])
local now = tonumber(ARGV[3])

local bucket = redis.call('HMGET', key, 'tokens', 'last')
local tokens = tonumber(bucket[1]) or capacity
local last = tonumber(bucket[2]) or now

local elapsed = now - last
tokens = math.min(capacity, tokens + elapsed * refill)

if tokens < 1 then
  redis.call('HMSET', key, 'tokens', tokens, 'last', now)
  redis.call('EXPIRE', key, 3600)
  return 0
end

tokens = tokens - 1
redis.call('HMSET', key, 'tokens', tokens, 'last', now)
redis.call('EXPIRE', key, 3600)
return 1
LUA;

    return (bool) Redis::eval($lua, 1, "rl:{$key}", $capacity, $refillPerSecond, $now);
}

سكريبت Lua بيخلي القراءة-التعديل-الكتابة ذرية، اللي مهم في التزامن العالي. تنفيذ PHP ساذج كان هيكون عنده race condition بيسمح بـ 2-3x حد المعدل تحت الحمل. تعلمت ده بالطريقة الصعبة في تخفيضات Black Friday اللي عملت DDoS لقاعدة بياناتنا.

تعيين إصدارات APIs من غير ما تكسر الكلاينتس: URL، header، وتفاوض المحتوى

استراتيجية تعيين إصدارات الـ API بتاعتك وعد للعملاء. غلط فيها ومش هتقدر تصلحها من غير ما تكسرهم. تلات طرق:

• تعيين إصدار بالـ URL (/api/v1/users) — مملة، مرئية، سهل التوجيه في load balancers. افتراضي بتاعي للـ APIs العامة.
• تعيين إصدار بالـ header (Accept: application/vnd.myapi.v2+json) — URLs نضيفة، أصعب في curl، أصعب في الكاش. نظرياً نقي، عملياً مزعج.
• تعيين إصدار مبني على التاريخ (Stripe-Version: 2024-06-20) — أسلوب Stripe. ممتاز للـ APIs اللي بتتطور باستمرار من غير إعادة تصميم كبيرة. العملاء بيثبتوا على تاريخ ويهاجروا حسب جدولهم.

قواعد بأتبعها:

1. عيّن الإصدار من اليوم الأول، حتى على v1. إضافة تعيين إصدار بعدين تغيير كاسر للعملاء في حد ذاته.
2. التغييرات الإضافية (حقول اختيارية جديدة، endpoints جديدة) مش بتحتاج رفع إصدار.
3. التغييرات الكاسرة (حذف حقول، تغيير أنواع، تغيير دلالات) بتحتاج إصدار جديد.
4. ادعم الإصدارات القديمة لـ 12 شهر على الأقل بعد الإهمال. سنتين للعملاء المدفوعين.
5. headers الـ Sunset (Sunset: Sat, 31 Dec 2026 23:59:59 GMT) بتخلي الكلاينتس يعرفوا امتى endpoint هيختفي.

التعامل مع الأخطاء بـ RFC 7807 problem+json

تفاصيل المشكلة في RFC 7807 هو المعيار للأخطاء المنظمة في API، وتقريباً محدش بيستخدمه. المفروض يستخدموه. ده شكل رد خطأ صحيح:

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/problem+json

{
  "type": "https://api.example.com/problems/validation-failed",
  "title": "Your request parameters did not validate",
  "status": 422,
  "detail": "The 'email' field is required and 'age' must be between 18 and 120",
  "instance": "/api/v1/users",
  "errors": [
    {
      "field": "email",
      "rule": "required",
      "message": "The email field is required"
    },
    {
      "field": "age",
      "rule": "between",
      "message": "The age must be between 18 and 120"
    }
  ],
  "trace_id": "01HXYZ123ABCDEF456GH"
}

الـ URL في type هي الميزة القاتلة — تقدر تربط لتوثيق بيشرح فئة الخطأ. trace_id بتخلي العميل يشاور على فشل محدد لما يبعت إيميل للدعم، وتقدر تجيب الطلب بالظبط من اللوجز بتاعتك. التصحيح الكويس بيبدأ بردود أخطاء كويسة.

توثيق API: توليد OpenAPI من الكود (Laravel و NestJS و FastAPI)

مواصفة OpenAPI في 2026 (3.1 هو الإصدار الحالي، أخيراً متسق مع JSON Schema) هو المعيار الفعلي لتوثيق REST APIs. القاعدة اللي بأفرضها على كل فريق: مواصفة OpenAPI بتاعتك لازم تتولد من الكود، أبداً ما تتكتبش بالإيد. المواصفات المكتوبة باليد دايماً بتنحرف عن الواقع. المواصفات المولّدة ما تقدرش تكدب.

حسب الفريمورك:

• Laravel — Scramble (أحدث، صفر إعداد) أو L5-Swagger (أنضج، بيحتاج annotations). بأستخدم Scramble على المشاريع الجديدة لأنه بيستنتج أغلب الحاجات من تلميحات الأنواع و form requests.
• NestJS — @nestjs/swagger مدمج، مولّد من DTOs والـ decorators بتاعتك. أفضل تجربة مطور في إيكوسيستم Node.
• FastAPI — توليد OpenAPI هو السلوك الافتراضي. ده ليه FastAPI أكلت غدا Flask في Python.
• Express — استخدم express-openapi-validator لو عاوز spec-first، أو هاجر لـ tRPC لو TypeScript-only.

من مواصفة OpenAPI، تقدر تولّد SDKs للكلاينت في 30+ لغة، مجموعات Postman، سيرفرات mock، واختبارات عقد. ده رفع ضخم من مصدر حقيقة واحد. مواصفة JSON:API بديل لـ REST برأي محدد، بس OpenAPI هي اللغة المشتركة.

تشديد الأمان: CORS و CSRF والتحقق من المدخلات وOWASP API Top 10

OWASP API Top 10 بتقرا زي اعتراف لكل API دققت فيه. أعلى تلاتة قتلة في 2026:

1. تفويض مستوى الكائن المكسور (BOLA) — endpoint بيرجّع /api/v1/orders/123 من غير ما يفحص إن طلب 123 خاص بالمستخدم المصادق. دي الثغرة رقم 1 في APIs الإنتاج. اختبر كل endpoint مصادق بـ ID مستخدم غلط.
2. مصادقة مكسورة — ما فيش حد معدل على تسجيل الدخول، ما فيش MFA، أسرار JWT في الكود المصدري، session IDs قابلة للتنبؤ. مشاكل مملة لسه بتسبب اختراقات.
3. تعرض بيانات زائد — نموذج User بتاعك بيسلسل password_hash، internal_notes، وstripe_customer_id لأن حد رجّع $user->toArray(). استخدم فئات Resource/DTO صريحة دايماً.

أساسيات تانية:

• CORS — قائمة سماح صريحة للأصول، أبداً Access-Control-Allow-Origin: * على APIs مصادقة.
• CSRF — مطلوب للمصادقة المبنية على كوكيز. مش مطلوب للمصادقة المبنية على رموز في Authorization headers.
• التحقق من المدخلات — Zod، Joi، form requests في Laravel، نماذج Pydantic في FastAPI. اتحقق على الحدود، اوثق داخلياً.
• ترميز المخرجات — حدد Content-Type صراحة، حدد X-Content-Type-Options: nosniff.
• headers الأمان — HSTS، CSP، X-Frame-Options. شوف قائمة فحص الأمان الكاملة بتاعتي للقائمة الكاملة.

الأداء: طبقات الكاش، تكامل CDN، وضغط الردود

أداء API بيعيش أو بيموت في أربع طبقات:

1. قاعدة البيانات — الفهارس، خطط الاستعلام، تجمع الاتصالات. تصميم قاعدة البيانات فوق أداء API.
2. كاش التطبيق — Redis للبيانات الساخنة، مع إلغاء صريح. اعمل كاش لنتائج SQL، مش رد JSON.
3. كاش HTTP — headers ETag وLast-Modified، Cache-Control مع stale-while-revalidate. بتخلي CDNs والمتصفحات تشتغل ليك.
4. CDN — Cloudflare، Fastly، Bunny. اعمل كاش لردود GET على الحافة للـ endpoints اللي بتسمح بكده.

ضغط الردود: فعّل Brotli لكل حاجة. Brotli 4 بيديك 90% من الضغط بـ 30% من تكلفة الـ CPU مقارنة بـ Brotli 11. أغلب منصات السحابة بتفعّله تلقائياً؛ تأكد بـ curl -H "Accept-Encoding: br" -I.

مثال كاش ETag لـ API بـ Laravel:

// app/Http/Middleware/EtagMiddleware.php
public function handle($request, Closure $next)
{
    $response = $next($request);

    if ($request->isMethod('GET') && $response->getStatusCode() === 200) {
        $etag = '"' . md5($response->getContent()) . '"';
        $response->header('ETag', $etag);
        $response->header('Cache-Control', 'private, max-age=60, stale-while-revalidate=300');

        if ($request->header('If-None-Match') === $etag) {
            return response('', 304)->header('ETag', $etag);
        }
    }

    return $response;
}

رد 304 Not Modified حوالي 200 بايت مقابل رد JSON نموذجي 50KB. على endpoint فيد بيتضرب مليون مرة في اليوم، ده 50 GB من النطاق الترددي توفر. مش نظري — متقاس على منصة الـ e-commerce اللي ذكرتها قبل كده.

أخطاء تصميم API الشائعة اللي بأشوفها في مراجعات الكود (وإزاي تصلحها)

أنماط بأشاور عليها في كل مراجعة كود تقريباً:

• أفعال في URLs — /api/createUser بدل POST لـ /api/users. الحل: استخدم أفعال HTTP.
• 200 OK لكل حاجة — بما فيها الأخطاء، مع حقل success: false. الحل: استخدم أكواد حالة HTTP صح.
• إرجاع أسماء أعمدة قاعدة البيانات — user_id، created_at_utc، is_deleted_flag. الحل: طبقة Resource/Serializer صريحة.
• ما فيش pagination على endpoints القوائم — بتشتغل في اليوم الأول، بتموت عند 10,000 صف. الحل: cursor pagination من البداية.
• endpoints GET بتعدل — GET /api/orders/123/complete. الحل: POST لـ /api/orders/123/completions.
• endpoints مركبة ضخمة — POST /api/process بتعمل سبع حاجات مختلفة على حسب حقل type. الحل: endpoints منفصلة، أو روح GraphQL.
• كلمات سر بنص عادي في لوجز الطلبات — أه، لسه. الحل: نضّف الحقول الحساسة في middleware اللوجينج.
• ما فيش انتشار request ID — التصحيح بيحتاج grep عبر 12 خدمة. الحل: header X-Request-Id مولّد عند الـ gateway، منتشر عبر كل استدعاء داخلي.
• تسمية حقول غير متسقة — userId في endpoint، user_id في تاني. الحل: قاعدة linter على مواصفة OpenAPI.
• المناطق الزمنية في توقيت محلي — دايماً رجّع ISO 8601 بإزاحة UTC صريحة (2026-06-20T15:30:00Z).

مستقبل الـ APIs: AsyncAPI، المعمارية المدفوعة بالأحداث، وendpoints agents الذكاء الاصطناعي

اللي جاي في الـ 24 شهر الجايين اللي المفروض تخطط ليه:

• AsyncAPI — معادل OpenAPI للأنظمة المدفوعة بالأحداث (Kafka، RabbitMQ، MQTT). لو بتنشر أحداث، وثقها بـ AsyncAPI 3.0.
• endpoints agents الذكاء الاصطناعي — الـ API بتاعك بشكل متزايد بيستدعيه استخدام أداة LLM، مش بشر. أوصاف OpenAPI غنية، مفاتيح idempotency، ورسايل خطأ واضحة بقت أهم من قبل. الـ agent محتاج يستعيد من الأخطاء من غير تدخل بشري.
• Model Context Protocol (MCP) — معيار Anthropic للتواصل من الذكاء الاصطناعي للأداة. يستاهل تتبعه لو منتجك هيستهلكه مساعدات ذكاء اصطناعي.
• HTTP/3 و QUIC — بالفعل عند حوالي 30% من ترافيك الإنترنت. تأكد إن الـ CDN وload balancer بتاعك بيدعموهم.
• الحوسبة على الحافة — gateway الـ API بتاعك بشكل متزايد Cloudflare Worker أو Vercel Edge Function، مش pod Kubernetes. ده بيدفع المصادقة وتحديد المعدل للحافة.
• Webhooks بشكل صح — payloads موقعة، إعادة محاولة بـ exponential backoff، idempotency، endpoints لإعادة التشغيل. Stripe التنفيذ المرجعي.

لو بتبني للخمس سنين الجايين، صمم سطح API بتاعك على أساس إن نصف الترافيك بتاعك في الآخر هيكون من agents مؤتمتة — بما فيهم اللي مش بتتحكم فيهم. ده بيغير قد إيه بتاخد تحديد المعدل والـ idempotency ورسايل الخطأ بجدية.

الأسئلة الشائعة عن أفضل ممارسات تصميم API في 2026

هل REST مات في 2026؟

لا، ومش هيموت في المستقبل المنظور. REST لسه الاختيار الصح لـ APIs العامة، وتكاملات الأطراف الثالثة، وSDKs الموبايل، وأي سياق محتاج فيه أقصى توافق مع الإيكوسيستم الموجود لأدوات HTTP. الجدال مش REST مقابل البدائل — هو استخدام الأداة الصح لكل مستهلك. Stripe هي REST. Twilio هي REST. API Anthropic هو REST. الأنماط بتاعدك معنى.

امتى أختار GraphQL على REST؟

لما الـ API بتاعك داخلي للمنظمة بتاعتك، عندك كلاينتس فرونت إند متعددين (ويب، موبايل، إدارة) باحتياجات بيانات متنوعة، وفريقك عنده النضج التشغيلي للتعامل مع حدود تعقيد الاستعلام، وDataLoader، والصلاحيات على مستوى الحقل. ما تختارش GraphQL لأنه trendy. اختاره لأن عندك ألم جلب ناقص REST مش هتقدر تحله بأناقة.

هل tRPC جاهز للإنتاج؟

أه، فعلاً جداً. شحنت tRPC على خمس مشاريع إنتاج في الـ 18 شهر اللي فاتت من غير ندم. القيد هو إن الطرفين لازم يكونوا TypeScript وفي الأفضلية في نفس الـ monorepo. لو بتلبي القيود دي، tRPC هو الطريقة الأكتر إنتاجية لبناء APIs داخلية في 2026.

إزاي أعيّن إصدار الـ API بتاعي؟

تعيين إصدار بالـ URL (/api/v1/) لأغلب المشاريع لأنه مرئي وقابل للتصحيح وموجّه ببساطة. تعيين إصدار مبني على التاريخ (أسلوب Stripe) للـ APIs اللي بتتطور بتكرار من غير إعادة تصميم كبيرة. دايماً عيّن إصدار من اليوم الأول — إضافة تعيين إصدار بعد الإطلاق هو في حد ذاته تغيير كاسر. ادعم الإصدارات القديمة لـ 12 شهر على الأقل بعد الإهمال.

إيه أأمن طريقة للتعامل مع المصادقة لـ SPA؟

لو الـ SPA بتاعك على نفس الدومين زي الـ API، استخدم HttpOnly Secure SameSite=Lax cookies مع رموز CSRF. لو هم على دومينات مختلفة، استخدم رموز JWT access قصيرة العمر (15 دقيقة) مع رموز refresh. أبداً ما تخزنش JWTs في localStorage — XSS هيسحبها. نمط "JWT في localStorage" غلطة أمنية الدروس بتفضل تعلمها.

إزاي أمنع التغييرات الكاسرة لما أطوّر API؟

تلات قواعد: التغييرات الإضافية (حقول اختيارية جديدة، endpoints جديدة) آمنة ومش بتحتاج رفع إصدار؛ أهمل الحقول بـ directive @deprecated (GraphQL) أو Sunset header (REST) قبل ما تشيلها؛ شغّل تحليلات استخدام علشان تعرف امتى الحقل آمن للحذف. لو الـ API بتاعك عنده عملاء بيدفعوا، ادعم الإصدارات المهملة لـ 12-24 شهر على الأقل.

هل أبني API gateway مخصص ولا أستخدم واحد جاهز؟

جاهز، إلا لو عندك سبب محدد جداً. Kong، Tyk، AWS API Gateway، Cloudflare API Shield، وApigee كلهم بيتعاملوا مع تحديد المعدل، والمصادقة، وتحويل الطلبات، والقابلية للملاحظة. بناء واحد بتاعك مشروع سنين بيشتت عن المنتج الفعلي بتاعك. الـ gateways المخصصة منطقية للشركات الفائقة المقياس (Netflix، Uber) وتقريباً محدش تاني.

اشحن الـ API بتاعك صح من المرة الأولى

تصميم API واحد من المناطق اللي الفرق بين "كويس كفاية" و"كويس فعلاً" بيتراكم على مدى سنين. v1 نضيف بيحميك من إعادة كتابة v2 في رعب. استراتيجية تعيين إصدار بتحمي علاقاتك بالعملاء. نموذج صلاحيات صحيح بيحميك من خروقات البيانات. دي مش لمسات اختيارية — دي السلامة الهيكلية لمنتجك.

قضيت خمس سنين أبني APIs لعملاء عبر مصر والسعودية والإمارات وبريطانيا وسويسرا وفرنسا وألمانيا والكويت. الأنماط اللي وصفتها في المقال ده هي اللي نجت من الإنتاج. لو بتـبني SaaS جديد، أو بتختار بين WordPress و Laravel، أو بتطلق منصة e-commerce، الـ API هو أساسك. اضبطه صح.

لو عاوز عين تانية على تصميم الـ API بتاعك قبل ما تشحن — علشان تلقط الأخطاء اللي بتاخد شهور تتصلح بعدين — بأقدم مراجعات تصميم مجانية 30 دقيقة. هنمشي على endpoints بتاعتك، ومصادقتك، واستراتيجية تعيين الإصدار، وخطة التوسع، وهاقولك بصراحة إيه اللي هيألمك بعد 18 شهر. سواء كنت مؤسس فردي أو وكالة، المراجعة الصح في الوقت الصح بتدفع تكلفتها مرات كتير. احجز استشارة مجانية هنا، أو تصفح خدمات الباك إند وAPI بتاعتي لتشوف إزاي نقدر نشتغل سوا. اشحن الـ API اللي نفسك المستقبلية هتشكرك عليها.