كيفية نشر تطبيق React في بيئة الإنتاج باستخدام Docker وNGINX مع إعداد API Proxy

مقدمة: لماذا تحتاج إلى طريقة احترافية لنشر تطبيق React؟

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

في هذا الدليل العملي، ستتعرف على أسلوب بسيط وفعّال لنشر تطبيق React باستخدام Docker وNGINX. كما سنوضح كيف يمكن استخدام API Proxy لإخفاء API Key ومنع أخطاء الطلبات متعددة المصادر، من دون الحاجة إلى بناء واجهة خلفية كاملة ما لم تكن هناك ضرورة حقيقية لذلك.

هذه الاستراتيجية مناسبة بشكل خاص للتطبيقات الأمامية الثابتة التي تعتمد على استهلاك API خارجي، لكنها ليست الخيار الأنسب إذا كان مشروعك يعتمد على Server-Side Rendering، لأن هذا النوع يتطلب عادة طبقة خلفية فعلية.

ماذا ستتعلم من هذا المقال؟

• كيفية تجهيز تطبيق React للنشر في بيئة الإنتاج.
• طريقة استخدام NGINX كخادم ثابت ووسيط Proxy للطلبات.
• كيف تخفي API Key عن المستخدم النهائي.
• كيفية تجاوز مشكلات Cross-Origin Resource Sharing (CORS).
• بناء صورة Docker وتشغيلها محلياً.
• رفع الحاوية إلى خدمات AWS وتشغيلها عبر ECR وECS.

المتطلبات الأساسية قبل البدء

لتحقيق أقصى استفادة من الشرح، يُفضّل أن تكون لديك معرفة أساسية بما يلي:

• بناء تطبيقات React.
• أساسيات التعامل مع Docker.
• فهم أولي لطبيعة عمل الخوادم وواجهات API.

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

بناء مثال عملي لتطبيق React

تم إنشاء تطبيق بسيط باستخدام create-react-app، وتتمثل مهمته في عرض مخطط خطي يوضح بيانات الناتج المحلي الإجمالي للولايات المتحدة اعتماداً على واجهة بيانات خارجية مقدمة من FRED API.

رابط الواجهة البرمجية المستخدمة

https://api.stlouisfed.org/fred/series/observations?series_id=GDPCA&frequency=a&observation_start=1999-04-15&observation_end=2021-01-01&file_type=json&api_key=abcdefghijklmnopqrstuvwxyz123456

شرح أهم معاملات الطلب

• series_id: المعرّف الخاص بالسلسلة البيانية، وGDPCA يشير إلى الناتج المحلي الحقيقي.
• frequency: مستوى تجميع البيانات، وa تعني بيانات سنوية.
• observation_start: تاريخ بداية النطاق الزمني.
• observation_end: تاريخ نهاية النطاق الزمني.
• file_type: نوع البيانات المرجعة، والقيمة الافتراضية غالباً هي xml.
• api_key: مفتاح الوصول المطلوب لاستهلاك البيانات.

المشكلة الأساسية: كشف المفتاح وظهور أخطاء CORS

رغم أن الواجهة البرمجية توفر البيانات المطلوبة، إلا أن تصميمها يفرض تمرير API Key ضمن الرابط نفسه. هذا السلوك يمثل مخاطرة واضحة، لأن المفتاح يصبح مرئياً ويمكن اعتراضه أو إساءة استخدامه.

المشكلة الثانية أن هذه الواجهة محمية ضد الطلبات القادمة من نطاقات خارجية، ما يؤدي إلى ظهور أخطاء CORS عند محاولة استدعائها مباشرة من تطبيق React يعمل في المتصفح.

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

لماذا يُعد NGINX خياراً ذكياً لهذه المهمة؟

يُعرف NGINX بأنه خادم ويب سريع وخفيف وموثوق، لكنه أيضاً ممتاز في دور Reverse Proxy. وهذا يعني أنه يستطيع استقبال الطلبات من التطبيق، ثم إعادة توجيهها إلى الواجهة البرمجية الخارجية مع إضافة القيم الحساسة داخل الخادم بدلاً من المتصفح.

بهذه الطريقة ستحقق هدفين مهمين:

• إخفاء API Key عن المستخدم.
• منع أخطاء CORS لأن التطبيق سيتعامل مع نفس المصدر ظاهرياً عبر المسار /api.

