محمد عطية
ترند الأسبوع5 دقايق قراية

floci بديل LocalStack: شغّل AWS على جهازك من غير فاتورة

floci بديل LocalStack مفتوح وببلاش: إزاي بيقلّد الـ API بتاع AWS على جهازك عشان تشغّل الـ tests والـ CI، وإيه اللي مش هيكشفهولك.

لو عندك كود بيكلّم AWS، الـ test بتاعه قدامه اختيارين وحشين: يا يكلّم account حقيقي، فتدفع وتحط مفاتيح حقيقية في الـ CI (السيرفر اللي بيشغّل الـ tests مع كل push)، يا تعمل mock، يعني كود مزيّف بيرد بدل AWS، فما تعرفش هل الطلب اللي الـ SDK بعته كان هيتقبل أصلًا.

المشروع اللي طالع على GitHub Trending الأسبوع ده، floci، بيقدّم اختيار تالت: AWS مزيّف بيشتغل على جهازك، مفتوح وببلاش.

ليه طالع ترند دلوقتي؟

أشهر emulator للـ AWS، يعني برنامج بيعمل نفسه AWS على جهازك، هو LocalStack. وفي مارس 2026 اتغيّرت حاجة مهمة: من 23 مارس بقى LocalStack for AWS بيطلع كـ image واحدة محتاجة auth token، يعني مفتاح دخول مربوط بحسابك عندهم، وعشان تاخد آخر النسخ محتاج account، حتى في الـ CI. النسخ القديمة لسه بتشتغل من غير token، بس ما بقاش بيجيلها تحديثات ولا security fixes.

المشروع ده اتعمل في فبراير 2026، والـ README بتاعه بيلخّص نفسه في سطر: "No account. No auth token. No feature gates." والـ license بتاعه MIT، يعني تستخدمه وتعدّل فيه حتى في شغل تجاري، بشرط تسيب نص الـ license. ولحد 4 نوفمبر 2026 عليه حوالي 29 ألف star.

بيشتغل إزاي؟

الفكرة إنه مش بيقلّد السحابة نفسها، بيقلّد الـ API: شكل الطلبات اللي الـ SDK (المكتبة الرسمية بتاعة AWS) بيبعتها، وشكل الردود اللي بيستناها. زي بروفة مسرحية: الديكور كرتون، بس الحوار هو هو. فالكود بتاعك بيفضل زي ما هو، وإنت بتغيّر حاجة واحدة: الـ endpoint، يعني العنوان اللي الـ SDK بيبعت عليه، يبقى http://localhost:4566.

your code --(AWS SDK)--> http://localhost:4566 --> floci
                                                    |-- in-process : S3, SQS, DynamoDB, SNS, IAM ...
                                                    '-- Docker     : Lambda, RDS, ECS, EKS ...

الرسمة بتقول إن كل الـ services على نفس الـ port، ومن جوّه فيه نوعين:

  • الخفيفة زي S3 و SQS و DynamoDB شغالة in-process، يعني جوّه نفس البرنامج، من غير أي حاجة زيادة.
  • التقيلة زي Lambda و RDS و ECS، floci بيشغّل لها Docker containers حقيقية. مثلًا الـ Lambda function بتاعتك بتتنفّذ فعلًا جوّه container، مش رد جاهز.

وعشان يقدر يشغّل الـ containers دي، لازم تدّيله الـ Docker socket، يعني الباب اللي بيتحكم منه في Docker على جهازك، ومثال الـ README بيشغّله كـ root كمان، يعني بأعلى صلاحية. معنى كده إن floci يقدر يشغّل ويقفل containers على الجهاز، فاعمل ده بس على جهاز أو سيرفر CI إنت مطمّن له. ولو كل اللي محتاجه S3 و SQS، ما تحتاجش الـ socket خالص.

مثال: test لـ service بتحط ملف في S3

