مقدمة

ملاحظة 1: إليك العرض التوضيحي التفاعلي المستضاف: demo.saasconstruct.com

ملاحظة 2: فاتورتي الشهرية لكل إعداد SaaS هي 3-5 دولارات شهريًا، وهي في الغالب تكاليف CI/CD.

ملاحظة 3: القالب موجود هنا: saasconstruct.com.

لقد أجريت العديد من عمليات إثبات المفهوم (PoCs) وMVPs الخاصة بالذكاء الاصطناعي على AWS، وهي دائمًا أشياء متشابهة:

• استضافة الواجهة الأمامية في مكان ما
• إجراء مكالمة إلى الواجهة الخلفية
• تحصل الواجهة الخلفية على/تحديث البيانات من التخزين الثنائي/قاعدة البيانات
• تقوم الواجهة الخلفية ببعض منطق الذكاء الاصطناعي أو تستدعي خدمة أخرى وترسل النتيجة مرة أخرى
• يوجد حسابان معزولان على AWS: dev وprod
• CI/CD لعمليات النشر
• البنية التحتية كرمز لإعلان الموارد السحابية

لذا، فكرت في إنشاء حل بسيط لتشغيل مثل هذه الأشياء على AWS. وكتابة تدوينة حول هذا الموضوع.

قررت إضافة بعض الميزات، مثل مدفوعات Stripe (ومدفوعات LemonSqueezy إذا كنت لا تريد القلق بشأن ضريبة المبيعات/ضريبة القيمة المضافة) وإدارة الدفع والمصادقة وإنذارات حركة المرور وغيرها. وأعتقد أيضًا أنها بحاجة إلى أن تكون قابلة للتكوين، مثل استبدال API Gateway وAWS Lambda بـ ELB وECS للمهام الأطول.

الواجهة الأمامية

لقد اخترت الإطار الأسهل المعلن عنه عادةً للبدء به. إنه Vue، وبقدر ما فهمت، فهو ثاني أكثر إطار عمل شيوعًا. لقد اخترته ليس لأنه الأسهل فحسب، بل لأنه كان لدي بعض الخبرة فيه أيضًا.

الموقع الإلكتروني عبارة عن تطبيق SPA قياسي مع Vite كأداة بناء. بالنسبة للتصميم، أستخدم Bootstrap لأنه أيضًا من السهل جدًا التعامل معه، وأيضًا لأنه لا يسبب الكثير من الألم عند الانتقال من إصدار واحد من إطار عمل الواجهة الأمامية إلى إصدار آخر.

استضافة الواجهة الأمامية

هناك خياران:

• S3 وCloudFront (CDN)
• استضافة AWS Amplify، وهي عبارة عن برنامج مجمع حول S3 وCloudFront، يسهل التعامل معها ولكنها أقل قابلية للتكوين. على سبيل المثال، لا يمكنك فعل أي شيء باستخدام توزيع CloudFront، لأنه غير مرئي. لا يمكنك أيضًا حظر تطبيقك جغرافيًا باستثناء القيام بذلك من خلال عمليات إعادة التوجيه.

لقد اخترت Amplify Hosting باعتباره محور التركيز الأساسي لـ AWS في حلول استضافة الواجهة الأمامية ولأنه من السهل إعداده وإرفاق نطاق وما إلى ذلك.

نظرًا لأنه أساس الدفع أولاً بأول، فقد قمت بإعداد إنذار حركة المرور: إذا كان هناك أكثر من عدد معين من الزيارات كل 10 ثوانٍ، أحصل على إشعار.

الخلفية

الواجهة الخلفية هي بوابة واجهة برمجة التطبيقات، التي تحدد المعدل، وAWS Lambda (Python)، التي تقوم بالأعمال والمنطق العام:

• التحقق من مصادقة المستخدم
• معالجة المدفوعات وإدارة الاشتراكات (بوابة العملاء)
• إرسال رسائل البريد الإلكتروني
• إلخ.

لدي أيضًا وظيفة AWS Lambda أخرى تقوم بإنشاء مستخدم في قاعدة البيانات بعد التسجيل في Cognito.

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

المصادقة

أعلم أن المصادقة مؤلمة، ولم أرغب في استخدام خدمة طرف ثالث. لذلك بقيت مع AWS Cognito. أنها رخيصة جداً.

يمكنك القول، ما عليك سوى استخدام AWS Amplify Auth (وهو عبارة عن غلاف حول AWS Cognito)، ولكن واجهت بعض المشكلات معه. حتى أنني كتبت منشورًا على Reddit:

قائمة المشاكل الخاصة بي مع Amplify للمصادقة

