You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The adoption of an architectural decision will determine the possible vector of development for the near (or long) time
Screenshots
How could it be implemented/designed?
The current architecture proposal is shown in the picture.
The main ideas:
separating the implementation of document generation from the delivery of the document in the right form to the right place
relying on schema from the LEGO library
maintaining the ability to migrate (ideally seamlessly) users from an existing version
full openness to new ways of generating documents (both within the framework of our new functionality and within the framework of implementation at the user application level)
full openness to new scenarios for using the generated document (both within the framework of our new functionality and within the framework of implementation at the user application level)
I did not aim to reflect the architecture of the current implementation.
On the contrary, the main purpose of this is to turn the library into some kind of platform, open both to implement new ways of converting code into asyncapi document, and to further obtain this document in the desired form.
Please note that this issue does not address the issue of nuget package delivery. Here we will not define a possible list of them or anything else. (However, I believe that adopting such an architecture will greatly simplify this process in the future)
Why do we need this improvement?
How will this change help?
The adoption of an architectural decision will determine the possible vector of development for the near (or long) time
Screenshots
How could it be implemented/designed?
The current architecture proposal is shown in the picture.
The main ideas:
I did not aim to reflect the architecture of the current implementation.
On the contrary, the main purpose of this is to turn the library into some kind of platform, open both to implement new ways of converting code into asyncapi document, and to further obtain this document in the desired form.
Please note that this issue does not address the issue of nuget package delivery. Here we will not define a possible list of them or anything else. (However, I believe that adopting such an architecture will greatly simplify this process in the future)
🚧 Breaking changes
Yes
👀 Have you checked for similar open issues?
🏢 Have you read the Contributing Guidelines?
Are you willing to work on this issue?
Yes I am willing to submit a PR!
The text was updated successfully, but these errors were encountered: