Apicurio-studio: संपादक में AsyncAPI मानक का समर्थन करने में सक्षम

मैं AsyncAPI के लिए एक Apicurio दृश्य संपादक देखना पसंद करूंगा। अभी इस परियोजना में इस तरह के प्रयास के लिए इंजीनियरिंग बैंडविड्थ नहीं है। :(

@EricWittmann प्रतिक्रिया के लिए धन्यवाद। मैं इस फीचर पर काम करने के लिए कुछ समय निकालने की कोशिश करूंगा अगर यह इतना मुश्किल नहीं होगा ...

वैसे मुझे लगता है कि AsyncAPI के लिए समर्थन जोड़ना बहुत बड़ी मात्रा में काम है। पहला काम शायद इसके लिए एक पार्सर/मॉडल परत लागू करना होगा। ओएआई के लिए मैंने इसे यहां किया है:

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

तो यह शायद शुरू करने के लिए एक अच्छी जगह है - शायद एक नया भंडार जैसे asyncapi-ts-core ।

यदि आप उस तरह की चीज़ के लिए तैयार हैं तो यह बहुत अच्छा होगा! मुझे बाकी Apicurio में asyncapi समर्थन प्राप्त करने के सर्वोत्तम तरीके के बारे में सोचना शुरू करना होगा। विभिन्न UI पृष्ठों में कई विचार हैं।

इसके लायक क्या है, AsyncAPI कुछ अतिरिक्त भाप लेना शुरू कर रहा है। इसलिए एपिकुरियो में इसके लिए सहायता प्रदान करना प्राथमिकता सूची में ऊपर चढ़ रहा है। :) अभी तक कोई ईटीए या ऐसा कुछ नहीं - लेकिन उम्मीद है कि हम इस क्षेत्र में कुछ प्रगति करना शुरू कर सकते हैं।

यह खबर सुनकर अच्छा लगा, @EricWittmann , धन्यवाद। यदि पर्याप्त समय मिले तो मैं भाग लेना चाहूंगा।

FWIW, अब हमारे पास AsyncAPI 2.0.0 के लिए एक

यह दिलचस्प है, @fmvilas - सूचक के लिए धन्यवाद। हमने वास्तव में यहां AsyncAPI और OpenAPI के लिए अपना एकीकृत डेटा मॉडल कार्यान्वयन बनाया है: https://github.com/Apicurio/apicurio-data-models

वह पुस्तकालय जावा में लिखा गया है और टाइपस्क्रिप्ट में ट्रांसपाइल किया गया है ताकि हम इसे अपने बैक-एंड और सीधे हमारे यूआई में भी उपयोग कर सकें। इसमें विभिन्न विशेषताएं भी हैं जैसे पूर्ण आगंतुक समर्थन, एक साधारण परिचालन परिवर्तन इंजन, आदि ...

आपकी टिप्पणी के अधिक दिलचस्प हिस्से पर - एपिकुरियो में AsyncAPI रखने के लिए जिन कार्यों को करने की आवश्यकता है। :) :) मुझे लगता है कि अभी बड़ी बात शायद संपादक का समर्थन है। अंतत: मैं अपने विजुअल ओपनएपीआई संपादक (जिसमें सत्यापन और समवर्ती संपादन समर्थन शामिल है) के साथ फीचर समानता रखना चाहता हूं। हालाँकि, मुझे लगता है कि अल्पावधि में एक अच्छा (शायद अस्थायी) योगदान मौजूदा टेक्स्ट-आधारित AsyncAPI संपादक को Apicurio में एकीकृत करना होगा। यह बहुत अच्छा होगा और बहुत आगे तक जाएगा। मैं एक ऐसा भविष्य देख सकता था जहां टेक्स्ट-आधारित संपादक और दृश्य संपादक दोनों समर्थित विकल्प हैं। मेरे पास वास्तव में एक समुदाय उपयोगकर्ता ने इसके लिए कहा था - उनके वरिष्ठ डेवलपर्स को दृश्य संपादक पसंद नहीं था और इसके बजाय एक टेक्स्ट संपादक चाहते थे। जाओ पता लगाओ।

