Apicurio-studio: قادرة على دعم معيار AsyncAPI في المحرر

أرغب في رؤية محرر مرئي Apicurio لـ AsyncAPI. في الوقت الحالي ، لا يمتلك هذا المشروع النطاق الترددي الهندسي لمثل هذا الجهد. :(

EricWittmann شكرا على الرد. سأحاول أن أجد بعض الوقت للعمل على هذه الميزة إذا لم يكن الأمر بهذه الصعوبة ...

حسنًا ، أعتقد أن إضافة الدعم لـ AsyncAPI يمثل قدرًا هائلاً من العمل. من المحتمل أن تكون المهمة الأولى هي تنفيذ طبقة محلل / نموذج لها. بالنسبة إلى OAI ، قمت بذلك هنا:

https://github.com/apicurio/oai-ts-core

لذلك ربما يكون هذا مكانًا جيدًا للبدء - ربما مستودع جديد مثل asyncapi-ts-core .

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

لما يستحق ، بدأت AsyncAPI في التقاط بعض البخار الإضافي. لذا فإن تقديم الدعم لها في Apicurio يرفع قائمة الأولويات. :) لا توجد ETA أو أي شيء من هذا القبيل حتى الآن - ولكن نأمل أن نبدأ في إحراز بعض التقدم في هذا المجال.

من الجيد سماع هذا الخبر ، EricWittmann ، شكرًا. أرغب في المشاركة إذا وجدت الوقت الكافي.

FWIW ، لدينا الآن محلل لـ AsyncAPI 2.0.0 . لقد كنا نناقش الترحيل إلى Typescript. سيكون من الرائع أن يكون لديك قائمة بالمهام التي يجب القيام بها من أجل الحصول على AsyncAPI في Apicurio. نحن ربما نكون قادرين على مساعدة :)

هذا مثير للاهتمام ، fmvilas - شكرًا على المؤشر. لقد قمنا بالفعل ببناء تطبيق نموذج البيانات الموحد الخاص بنا لـ AsyncAPI و OpenAPI هنا: https://github.com/Apicurio/apicurio-data-models

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

إلى الجزء الأكثر إثارة للاهتمام من تعليقك - المهام التي يجب القيام بها من أجل الحصول على AsyncAPI في Apicurio. :) :) أعتقد أن الشيء المهم الآن هو دعم المحرر. في النهاية ، أود الحصول على تكافؤ في الميزات مع محرر OpenAPI المرئي (والذي يتضمن التحقق من الصحة ودعم التحرير المتزامن). ومع ذلك ، أعتقد أن مساهمة لطيفة (ربما مؤقتة) على المدى القصير ستكون دمج محرر AsyncAPI القائم على النص في Apicurio. سيكون ذلك رائعًا جدًا وسيقطع شوطًا طويلاً. يمكنني رؤية مستقبل يكون فيه كل من المحرر المستند إلى النص والمحرر المرئي خيارين مدعومين. لقد طلب أحد مستخدمي المجتمع ذلك بالفعل - لم يحب كبار مطوريهم المحرر المرئي وبدلاً من ذلك أرادوا محرر نصوص. إذهب واستنتج.

بخلاف المحرر ، يجب أن أفكر في قائمة المهام. لكن كل شيء آخر سيكون تدريجيًا على رأس المحرر (مثل إنشاء المشروع).

إلى الجزء الأكثر إثارة للاهتمام من تعليقك - المهام التي يجب القيام بها من أجل الحصول على AsyncAPI في Apicurio. :) :)

اسمعك :)

حسنًا ، كما قلت ، لنبدأ بشيء سهل / أسهل. سأخبرك بمجرد أن يكون لدينا بعض النطاق الترددي للتعاون. شكرا!

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

أنا أشير إلى المحرر الموجود في الملعب هنا: https://playground.asyncapi.io/

لم أقم بالنظر في ذلك حتى الآن - لذا لست متأكدًا مما إذا كان قد تم تصميمه للاستفادة منه بسهولة في التطبيقات الأخرى ، ولكن إذا كان الأمر كذلك ، فآمل ألا يكون من الصعب استيراده واستخدامه. من شأن ذلك أن يقطع شوطًا طويلاً نحو المطالبة (على الأقل مبدئيًا) بدعم AsyncAPI داخل Apicurio Studio.

