Start collecting AsyncAPI use cases

[derberg]

Mission statement 😄 "AsyncAPI Community needs a set of real stories from end-users on how they use AsyncAPI in real life".

Now, what does it mean? and how to get it?

Who needs use cases

I noticed there are different ideas popping up, also different community members need use cases for something different. Some examples:

• @smoya and @jonaslagoni are focusing now to work on AsyncAPI 3.0 and they need lots of different examples to understand better the ecosystem and see how their proposals may affect others
• me and @fmvilas need it for maintaining the spec, to always make sure every RFC is checked against existing use cases
• AsyncAPI end users that learn AsyncAPI need stories from other end users. They not only need official docs and official recommendations but also need to learn how things look like in reality
• community members that work for vendors that build tools on top of spec, like for example @nictownsend want to learn how end users us the spec so they can provide even better tools
• official AsyncAPI tools maintainers like @boyney123 , @magicmatatjahu or @Pakisan need info on how people use AsyncAPI so they can improve existing tools and create others

So yeah, use cases are not an option, we simply must have them.

Current ideas in the community

Different ideas that I know about on how to collect use cases:

• different people from time to time ask for use cases in Slack
• conference
• @Barbanio suggests Webinar
• during the last SIG meeting @nictownsend mentioned meetups and @boyney123 picked it up with this discussion
• @doc-jones opened up this PR with a great idea to make it much easier for people to provide us with use cases easier, with some suggested structure
• I started chatting with @doc-jones that we need more direct approach, go directly to people and ask for use cases

My point of view

If we want to succeed with this under AsyncAPI Initiative umbrella, we definitely need to synchronize and coordinate together, as a group.

Why? to not duplicate efforts and to not confuse the community

Best solution

There is no such solution. We need to be flexible. On one hand, we want radical transparency and do all in public, but we also need to respect that now everyone feels comfortable with talking about everything in public:

• some people just for personal reasons prefer to have a private meeting, with a smaller group of people, and share use cases only in written form (and we should respect that)
• some people because of their company policies can talk but before anything can be submitted, they need their manager to approve it

IMHO this is normal and should be allowed, and most probably because of nature of EDA can be a case in majority of situations.

So I just want to express that: we cannot expect people on their own will come and share their stories, we need to ask them to do it and support them as much as we can.

might be that in future once we have more use cases, people will be less shy and will contact us, so we do not have to look for them on our own

Solution

• We need clear instructions for end-users that are ok with full public info sharing. Like almost a self-service:
  • where use cases are displayed
  • how we maintain them
  • how to provide them (issue template)
  • who owns it and helps
• We need a process for a more "proactive approach", where we identify people that represent end-users and approach them to gather use cases
  • in a group, we coordinate who talks to who (so we do not duplicate efforts)
  • we have folks that want to regularly participate in interviews with end users. I already know @doc-jones from Postman and @nictownsend from IBM wants to actively help. I'm pretty sure folks like @jessemenning from Solace or @Ugbot from Ably (and I bet others) would like to join and would also benefit.
  • interview cheat sheet
  • clear approach for "public interviews" and "private interviews"

Results of work

Full-blown package, result of use case research would be:

1. official example based on the use case
2. Use case story published under the not-yet-available-section on the official website
3. We should encourage interviewed end user to write a blog post about their experience on their blogs, their domains to increase credibility for the use case (example from eBay)
4. A public presentation, can be Webinar, can be Meetup. I don't think it is important now what will be the name, and how we organize it. More important is to actually start getting use cases and grabbing contacts

Minimum success is when we get 1 and 2 ❤️ as we will already cover all the needs I described in first sections.

Conslusion

I strongly believe we cannot expect people will come on their own and share their stories, for the sake of the community we need to proactively push for it together, go forward, offer our time, interview, guidance. Sometimes even we will have to offer that we will describe the use case and that they just need to sign off.

I would ❤️ if we could all do it really together as a group supporting each other efforts. Do we need to have a sync-like online meeting about it? lets do it!

any commitments? Does anyone want to actively participate here? Share your availability 🙏🏼

[fmvilas]

I'd love to participate in this. Count on me. I sometimes get exposed to companies demoing how they're using AsyncAPI. I usually don't help companies unless they are platinum sponsors (I ask them to become if they're not yet) but maybe I can offer some help if they give us this, a use case to tell the story 🤔

[nictownsend]

This is an amazing writeup, I think it covers all the aspects we've been considering.

I really like having a "use case" section of the website with a detailed case study, that would be brilliant to help new adopters start to visualize how to use the spec.

Reiterating that I'm very happy to conduct interviews and create use cases (along with helping curate/shape directly user contributed use cases)

[jessemenning]

Solace would definitely be interested in providing the use case of implementing AsyncAPI in Event Portal.

I would love to get some of our end clients who are implementers to contribute as well. However, I ran into significant resistance when trying to recruit clients for the AsyncAPI conference, and fear it will be the same situation here. This is particularly true when using company logos.

I will definitely continue to push, as there are real benefits to the client, Solace and AsyncAPI.

[derberg]

However, I ran into significant resistance when trying to recruit clients for the AsyncAPI conference, and fear it will be the same situation here

I understand your concern, I made a public statement yesterday during SIG meeting that we are flexible and especially in case of a few first use cases we can always negotiate something in exchange, like some "internal employees only" presentations, maybe a few hours of consulting. So yeah, nothing specific, we just need to discuss.

[abelgomez]

Regarding use cases, we have recently published a scientific paper in the Software and Systems Modeling journal (also available for wider audiences in @jcabot's modeling-languages.com blog) on our experience using AsyncAPI and the tool we already presented in the AsyncAPI 2020 conference. Basically, in this use case we report in the easy of use and productivity improvement achieved by our code generation tool (also including a modeling IDE which allowed to bootstrap an AsyncAPI spec) that in the end generated Java code (which may relate to #189).

BTW, we plan to continue working on this research line on our current research projects, so more use cases will probably come. For this reason, we're also keeping an eye on #193 and a possible Ambassador program 😊.

[Barbanio]

This is so cool! I think your experience and vision as developers and researchers is very enriching for the AsyncAPI community.

[quetzalliwrites]

I love this!!! thank you for sharing :)

[fmvilas]

I'd also love to note that I'm also looking for people who didn't start using AsyncAPI yet and are evaluating it or are about to evaluate it. Happy to offer an online workshop or webinar in exchange.

And also, negative feedback about why you didn't end up adopting AsyncAPI is also very useful. Even if it's not an AsyncAPI's fault, we want to better understand what's the context in which we're playing.

Just in case you're reading this and don't know how to get in touch with us, join our Slack workspace or email us at info@asyncapi.io.

[derberg]

ok folks, I drafted some initial proposal for the share of the case study basing it on first real official case study from Adeo

asyncapi/website#921