كيفية تنظيم خدمة الويب Python مع واجهة برمجة التطبيقات وواجهة ويب؟

Question

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

عند النشر حاليًا ، لدينا جهازان مختلفان: أحدهما هو خدمة الويب ، التي تستخدم واجهة برمجة التطبيقات ، والآخر هو تطبيق الويب.

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

ثم ، الإساءة GIT الفرعية, ، فصل تطبيق الويب عن الجهاز الفرعي API والتي يمكن تطويرها بشكل متزامن.

وبهذه الطريقة ، يمكن أن يكون هناك إصدار لاتصالات API (مراجعة الالتزام المحددة) وكذلك نشر تطبيق الويب الذي لا يتداخل مع بعضها البعض طالما يتم تطبيق التوافق المتخلف.

بضع سلبيات مع هذا النهج:

1. إنه مرتبط بالجيت
2. لا تزال التغييرات في API تتطلب إعادة تشغيل تطبيق الويب (ولكن هذا هو الحال مع أي بناء خدمة حول واجهة برمجة التطبيقات)
3. قد تكون git-submodules معقدة بشكل مفرط ويصعب فهمها للأشخاص الجدد (لست متأكدًا من هذا)

بمجرد أن يكون لدينا عرض ترددي كافٍ ، يمكننا استخدام شيء مثل ZC.Buildout لاستخدام نظام بناء للنشر.

أحد الحلول الأخرى ، هو مجرد استخدام ZC.Buildout على الفور والحصول على مستودع رئيسي واحد وبناء ملفات إصدار Python.

أفكار؟

Answer 1

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