إعداد NGINX كوسيط للطلبات

http {
  server {
    location /api {
      set $args $args&file_type=json&api_key=abcdefghijklmnopqrstuvwxyz123456;
      proxy_pass https://api.stlouisfed.org/fred/series;
    }
  }
}

هذا المقطع البسيط كافٍ لتحويل أي طلب إلى المسار /api بحيث يُرسل فعلياً إلى FRED API مع إضافة api_key وfile_type=json تلقائياً من داخل الخادم.

كيف سيبدو الرابط الجديد داخل التطبيق؟

/api/observations?series_id=GDPCA&frequency=a&observation_start=1999-04-15&observation_end=2021-01-01

لاحظ أنك لم تعد بحاجة إلى تمرير api_key أو file_type من الواجهة الأمامية. وهذا يجعل التطبيق أنظف وأكثر أماناً.

استخدام Docker لتغليف التطبيق وتشغيله بسهولة

أفضل طريقة لتشغيل NGINX مع التطبيق في بيئات مختلفة هي وضع كل شيء داخل حاوية Docker. بهذه الآلية يمكنك نقل التطبيق من جهازك المحلي إلى أي خادم أو مزود سحابي مع ضمان تطابق البيئة التشغيلية.

ملف Dockerfile

FROM nginx
COPY container /
COPY build /usr/share/nginx/html

هذا الملف يقوم بما يلي:

• الاعتماد على صورة nginx الجاهزة.
• نسخ إعدادات الخادم من مجلد container.
• نسخ ملفات البناء الناتجة من تطبيق React إلى مجلد التقديم الثابت داخل NGINX.

خطوات التشغيل محلياً

1. تثبيت الاعتماديات.
2. بناء نسخة الإنتاج من التطبيق.
3. إنشاء صورة Docker.
4. تشغيل الحاوية وربط المنفذ المحلي مع منفذ الخادم داخل الحاوية.

$ yarn install
$ yarn build
$ docker build -t msokola/fred-app:latest .
$ docker run -p 8081:80 -it msokola/fred-app:latest

بعد تنفيذ الأوامر السابقة، سيصبح التطبيق متاحاً عبر الرابط http://localhost:8081.

كيف تتحقق من نجاح التشغيل؟

عند فتح التطبيق في المتصفح، من المفترض أن تظهر سجلات مشابهة لما يلي داخل الطرفية:

0.0.0.1 - - [11/Mar/2021:18:57:50 +0000] "GET / HTTP/1.1" 200 1556 "-" "Mozilla/5.0" "-"
0.0.0.1 - - [11/Mar/2021:18:57:51 +0000] "GET /api/observations?series_id=GDPCA&frequency=a&observation_start=1999-04-15&observation_end=2021-01-01 HTTP/1.1" 200 404 "http://localhost:8081/" "Mozilla/5.0" "-"

وجود الرمز 200 يعني أن الطلب نُفّذ بنجاح. إذا ظهر الرمز 400 بجوار طلب الواجهة البرمجية، فغالباً توجد مشكلة في API Key. أما الرمز 304 فيشير عادة إلى أن البيانات مخزنة مؤقتاً، وهو سلوك طبيعي.

نشر الحاوية على AWS

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

1) تثبيت وإعداد أدوات AWS CLI

بعد تثبيت أدوات AWS CLI المناسبة لنظامك، نفّذ الأمر التالي لتسجيل بيانات الوصول:

$ aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: us-east-2
Default output format [None]: json

لإنشاء مفاتيح الوصول، ادخل إلى لوحة تحكم AWS ثم انتقل إلى إعدادات الأمان الخاصة بحسابك.

2) إنشاء مستودع جديد في Elastic Container Registry (ECR)

نحتاج أولاً إلى مكان لتخزين صورة Docker الخاصة بالتطبيق:

aws ecr create-repository --repository-name react-to-aws --region us-east-2

أهم الوسائط في الأمر:

• ecr: خدمة مستودعات الحاويات في AWS.
• repository-name: اسم المستودع الذي سترفع إليه الصورة.
• region: المنطقة الجغرافية التي ستُنشأ فيها الخدمة.

الناتج المتوقع سيكون على هيئة JSON ويحتوي على تفاصيل مثل repositoryUri وregistryId.