مرحبا EricWittmann ،

أقضي بعض الوقت اليوم في البحث عن تكلفة إضافة محرر رسومي لـ AsyncAPI والوصول إلى بداية النتيجة مؤخرًا. انظر لقطة الشاشة أدناه - لقد أعدت إنشاء نفس بنية OpenAPI وأضفت محرر الكود الذي لدينا بالفعل لذلك لدينا بالفعل تكافؤ في الميزات مقابل ما لدينا اليوم. لقد بدأت من مثال AsyncAPI الذي أضفته مسبقًا.

بعض الأفكار والأسئلة التي أود مشاركتها:

• الأول من ناحية التنفيذ: كان مكون المحرر الجديد موجودًا بالفعل وأتابع اتباع ذلك من خلال تكرار المكونات الموجودة في نظيرتها AsyncApi* . في معظم الأوقات ، فقط استبدال OasDocument بـ AaiDocument ، هذا ليس بالأناقة ... ومع ذلك فقد خدشت السطح للتو وستكون هناك اختلافات أكثر أهمية بين المواصفات 2 ... هل تفضل الاحتفاظ بهذه الطريقة وامتلاك مجموعتين مستقلتين من المكونات أو محاولة التبادل حتى لو كان هناك الكثير من if document.isOpenApi() أو if document.isAsyncApi() على طول الكود؟ ما رأيك ؟

• الثاني في هذه العملية. كما قلت من قبل ، قد يكون جهدًا كبيرًا ... ليس صعبًا تقنيًا ولكنه طويل ودقيق ... لذلك لا أعتقد أنني سأمتلك الصبر ولا أنه من الممكن تنفيذ محرري المواصفات بالكامل قبل ارتكاب أي شيء. أفضل أن أرى ذلك كمهمة متكررة حيث يمكنني ملء بعض القطع التي تبدأ بأولويات عالية ( Channels ، DataTypes ، Messages ، Examples ؛ - )) ثم الانتقال إلى أولويات أقل ( Servers ، Traits وهكذا ...). ما رأيك ؟ هل سيكون من المقبول تقسيم التنفيذ على العديد من طلبات السحب؟

يسعدني حقًا تقديم المساعدة حيث ربما تكون قد رأيت أن Microcks تدعم الآن محاكاة AsyncAPI (والاختبار في غضون أسابيع قليلة). لذلك قد يكون من المغير لقواعد اللعبة أن يكون لديك دعم Apicurio ويسمح بتغطية الأنماط الرئيسية لمواصفات API الحديثة.

cc fmvilas ؛-)

بادئ ذي بدء - تهانينا على إضافة دعم AsyncAPI في Microcks! لقد رأيت أنه تمت إضافته مؤخرًا.

لدي بعض الأفكار حول هذا. الأول هو أنني أعتقد أنه قد يكون من المنطقي محاولة الحصول على محرر AsyncAPI Playground مضمنًا في Apicurio Studio إذا كان ذلك من الناحية الفنية "سهل". :) سيكون ذلك بمثابة فوز سريع وسيمنحنا دعمًا "تجريبيًا" معقولاً لتحرير مستندات AsyncAPI في Apicurio Studio.

بعد ذلك ، يمكننا التركيز على إنشاء محرر مرئي.

(1) بالنسبة لسؤالك حول التنفيذ - أعتقد أن تكرار المكونات وتعديلها لتناسب AsyncAPI هو النهج الصحيح على المدى القصير. والسبب هو أنه من السهل إعادة البناء فيما بعد لمشاركة المكونات عبر المحررين ، ولكن الأهم من ذلك هو أننا سنقوم بإعادة تنفيذ واجهة مستخدم Studio بالكامل في React في وقت ما. لذا فإن أي جهود كبيرة نبذلها في تطبيق Angular الحالي ستضيع هباءً. من الأفضل أن تفعل شيئًا سريعًا لأنه سيتعين إعادة بنائه لاحقًا على أي حال.

(2) أوافق على أن الجهد ليس صعبًا من الناحية الفنية ولكنه طويل ودقيق. :) أعتقد أنه من المنطقي أن يتم تقسيم التطبيق إلى العديد من العلاقات العامة - ونأمل أن نتمكن من تقسيم العمل عبر العديد من المساهمين أيضًا.

