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

[thompson-tomo]

My thoughts would be that we could achieve a number of synergies and improve the ecosystem by bringing aligning the tool chain. However a roadmap for the dotnet eco-system should be prepared which gives each tool a clearly defined purpose/role.

For instance saunter focuses on being UI/testing tool & neuroglia on generation tool chain. That is just my quick thought on the topic

[VisualBean]

Saunter is primarily a generation tool, like swashbuckle is for OpenApi. - it doesn't deal with generating client code though - but rather document a running server.

[thompson-tomo]

Correct but one of the biggest pain points is that the generation only works for web projects and not console for instance.

[cdavernas]

This is indeed a limitation Neuroglia's solution does not have. I guess it should not be too difficult, however, to make the required adjustments to Saunter for it to work in a non-web context, but I might be wrong.

[iancooper]

I think that if we could win over the .NET community with a standard toolset, it would go a long way in making inroads on AsyncAPI adoption with that community. We might be able to get folks like David Fowler to champion its usage. The .NET community likes "clear choices" over a plethora of tools, and it likes ones that are "official." No offense to the Lego folks, who have done an incredible job, it's just the way .NET folks are (I wish it was not true). I can certainly promote to the maintainers of the other frameworks than mine (Brighter) such as Mass Transit (large in the US), NServiceBus, and Wolverine.

[cdavernas]

I completely agree with you. My take on this is that all donated or official AsyncAPI projects should be published under the AsyncAPI name to avoid confusing newcomers with multiple, unrelated project names.

[VisualBean]

I think that if we could win over the .NET community with a standard toolset, it would go a long way in making inroads on AsyncAPI adoption with that community. We might be able to get folks like David Fowler to champion its usage. The .NET community likes "clear choices" over a plethora of tools, and it likes ones that are "official." No offense to the Lego folks, who have done an incredible job, it's just the way .NET folks are (I wish it was not true). I can certainly promote to the maintainers of the other frameworks than mine (Brighter) such as Mass Transit (large in the US), NServiceBus, and Wolverine.

Win Them over to do what?
It's not like dotnet apps using EDA are being documented with something else 😅.
Saunter and asyncapi.net are pretty big in the community already.

From nuget stats so is this lib being donated.

It's not that I'm disagreeing with the notion, it just sounded like the .net devs were holding out on using asyncapi due to lack of consistent nuget authors. Which is definitely not the case.

Also I'm not sure how keen Fowler is on this sort of thing, never seen him advocate much for openapi - which has not made it into core tooling.

Would be exceedingly cool though - generally they want it in house due to licensing and tooling support, although they do work with the community (more and more) - as you might have seen with the more recent "event pipeline" issue in the aspnetcore repository, they often need some specific hooks or otherwise that requires to in source a given lib - which might piss off parts of the community. It's a balance.