مثلًا عندك service بتستقبل فاتورة، تحطها في S3، وتبعت رسالة على SQS عشان worker يعالجها. وعايز test يتأكد إن الملف اتحط والرسالة اتبعتت، ويشتغل في الـ CI مع كل push.

  1. شغّل floci: docker run -d -p 4566:4566 floci/floci:latest
  2. قول للـ SDK يروح لـ floci بدل AWS، بـ environment variables: export AWS_ENDPOINT_URL=http://localhost:4566 export AWS_DEFAULT_REGION=us-east-1 export AWS_ACCESS_KEY_ID=test export AWS_SECRET_ACCESS_KEY=test المفاتيح هنا كلمة test وخلاص، مفيش مفتاح حقيقي في أي حتة.
  3. شغّل الـ tests زي ما هي. الكود بيعمل الـ bucket ويحط الملف ويبعت الرسالة، وكله رايح لـ localhost.
  4. اقفل الـ container. في الوضع الافتراضي الداتا كلها في الـ RAM وبتتمسح، فالـ run الجاي يبدأ على نضيف.

ولو مش عايز تشغّله بإيدك، فيه Testcontainers modules، يعني مكتبة بتشغّل الـ container من جوّه الـ test نفسه وتقفله لما يخلص. موجودة لـ Java و Python و Node، ولـ .NET كمان باسم Testcontainers.Floci على GitHub Packages.

الداتا بتتحفظ فين؟

الـ setting اسمه FLOCI_STORAGE_MODE، وليه 4 اختيارات:

  • وضع memory (الافتراضي): كله في الـ RAM ويتمسح لما الـ container يقف. ده المناسب للـ CI.
  • وضع hybrid: شغال في الـ memory وبيحفظ على الـ disk كل 5 ثواني. الـ README بيرشّحه للشغل على جهازك، مثلًا لو عايز الـ buckets تفضل موجودة تاني يوم.
  • وضع persistent: بيحفظ على الـ disk مع كل عملية كتابة.
  • وضع wal: يعني write-ahead log، كل تغيير بيتسجّل في log قبل ما يرد عليك. ده أعلى حماية للداتا.

التمن: إيه اللي floci مش هيقولّهولك؟

كل قرار ليه تمن، والتمن هنا إن ده مش AWS.

الصلاحيات. by default أي مفاتيح مش فاضية بتعدّي. يعني لو الـ IAM role، أي الصلاحيات اللي الـ service بتاعتك واخداها، ناقصها صلاحية الكتابة على S3، الـ test هيعدّي عندك ويقع على AWS. فيه setting لـ S3 بس (FLOCI_SERVICES_S3_ENFORCE_AUTH) بيرفض المفاتيح المش معروفة ويطبّق public و private على القراءة، بس ده مش بديل عن IAM الحقيقي.

services متعملة شكل بس. الـ Bedrock Runtime، خدمة AWS اللي بتكلّم موديلات الـ AI، بيرد ردود وهمية. والـ Transcribe، اللي بيحوّل الصوت لكلام مكتوب، بيخلّص الـ job على طول من غير ما يعالج صوت فعلًا. والـ Textract، اللي بيطلّع النص من الصور والمستندات، بيرجّع داتا وهمية. فلو الـ feature بتاعتك قايمة على موديل AI، floci بيختبر إن الكود بيبعت الطلب صح، مش إن الرد مفيد.

والخلاصة: test عدّى عندك مش ضمان إنه هيعدّي على AWS.

رأيي

رأيي إن floci مكانه الطبيعي الـ tests والـ CI: بيتشغّل بأمر واحد، ببلاش، ومن غير مفاتيح حقيقية. بس أنا بتعامل معاه كبروفة. آخر خطوة قبل production، بيئة staging (نسخة من السيستم بنجرّب عليها قبل المستخدمين) على account حقيقي وبصلاحيات حقيقية، دي ما تتشالش.

ولو إنت مثبّت نسخة قديمة من LocalStack عشان تهرب من الـ token، floci يستاهل تجرّبه. بس هو مشروع عمره شهور، فجرّبه الأول على الـ services اللي إنت بتستخدمها فعلًا قبل ما تنقل الـ CI كله عليه.

المصادر

اقرا كمان