{
  "repository": {
    "repositoryArn": "arn:aws:ecr:us-east-2:1234567890:repository/react-to-aws2",
    "registryId": "1234567890",
    "repositoryName": "react-to-aws",
    "repositoryUri": "1234567890.dkr.ecr.us-east-2.amazonaws.com/react-to-aws2",
    "createdAt": "2021-03-16T22:50:23+04:00",
    "imageTagMutability": "MUTABLE",
    "imageScanningConfiguration": {
      "scanOnPush": false
    },
    "encryptionConfiguration": {
      "encryptionType": "AES256"
    }
  }
}

3) رفع صورة Docker إلى السحابة

بعد إنشاء المستودع، يمكنك تسجيل الدخول إليه ثم رفع الصورة باستخدام أوامر مشابهة لما يلي:

$ aws ecr get-login-password --region us-east-2 | docker login --username AWS --password-stdin 123456789.dkr.ecr.us-east-2.amazonaws.com
Login Succeeded

$ docker build -t react-to-aws .

$ docker tag react-to-aws:latest 123465789.dkr.ecr.us-east-2.amazonaws.com/react-to-aws:latest

$ docker push 123456789.dkr.ecr.us-east-2.amazonaws.com/react-to-aws:latest

بعد اكتمال الرفع، ستجد الصورة متاحة داخل المستودع ويمكنك نسخ URI الخاص بها لاستخدامه في خطوة التشغيل.

4) إعداد Task Definition في ECS

حتى تتمكن الآلات الافتراضية من تشغيل الصورة، يجب تحديد إعدادات التنفيذ مثل حجم الذاكرة، ووحدة المعالجة، والمنافذ المفتوحة. في AWS ECS يُطلق على هذا الإعداد اسم Task Definition.

عند إنشاء مهمة جديدة، اختر النمط FARGATE ثم استخدم قيماً مناسبة مثل:

• اسم المهمة: react-to-aws-task
• الدور: none
• الذاكرة: 0.5GB
• المعالج: 0.25 vCPU

ثم أضف الحاوية بالقيم التالية:

• اسم الحاوية: react-to-aws
• الصورة: URI الذي نسخته من ECR
• حد الذاكرة: 128 MiB
• المنفذ: 80

5) إنشاء Cluster وتشغيل التطبيق

الخطوة الأخيرة هي إنشاء Cluster داخل ECS، ثم تشغيل المهمة داخله:

• اختر Clusters ثم Create Cluster.
• استخدم خيار Networking only.
• سمِّ المجموعة باسم react-to-aws.

بعد إنشاء المجموعة، انتقل إلى تبويب Tasks واختر Run new Task، ثم حدّد:

• Launch type: FARGATE
• Cluster VPC: أول شبكة متاحة
• Subnet: أول شبكة فرعية متاحة

عند تشغيل المهمة والانتظار حتى تتغير الحالة إلى RUNNING، ستجد عنوان Public IP الخاص بالحاوية في قسم الشبكة. افتح هذا العنوان في المتصفح، وستظهر لك نسخة التطبيق المنشورة.

فوائد هذا الأسلوب في النشر

• تقليل التعقيد بعدم بناء Backend غير ضروري.
• رفع مستوى الأمان عبر إخفاء API Key.
• التعامل مع مشكلة CORS بكفاءة.
• سهولة نقل التطبيق بين البيئات بفضل Docker.
• الاستعداد للتوسع لاحقاً عند الحاجة إلى تطوير البنية.

ملاحظات مهمة قبل اعتماد هذه البنية

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

الخلاصة التقنية

استخدام Docker مع NGINX لنشر تطبيق React يمنحك توازناً ممتازاً بين البساطة والأمان والاعتمادية. فعوضاً عن بناء طبقة خلفية كاملة لمجرد تمرير الطلبات، يمكنك الاستفادة من NGINX كوسيط ذكي يخفي المفاتيح الحساسة ويعالج مشكلات CORS بكفاءة. ومن الناحية العملية، يُعد هذا النهج مناسباً جداً للمشاريع الصغيرة والمتوسطة، كما أنه يهيئ التطبيق للانتقال السلس إلى بيئات سحابية مثل AWS عند الحاجة إلى التوسع.