وهناك منشور آخر يحتوي على قائمة أكبر من بعض المستخدمين المحبطين (على الرغم من أنه منشور قديم).

هنا

علاوة على ذلك، إذا كنت تستخدم Amplify فقط، فأنت عالق في النظام البيئي بأكمله دون أي فرصة لتغيير شيء ما. على سبيل المثال، إذا كنت ترغب في الوصول إلى توزيع CloudFront (على سبيل المثال، عندما تريد حظر مناطق معينة جغرافيًا)، فمن الصعب أن تتمكن من رؤية ذلك باستخدام Amplify Hosting. لقد واجهت مشكلات أخرى أيضًا: أحد الأمثلة على ذلك هو إنشاء CDK من موارد Amplify، والتي كانت بمثابة نقطة ألم بالنسبة لي.

إذن ما فعلته هو نهج مختلط (وهو شائع إلى حد ما وفقًا لـ Reddit): تتيح لك مكتبة AWS Amplify JS استيراد الموارد السحابية التي تنشئها بنفسك، مثل مجموعات المستخدمين، لذلك قمت بإنشائها باستخدام CDK ثم استخدم مكتبة Amplify JS للمصادقة.

في هذه الحالة، يمكنني دائمًا تغيير ما أريد، وتبديل الموارد السحابية (على سبيل المثال، يمكنني الانتقال من Amplify Hosting إلى CloudFront S3 إذا كنت بحاجة إلى الوصول إلى توزيع CloudFront).

رسائل البريد الإلكتروني

AWS SES. إنها خدمة البريد الإلكتروني الرئيسية لـ AWS. إنه يرسل كل شيء، بما في ذلك رسائل البريد الإلكتروني لمصادقة Cognito، والطلبات من نموذج الاتصال، وما إلى ذلك. الشيء الوحيد الذي تحتاج إلى فهمه هو أنه في حساب dev AWS الخاص بك، ستحتاج إلى إنشاء هويات تم التحقق منها أولاً لتتمكن من الإرسال (لقد قمت بأتمتة ذلك عبر IaC)، وفي حساب AWS للإنتاج، ستحتاج إلى طلب الوصول إلى الإنتاج (وهو ما لا يتطلب سوى بضع نقرات).

باستخدام AWS SES، يتم إرسال إشعارات البريد الإلكتروني في السيناريوهات التالية:

• عند حدوث أخطاء في الدفع.
• في حالة حدوث طفرات في حركة مرور الويب.
• إذا فشل تشغيل CI/CD.
• للحالات الأخرى، مثل رسائل البريد الإلكتروني للمصادقة والاستفسارات من نموذج الاتصال، وما إلى ذلك.

تخزين

DynamoDB كقاعدة بيانات. سهلة وسريعة، وإدارتها. نعم، كان علي أن أفكر في أنماط الوصول، ولكن بشكل عام، من الجيد العمل معها ولا يكلفني أي شيء أثناء التحقق من الصحة/البناء. نظرًا لأنني أخطط للعمل على العديد من المنتجات وأريد إبقائها معزولة، فلا يمكنني وضع RDS/DocumentDB في حسابات التطوير والإنتاج لكل مشروع (يكلف ذلك كثيرًا).

المدفوعات

لقد أضفت نظامين للدفع، ومن الممكن اختيار أي منهما لاستخدامه لأنهما يعملان بنفس الطريقة:

• Stripe شائع وسهل الدمج، وسهل وبسيط. عندما يشتري مستخدم منتجًا، أستخدم Stripe checkout، ولإدارة الاشتراكات، أستخدم بوابة عملاء Stripe.
• LemonSqueezy يشبه إلى حد كبير Stripe، ولكنه أيضًا تاجر مسجل، مما يعني أنه يتولى ضريبة المبيعات/ضريبة القيمة المضافة نيابةً عنك. كما أن لديها الخروج لشراء الاشتراك وبوابة العملاء لإدارتها.

هناك نقاط نهاية كتبتها لخطافات الويب Stripe/LemonSqueezy، والتي تتعامل مع كل المنطق.

البنية التحتية كرمز

لذلك هناك الكثير من الأشياء للاختيار من بينها:

• شيء مثل Terraform أو OpenTofu (بديل مفتوح المصدر بالكامل يعتمد على Terraform)
• بولومي
• سي دي كيه
• تكوين السحابة

لقد اخترت AWS CDK، وإليك الأسباب:

• من السهل العمل معه
• أنها شعبية وناضجة بما فيه الكفاية
• إنه أفضل بكثير من AWS CloudFormation، في رأيي
• إنها مكتبة AWS، وأنا أستخدم AWS
• يمكنني كتابتها بلغة Python أو TypeScript أو لغات أخرى. نظرًا لأنني أستخدم Python في الواجهة الخلفية وTypeScript في الواجهة الأمامية، فهذا اختيار جيد.