संपादक के अलावा, मुझे कार्यों की सूची के बारे में सोचना होगा। लेकिन बाकी सब कुछ संपादक के शीर्ष पर वृद्धिशील होगा (उदाहरण के लिए परियोजना निर्माण)।

आपकी टिप्पणी के अधिक दिलचस्प हिस्से पर - एपिकुरियो में AsyncAPI रखने के लिए जिन कार्यों को करने की आवश्यकता है। :) :)

मैं तुम्हें सुनता हूं :)

ठीक है, जैसा कि आपने कहा, चलिए कुछ आसान/आसान से शुरू करते हैं। जैसे ही हमारे पास सहयोग करने के लिए कुछ बैंडविड्थ होगी, मैं आपको बता दूंगा। धन्यवाद!

सहयोग शानदार होगा, निश्चित रूप से। इस बीच, यदि आपके पास AsyncAPI संपादक को अन्य अनुप्रयोगों में एम्बेड करने के तरीके के बारे में कुछ दस्तावेज हैं, तो शायद मैं POC के रूप में बहुत जल्दी कुछ दिलचस्प कर सकता हूं।

मैं यहाँ खेल के मैदान में मिले संपादक की बात कर रहा हूँ: https://playground.asyncapi.io/

मैंने अभी तक उस पर ध्यान नहीं दिया है - इसलिए मुझे यकीन नहीं है कि इसे अन्य अनुप्रयोगों के भीतर आसानी से लीवरेज करने के लिए बनाया गया है, लेकिन यदि ऐसा है तो उम्मीद है कि आयात और उपयोग करना मुश्किल नहीं है। यह Apicurio Studio के भीतर AsyncAPI समर्थन (कम से कम प्रारंभिक) का दावा करने की दिशा में एक लंबा रास्ता तय करेगा।

हाय @EricWittmann ,

मैं आज कुछ समय यह जांच करने में बिताता हूं कि AsyncAPI के लिए ग्राफिकल संपादक को जोड़ने की लागत क्या होगी और हाल ही में एक परिणाम की शुरुआत होगी। नीचे स्क्रीनशॉट देखें - मैंने ओपनएपीआई के समान संरचना को फिर से बनाया है और हमारे पास पहले से मौजूद कोड संपादक को जोड़ा है, इसलिए हमारे पास पहले से ही फीचर समानता है जो आज हमारे पास है। मैंने पहले जोड़े गए AsyncAPI उदाहरण से शुरुआत की है।

कुछ विचार और प्रश्न जो मैं साझा करना चाहूंगा:

• कार्यान्वयन पक्ष पर पहला: नया संपादक घटक पहले से मौजूद था और मैं मौजूदा घटकों को उनके AsyncApi* समकक्ष में डुप्लिकेट करके इसका अनुसरण करता हूं। अधिकांश समय केवल OasDocument को AaiDocument , यह इतना सुंदर नहीं है ... हालांकि मैंने अभी सतह को खरोंच दिया है और 2 विनिर्देशों के बीच और अधिक महत्वपूर्ण अंतर होंगे ... क्या आप इस तरह से रखना और घटकों के 2 स्वतंत्र सेट रखना पसंद करेंगे या कोड के साथ बहुत सारे if document.isOpenApi() या if document.isAsyncApi() होने पर भी पारस्परिक करने का प्रयास करेंगे? तुम क्या सोचते हो ?