fmvilas هل المحرر موجود في AsyncAPI Playground مفتوح المصدر (أفترض نعم) ويمكن أيضًا دمجه بسهولة في أدوات أخرى مثل Apicurio Studio؟

(إذا كانت الإجابة بنعم ، فستكون أي مؤشرات عن كيفية التوثيق رائعة)

شكرا EricWittmann !

لقد ألقيت نظرة سريعة على ملعب AsyncAPI أولاً ولكن يبدو أنه يحتوي على مكونات من جانب الخادم في NodeJS. لذلك كنت أفكر في أن الدمج لن يكون بهذه السهولة ... ولهذا السبب أستكشف طريقة المحرر ؛-)

يجب أن أكون قادرًا على قضاء المزيد من الوقت في ذلك بحلول نهاية الأسبوع ... إذا كان الأمر جيدًا بالنسبة لك ، فسأحاول إرسال أول علاقات عامة في بداية الأسبوع المقبل. يجب أن يكون من الممكن أن تكون المعلومات الرئيسية قابلة للتعديل ( Version ، Contact ، License و Tags ) بالإضافة إلى معاينة للقراءة فقط لـ Channels في العمود الأيسر.

إنه مفتوح المصدر ، يمكنك العثور عليه هنا . ومع ذلك ، نحن نعمل على تحسين أفضل بكثير مع الإكمال التلقائي ، والأخطاء التي تم الإبلاغ عنها في المحرر نفسه من خلال "وضع خط تحت" الأسطر والأعمدة الخاطئة ، وما إلى ذلك. إنه في الواقع هو ذلك الذي يظهر على AsyncAPI Hub ، والذي سيحل في النهاية محل Playground. لم يتم فتح هذا المصدر بعد ، ولكنه سيكون قريبًا جدًا ، قبل نهاية العام بالتأكيد ، وقد تم إجراؤه في React باستخدام محرر Monaco (المحرر الذي يدعم VS Code).

ولكن نظرًا لأنك تستخدم Angular في Apicurio Studio ، فأنا لست متأكدًا من أنها ستكون مفيدة. سمعت أنه من الممكن الجمع بين React و Angular ولكن بصراحة لم أحاول أبدًا.

شكرًا fmvilas - سنقوم في النهاية بالتحويل إلى React أيضًا (هذا قيد التقدم). هل يتطلب محرر AsyncAPI الجديد أي مكونات خادم أم أنه مجرد تفاعل من جانب العميل؟ وهل ينوي أن تكون جزءا لا يتجزأ من مشاريع أخرى؟

لم نعتقد أبدًا أن الآخرين قد يكونون مهتمين بتضمينه ولكن يجب أن يكون من السهل القيام به لأنه مكون معزول بالفعل ، لذلك نعم ، يمكننا جعله قابلاً للتضمين بسهولة. المكون هو React من جانب العميل فقط لأن Monaco لا تدعم العرض من جانب الخادم.

أول العلاقات العامة لتمهيد المحرر في طريقه! انظر # 1280

وهذه واحدة أخرى في # 1285 ؛-)

قريبًا جدًا يجب علينا تمكين دعم AsyncAPI افتراضيًا (أعتقد أن الميزة متوقفة حاليًا بشكل افتراضي).

مرحبا EricWittmann والجميع!

إليك واحدًا آخر يجلب: دعم التشغيل والرسالة والعملية وصورة الرسائل. انظر # 1313 ؛-)

لم يتم بعد تنفيذ جميع تفاصيل كل مفهوم بالكامل كشكل رسومي ولكن الإطار موجود.

أهلا بكم!

تم العثور على بعض الوقت في نهاية هذا الأسبوع لبعض التحسينات الجديدة: إليك PR # 1382 آخر.

يمكننا الآن إنشاء عملية جديدة ، وتعيين نوع الحمولة والرؤوس بالإضافة إلى توفير أمثلة (مفيدة الآن حيث يمكننا محاكاة AsyncAPI مباشرةً باستخدام موصل Microcks 😉)

EricWittmann كيف تقوم بتمكينه؟

بالنسبة إلى حاوية apicurio-studio-ui ، يلزمك تعيين متغير البيئة APICURIO_UI_FEATURE_ASYNCAPI على "true" (كسلسلة ، وليس منطقيًا ) ،