السبب وراء عدم اختيار Terraform هو أن CDK أسهل؛ فهو يسمح بإنشاء الموارد بطريقة بسيطة، على الأقل في رأيي. أنا أحب OOP وأحاول إنشاء البنية التحتية السحابية الخاصة بي وفقًا لذلك. هناك فائدة كبيرة تتمثل في تضمين CI/CD (خطوط أنابيب CDK)، لذلك لا يتعين علي اختراع ذلك.

سي آي/سي دي

لقد اخترت خطوط أنابيب CDK لأنها مرة أخرى سهلة. ما عليك سوى توصيل المسار بمستودع GitHub، وستكون جاهزًا للانطلاق. ادفع Git إلى فرع التطوير -> سيتم نشره في حساب التطوير. ادفع Git إلى الطلب الرئيسي (أو طلب السحب) -> بدء الإنتاج.

الإنذارات وحدود المعدل

لقد قمت بإعداد تحديد المعدل لمنع تلقي رسائل غير مرغوب فيها عبر بوابة واجهة برمجة التطبيقات. لقد قمت بإعداد اثنين من منبهات CloudWatch:

• لتنبيهي عندما يتعرض موقع الويب المستضاف إلى رسائل غير مرغوب فيها بالطلبات.
• لتنبيهي عندما تتعرض بوابة واجهة برمجة التطبيقات (API Gateway) لرسائل غير مرغوب فيها بالطلبات.

لقد قمت أيضًا بإعداد منبهات الفوترة لإبلاغي إذا كنت على وشك إنفاق الكثير.

التسجيل

يسجل CloudWatch الأحداث، ويمكنك رؤيتها في وحدة تحكم AWS ومباشرة في IDE عبر الملحقات.

منظمة العفو الدولية

كان الاختيار بين استخدام OpenAI (مع نماذج GPT) أو AWS Bedrock (مع نماذج Claude). كان هذا القرار صعبًا لأنه على الرغم من أن AWS Bedrock مع Claude يتكامل بسهولة مع AWS، إلا أن OpenAI هو الأكثر شيوعًا. تقدم كلا الشركتين نماذج من الذكاء الاصطناعي من الدرجة الأولى. في الوقت الحالي، اخترت الاستمرار في استخدام AWS Bedrock. قد يتغير هذا في المستقبل، لكن في الوقت الحالي، أقدر البساطة. بالنسبة لقاعدة البيانات المتجهة، أستخدم Pinecone، الذي يحتوي على فهارس بدون خادم.

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

لغات البرمجة

كنت في البداية مطورًا لـ Java، ولكن بعد ذلك أصبحت مطورًا لـ Python لأنني طورت التعلم الآلي وخدمات التعلم العميق. تم تطوير معظم المكتبات في هذا المجال بلغة Python أو تحتوي على غلاف Python. علاوة على ذلك، تتكامل Python بسلاسة مع AWS، سواء في AWS Lambda (على سبيل المثال، باستخدام مكتبة AWS Lambda Powertools) أو في CDK. لذا في النهاية، يتم تنفيذ كل من البنية التحتية الخلفية والسحابية (عبر CDK) في بايثون.

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

فواتير AWS

نظرًا لعدم وجود حمل كبير على حركة المرور، فإن تكاليف AWS الخاصة بي منخفضة جدًا، عادةً 3-5 دولارات شهريًا، ويرجع ذلك في المقام الأول إلى نفقات CI/CD.

يتضمن الإعداد CDN (مقدم من Amplify Hosting) وطبقة تخزين مؤقت صغيرة داخل AWS Lambda. بالإضافة إلى ذلك، تندرج بعض الخدمات ضمن طبقة AWS المجانية، مما يقلل من التكاليف التي أتحملها.

مع توسع المنتج واكتساب المزيد من المستخدمين، قد أحتاج إلى تحسين الموارد عن طريق التبديل إلى الموفر DynamoDB وتنفيذ DAX (DynamoDB Accelerator). ومع ذلك، في الوقت الحالي، يعمل هذا الإعداد بشكل مثالي.

خاتمة

يلبي هذا الحل احتياجاتي الحالية بكفاءة.

لقد قمت بتضمين هذه المجموعة التقنية بأكملها باعتبارها نموذجًا معياريًا (الذي أقوم بتطويره وتحديثه بشكل نشط) في قالب AWS على SaaSConstruct.

سأستمر في استكشاف الميزات الإضافية التي يمكن دمجها في هذا الإعداد لتعزيز قدراته...