Donating Neuroglia.AsyncAPI

[cdavernas]

Proposal: Donation of a .NET Solution for AsyncAPI

I have developed a .NET solution for AsyncAPI that includes:

• A code-first documentation generator
• Fluent builders for intuitive and expressive API definitions
• Fluent validators to ensure compliance and correctness
• An ASP.NET Core-based GUI for visualizing generated AsyncAPI documents
• A generic, plug-and-play client that currently supports multiple messaging protocols, including:
  • AMQP
  • HTTP
  • Kafka
  • MQTT
  • NATS
  • Pulsar
  • Redis
  • Solace
  • STOMP
  • WebSocket

All components, except for the client, provide concurrent support for AsyncAPI v2.6.0 and v3.0.0.

Proposal for Donation

Following discussions with @fmvilas, I would like to donate this solution to the AsyncAPI Initiative, as I believe it has great potential to thrive within the ecosystem and benefit from a strong, engaged community to further enhance and refine it.

As per @fmvilas’s recommendation, I am reaching out to @asyncapi/tsc_members to formally request a vote on the potential acceptance of this project into the AsyncAPI Initiative ecosystem.

I look forward to your feedback and guidance on the next steps. 🚀

---

https://github.com/neuroglia-io/asyncapi

[fmvilas]

Thanks, @cdavernas! This is a great tool. Just to clarify, you should either join as a maintainer of the tool and/or find someone who will join as a maintainer. IIRC, we need two maintainers but I'm not sure if that's a hard requirement. @derberg can clarify. In any case, it's worth having more than one maintainer.

[cdavernas]

So far, I'm the sole maintainer, but perhaps my associate or some of the contributors might be interested in stepping in?
@JBBianchi @FantasyTeddy @thompson-tomo @RainDance74

Otherwise, I'd be more than happy to welcome anyone motivated to help improve the solution! 😉

[JBBianchi]

Thanks for the mention, @cdavernas. I'd be happy to step in as a maintainer and help keep things moving forward.

[derberg]

@cdavernas oh this is interesting 🤩 can you share how is this .NET project related to https://github.com/asyncapi/saunter that was donated some time ago?

@m-wild @VisualBean @yurvon-screamo you folks are the only ones I know in the community that maintain some .NET code under AsyncAPI. Can you please have a look and share your opinion?

[VisualBean]

@VisualBean On a side note, I see that it was requested to Saunter to implement AsyncAPI.NET, which AFAIK is not part of the AsyncAPI Initiative, but belongs to Lego. Is that correct? If so, why was there a request to use/share the same models? Isn't there a potential conflict of ownership that could potentially impact Saunter?

As the maintainer of asyncapi.net (which is technically owned by The LEGO Group at least officially (I don't work for LEGO anymore, but continue to maintain it)).
I don't see a conflict happening. Asyncapi.net exists with an apache license (albeit slightly modified due to naming it 'LEGO').

The point was to align on better models for saunter (something as close to spec in terms of (de)serialisation as possible. Which I think asyncapi.net succeeded with - no use of object for example. - it's still WIP in terms of migrating though.

We just wanted to push saunter to be better

[cdavernas]

@VisualBean Thanks for the clarifications! I really appreciate the insights. My question was purely out of curiosity—I came across the repo and couldn’t help but wonder about the potential implications in terms of ownership. Hope you don’t mind me asking!

[VisualBean]

@derberg

Although fairly rudimentary (de)serialisation logic.

It does mostly the same as saunter (although they do have 3.0 support which saunter does not, yet.)

I still think it would be a cool addition to the asyncapi initiative.

[VisualBean]

@VisualBean Thanks for the clarifications! I really appreciate the insights. My question was purely out of curiosity—I came across the repo and couldn’t help but wonder about the potential implications in terms of ownership. Hope you don’t mind me asking!

No worries at all.
I've been quite explicit in terms of what the lib is and how open source works (internally @LEGO).
To keep it 'open' and generic (spec compliant (without internal LEGO bloat))

[derberg]

thanks @VisualBean for sharing a detailed review 🙏🏼

@cdavernas it doesn't matter much where the dependency is located (what org) but what is its license and project activity. I'm not very much aware of .NET world, but in JS world it is completely common to strategically rely on projects from other organization. And in this particular case, it is even easier case as we know LEGO invests in AsyncAPI usage a lot, also many LEGO speakers already shared their experience at AsyncAPI conferences. Even one LEGO guy will deliver a webinar in March I think.

anyway, let's keep the discussion here for a week or two, maybe some other folks will ask some questions. I just started the voting process on the budget so we anyway should not trigger another voting, but wait for the budget voting first.

I will ping few other maintainers that use AsyncAPI and .NET

[derberg]

pinging few other maintainers in AsyncAPI org that I know do .NET

@connil @mr-nuno @jonaslagoni @dpwdec @iancooper