• 2 प्रक्रिया पर। जैसा कि आपने पहले कहा, यह एक बड़ा प्रयास हो सकता है ... तकनीकी रूप से कठिन नहीं बल्कि लंबा और सावधानीपूर्वक ... इसलिए मुझे नहीं लगता कि मेरे पास धैर्य होगा और न ही कुछ भी करने से पहले पूरे विशेष संपादकों को लागू करना संभव है। मैं इसे एक पुनरावृत्त कार्य के रूप में देखना चाहता हूं जहां मैं उच्च प्राथमिकताओं से शुरू होने वाले कुछ टुकड़े भर सकता हूं ( Channels , DataTypes , Messages , Examples ;- )) फिर कम प्राथमिकताओं ( Servers , Traits वगैरह...) पर जा रहे हैं। तुम क्या सोचते हो ? क्या कई पुल अनुरोधों पर कार्यान्वयन को विभाजित करना ठीक रहेगा?

मुझे मदद करने में वास्तव में खुशी होगी क्योंकि आपने देखा होगा कि Microcks अब AsyncAPI मॉकिंग (और कुछ हफ्तों में परीक्षण) का समर्थन करता है। तो यह एपिकुरियो का समर्थन करने के लिए एक गेम चेंजर हो सकता है और आधुनिक एपीआई स्पेक्स की प्रमुख शैलियों को कवर करने की अनुमति देता है।

सीसी @fmvilas ;-)

सबसे पहले - Microcks में AsyncAPI समर्थन जोड़ने पर बधाई! मैंने देखा कि हाल ही में जोड़ा गया था।

इस बारे में मेरे कुछ विचार हैं। पहला यह है कि मुझे लगता है कि अगर यह तकनीकी रूप से "आसान" है तो AsyncAPI Playground संपादक को Apicurio Studio में एम्बेड करने का प्रयास करना समझ में आता है। :) यह एक त्वरित जीत होगी और हमें Apicurio Studio में AsyncAPI दस्तावेज़ों को संपादित करने के लिए उचित "बीटा" समर्थन देगी।

उसके बाद, हम एक दृश्य संपादक बनाने पर ध्यान केंद्रित कर सकते हैं।

(1) कार्यान्वयन के बारे में आपके प्रश्न के लिए - मुझे लगता है कि घटकों को डुप्लिकेट करना और उन्हें AsyncAPI फिट करने के लिए संशोधित करना अल्पावधि में सही दृष्टिकोण है। इसका कारण यह है कि दो संपादकों में घटकों को साझा करने के लिए बाद में रिफैक्टर करना काफी आसान है, लेकिन इससे भी अधिक यह है कि हम किसी बिंदु पर पूरे स्टूडियो यूआई को रिएक्ट में फिर से लागू करेंगे। इसलिए वर्तमान कोणीय कार्यान्वयन में हम जो भी बड़े प्रयास करते हैं, वे व्यर्थ हो जाएंगे। कुछ तेजी से करने के लिए बेहतर है क्योंकि इसे बाद में फिर से करना होगा।

(2) मैं सहमत हूं कि प्रयास तकनीकी रूप से कठिन नहीं है, बल्कि लंबा और सावधानीपूर्वक है। :) मुझे लगता है कि कार्यान्वयन के लिए कई पीआर में विभाजित होना समझ में आता है - उम्मीद है कि हम कई योगदानकर्ताओं में भी काम को तोड़ सकते हैं।

@fmvilas क्या संपादक AsyncAPI खेल के मैदान के खुले स्रोत में पाया जाता है (मैं हाँ मान रहा हूँ) और यह भी आसानी से Apicurio Studio जैसे अन्य उपकरणों में एकीकृत होने में सक्षम है?

(यदि हां दस्तावेज़ीकरण के लिए कोई संकेतक कमाल होगा)

धन्यवाद @EricWittmann !

मैंने पहले AsyncAPI खेल के मैदान पर एक त्वरित नज़र डाली थी, लेकिन ऐसा लगता है कि NodeJS में सर्वर-साइड घटक हैं। तो मैं सोच रहा था कि एकीकरण इतना आसान नहीं होगा ... इसलिए मैं संपादक का रास्ता तलाशता हूं ;-)

मुझे सप्ताह के अंत तक इस पर कुछ और समय बिताने में सक्षम होना चाहिए... अगर यह आपके लिए ठीक है, तो मैं अगले सप्ताह की शुरुआत में पहला पीआर सबमिट करने का प्रयास करूंगा। यह संभव होना चाहिए कि मुख्य सूचनाएं संपादन योग्य हों ( Version , Contact , License और Tags ) साथ ही Channels का केवल-पढ़ने के लिए पूर्वावलोकन

यह खुला स्रोत है, आप इसे यहां पा सकते हैं। हालांकि, हम स्वत: पूर्णता के साथ एक बेहतर तरीके से काम कर रहे हैं, गलत लाइनों और स्तंभों को "रेखांकन" करके संपादक में ही त्रुटियों की सूचना दी गई है। यह वास्तव में AsyncAPI हब पर देखा गया है, जो अंततः खेल के मैदान को बदल देगा। यह अभी तक खुला स्रोत नहीं है, लेकिन बहुत जल्द, निश्चित रूप से वर्ष के अंत से पहले होगा, और यह मोनाको संपादक (वीएस कोड को शक्ति देने वाला संपादक) का उपयोग करके रिएक्ट में किया गया है।

लेकिन यह देखते हुए कि आप एपिकुरियो स्टूडियो में एंगुलर का उपयोग कर रहे हैं, मुझे यकीन नहीं है कि यह मददगार होगा। मैंने सुना है कि रिएक्ट और एंगुलर को मिलाना संभव है लेकिन ईमानदारी से कभी कोशिश नहीं की।

धन्यवाद @fmvilas - हम अंततः रिएक्ट में बदलने जा रहे हैं (यह प्रगति पर है)। क्या नए AsyncAPI संपादक को किसी सर्वर घटक की आवश्यकता है या यह विशुद्ध रूप से क्लाइंट-साइड रिएक्ट है? और क्या इसे अन्य परियोजनाओं में शामिल करने का इरादा है?

हमने कभी नहीं सोचा था कि दूसरों को इसे एम्बेड करने में दिलचस्पी हो सकती है, लेकिन इसे करना आसान होना चाहिए क्योंकि यह पहले से ही एक अलग घटक है, इसलिए हाँ, हम इसे आसानी से एम्बेड करने योग्य बना सकते हैं। घटक विशुद्ध रूप से क्लाइंट-साइड रिएक्ट है क्योंकि मोनाको सर्वर-साइड रेंडरिंग का समर्थन नहीं करता है।

अपने रास्ते में संपादक को बूटस्ट्रैप करने के लिए पहला पीआर! #1280 . देखें

और यहाँ #1285 पर एक और है ;-)

बहुत जल्द हमें डिफ़ॉल्ट रूप से AsyncAPI समर्थन सक्षम करना चाहिए (यह सुविधा वर्तमान में डिफ़ॉल्ट रूप से बंद है, मुझे विश्वास है)।

हाय @EricWittmann और सभी!

यहाँ एक और ला रहा है: ऑपरेशन, संदेश, ऑपरेशनट्रेट और मैसेजट्रेट समर्थन। #1313 देखें ;-)

प्रत्येक अवधारणा के सभी विवरण अभी तक एक ग्राफिकल रूप में पूरी तरह से लागू नहीं हुए हैं लेकिन रूपरेखा है।

नमस्ते!

कुछ नए संवर्द्धन के लिए इस सप्ताह के अंत में कुछ समय मिला: यहां एक और पीआर #1382 है।

अब हम नया ऑपरेशन बना सकते हैं, पेलोड और हेडर प्रकार सेट कर सकते हैं और साथ ही उदाहरण प्रदान कर सकते हैं (अब उपयोगी है कि हम माइक्रोक्स कनेक्टर के साथ सीधे AsyncAPI का मजाक उड़ा सकते हैं)

@EricWittmann आप इसे कैसे सक्षम करते हैं?

apicurio-studio-ui कंटेनर के लिए आपको APICURIO_UI_FEATURE_ASYNCAPI पर्यावरण चर को "true" (स्ट्रिंग के रूप में, बूलियन नहीं), @ alizard0 पर सेट करने की आवश्यकता है ।