AsyncAPI Community, 11 Jun 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: AsyncAPI SIG meeting 9 (June 11, 2019)

Description

This is the recording for the AsyncAPI Special Interest Group (SIG) meeting #9.

Attendees:
- Andrew Snodgrass
- Fran Méndez
- Łukasz Gornicki
- Marc DiPasquale
- Rubén Hervás
- Scott Vorthmann

Moderation:
- Fran Méndez

Agenda:
- Review: An application is not an API in EDA (Scott)
- Review: Unclear / odd semantics of multiple servers (Scott)
- Review: Application id should not be mandatory (Łukasz, Fran)
- Fran on review and launch dates.
- Q&A

A

Cool, so that's a go briefly point by point on what do we Walter? What we want to talk today so Scott, so you use got your architect that tip code right, correct me if I'm mistaken, okay, cool, so Scott has a to review issues here. He wants to to talk about, and one it's called. The title is an app is not an API in EDA. Even juvinity tectors, which actually is issue, is something it's something different, I guess right from the exclamation. Is it's not so much about it?

A

B

No problem and.

A

Then the servers semantics so we'll talk about it later as well. Also.

A

Lucas and I wanted to as part of the Lucas review from from s. Ip is about the application ID that it should not be mandatory, and it's actually something that I also wanted to ask you how you say it so we'll talk about it. What about it later?

A

Also I would like to communicate to all of you the dates for when are we closing the the time for reviews and old stuff, and when are we launching the version 2 and then QA? If you have something, to do, I mean Q&A, it doesn't have to be at the end as long as you have questions just just interrupt, let's make it a nice chat, not just instructor right talk or anything so Scott do you want to start with an app is not an API. Yet maybe okay.

C

Sure so it down to the the way that I've been thinking about.

C

Sort of as api's- and you know in some of our internal work and so a decent KP I expect I found very appealing in terms of it was timely. You know when I find found out about it. It documents pretty much what I want to document the the only challenge I saw was, you know, I'm really trying to the way I see it is generally with a with a pub/sub architecture or event-driven architecture.

C

The the event stream itself sort of is is the API right. So it's it's not like a little usual provider, consumer sort of arrangement that we have with rest, because, obviously you know many publishers, you're getting many subscribers and in a sense, I, don't want to be careful with the term application, because I know it has a very precise meaning in the spec, but let's say solution the solution that you build around this this this event bus. It is a single, cooperating solution and the event bus serves serves a very central role there.

C

So I'm really just trying to give it that central role really so I think async API. If we, if we allow the basically the omission of either publish or subscribe, it does exactly what I want, which is to say what are the messages that are following and where are they fall?

C

So that's sort of in a nutshell: I was a bit more verbose in the.

A

Review disruptions, I've seen something you're in your review. You said self documenting channels, so you could have an option like instead of having publish and subscribe as a bird, you have it, you have another property called role, maybe which can be probably subscribe or or missing it. So in case it's missing, you said it's a self documenting channel, but contact in the of the whole document is the applications. That's what I don't get. If we do this, if we just don't specify row, what doesn't what does it really mean.

C

At that point, the application is in some of you in some of the samples that I was writing up when I was working on this review, I even changed the title and the ID to really you know, you're changing the focus, your application isn't unless you're talking about the broader, the larger thing, the the solution, that's composed of many different, cooperating processes right this.

C

This is you're documenting an events channel or an event stream, or you know, call it what you will so the that's the sense that the the idea that I still need an application ID is maybe less critical. The idea that I'm talking even about an application. The point is I'm, not I'm, not talking about any single application. I'm talking about you know the way all of the applications communicate. Okay, your concern.

A

Is because you want to document the whole, that's in it the whole architecture. Again, you probably have one single document or the whole architecture or.

C

I may have many, but this this this is one piece of the DES of the documentation for the whole architecture. Yeah.

A

You may you may have many, but you simplifying it. A lot like it would be possible to have just one document in the whole thing right, yeah.

C

And it's it's, it's actually more than just documentation so and I think I mentioned this in the review. You can imagine implementations of publishers and subscribers that are aware of async API or you know this means of configuring them, and maybe they don't support all the possible.

C

You know that obviously can't support all the possible extensions for different kinds of servers and protocols etc, but they may support a few and essentially, you've got configurable code and this could serve as actually the live configuration that that's driving the design, time experience or the runtime experience or whatever. So it's you know, hopefully it's more than just documentation.

A

So this is this is something that that we tried on bashing one to have a single document and document the channels and actually, in version one. The document was not represented in the application. It wasn't, it wasn't specified, so you could use it or whatever you want and I tried. This approach, like documented the whole thing with the.

D

A

Place right but then a problem arose that I did that I think I didn't think about, and it was that imagine say you have an async API file that actually represents a broker. Maybe if you want to call it like it represents the broker and you want to generate code for a single application.

A

Then you don't have context of which application is actually subscribing or publishing to a certain channel. You only have the list of of channels, and you have publish and subscribe in all of them, because every channel will have someone bouncing. Is someone subscribing that voice right right.

C

I think that there may be a difference friend in that I'm not trying to document the entire solution. I'm trying to document one channel communication right really is the the the scope of the the async API doc really does focus down. So you know, I wouldn't expect to use multiple servers. I wouldn't expect to see multiple channels. I actually had a version of this, where I did sort of more violent change to the spec and I figured. That's, that's, probably not appropriate at this stage, so I ended up saying.

C

Well, let me make sure I can do what I. The key thing that I need to do, which is to you, know, eliminate the the requirement to say publishers subscribe, and even that I mentioned this in the in other thoughts. You know, I can always work around this simply by putting in publisher always or something like that, and just so it's it's really about making the syntax work me for the use case. I have in mind well.

A

Hopefully, you didn't have to do that. The thing is one of the things that we were thinking for person to or post version, two is actually having separate specs, meaning specs, that King act as organ function as libraries.

B

A

Of an async API specification, it was meant initially for for schemas and for messages, but it might make sense to have libraries of channels. Okay,.

B

A

Separate document where you document all the channels like- and this is the message that it's gonna be flowing in this in this channel I- don't know if it's gonna be publish and subscribe, I, don't care about the birth right, just channel and immediately inside you see that message definition.

A

Maybe it's it's it's a it's a good idea to to put it there as a separate specturm inspect that then I think API spec in reference, this library file right so.

C

That's fine, that's that's it! That's a reasonable approach! I'm.

A

Saying this because then we tend to think on eccentric architectures, but then that's not always the case. For instance, we have also also find server with what sockets, for instance, and with HTTP streaming API is, for instance, like you know you, you request and leave the the connection open and you start receiving server sent events. So in this case the channel is just one right: sister: well, not necessarily the channel in the case of WebSocket.

A

Yes, you only have one channel in the case of API HTTP streaming API, you can have many which, which are a mapping of the paths right.

A

So that's why I'm trying to do so. Actually, I think I have to pay for.

C

A

Because when I was deciding where to put the focus on having it here, right, you have it. This, like I, was thinking on topics, processes and messages, and everything was the relationship between the three of them. Is a many-to-many right and I thought: okay, because I have the I had this thing felt like what? If we put the focus on the topic on the channel right and then we document everything around it, uh-huh yeah, but that day it.

C

Looks awkward for clients and protectors and I didn't talk about WebSockets, etc, because I don't have enough knowledge of how.

A

I came up with with the idea of keeping it as focusing on the application, because it's for two reasons it's easier for people coming from open API, like your mindset, is on the application, let's say you're on the process right and and also because then you can augment it with many other features like how to deploy the application with X, whatever I know.

A

This is not part of the spec, but many people are actually using it for this, like they want to define what the application publicist and subscribe, and also how to how to are aware, the github repo, how to deploy it.

A

Whatever information about the CI CD pipeline, because it's a single application, people think about okay, let's put everything here, so it has more use cases right. This single file will have cool, have more use cases, even though it's not about api's anymore, because it's about deploying and CIC and all this stuff. That's.

D

A

Many so much since under I think API spec right, but that's why that's why we have the other extensions, so people can actually do these kind of things.

A

So I think I don't know what would you guys guys think.

A

Having this idea of a separate document, that's actually a library. This is this was actually proposed by by mules of guys, because in Rummel you have the concept of Rummel libraries, so you can move certain pieces and make them reusable when.

C

I was looking through the getting started. You you make reference to the shared messages right yeah, using a raft to link to the message, and but of course, with the perspective I have. What stood out to me was that the channel and the server were still redundant in and and really with this perspective, you end up with virtually nothing but identity, and you know you have a name and an ID in a description and you say I'm a publisher and everything else is a reference right.

B

C

You go if you go. I actually went through okay. What? If I made the server a ref- and you know I- checked the spec and I make all of these three things rest and then I said: why am I making three things or a fight? I just want to ref yeah? Well, actually, that's there we go yeah.

C

So the the point is it if you're using async API in the way I'm intending to you, you may not use it at all for the applications, because there's there's almost nothing there right, you might generate code for the applications. You might generate subscriber code, you might generate publisher code and that just becomes an argument when you, when you you know, take in the document and say what am I generating right.

C

So it's I think I. Think the lesson for me is as you as you talked about the deployment approach and the things that people want to do with respect as us as in in specifying this, you want to sort of say, stay fairly agnostic about the semantics in many ways right because you know I I'm, not gonna use it for deployment. Certainly- and you know I- wouldn't thank you if you put deployment semantics into it right, so you know that's a that's a bit of a tightrope.

A

To walk I know, I, know what you mean yeah the thing is I, don't want to put just to be clear: I don't want to put the, for instance, deployment semantics on this paper, because I don't I understand that this is not API.

A

Lifecycle and but people use this X extensions to put information there. That's that's what I would say so probably so. The concern is that every application then will have the same set of not the same, but a list of topics or channels. Sorry, you don't want to be repeating all the time. The same thing right this reminds me.

A

Trait the traits feature that we added in version 2, which is not possible to use it on on channels a channel level. Maybe we sould make it possible to specify a trait a reusable piece somewhere else, which is a list of channels right and then reference it from channel list.

A

Sorry I will have to think about it, but maybe.

C

The Box you in the corner here, as I, said you essentially I I I brought these concerns to Raji I know just in terms of internal typical perspective, and could we use it and so forth and she suggested that I share them. So it's it's all up to you and we're not gonna I'm, not gonna, throw down our toys and stop out.

C

If, if you don't do it and honestly in in our use, we probably wouldn't even have an async API doc for the applications right, because you know so whether or not we can reference from there to the central thing, we're really gonna. You know we're gonna have our own artifacts that are referencing this as a configuration artifact. That's.

A

That's another use case that I find like people telling me our source of truth is gonna, be the async API file. It's gonna be something else. Yeah.

A

C

As far as I'm attorney, you know, you know where you go with. This is totally up to you and you know we can. We can yeah.

A

I know but I want to you know: I want to get feedback from from you folks and get opinion, and so it's not just a one-man, show right, saying: hey yes, this now I want to be as open as possible and and and yeah and when every something makes sense, why not write I? Do lots of mistakes all the time? So please correct me if I'm doing something bad, someone moving forward, maybe to the servers semantics. Maybe it's something similar! It's a similar concern. So, okay.

C

And it may end up just being wanting to change the wording in the getting started document. I think it's related to that notion of using these assets as deployment artifacts, which you know, is something that didn't occur to me. So the the idea of saying well I need to put multiple servers in there because I'm going to document my.

C

My different deployment environments that really didn't ring true for me, so I just wanted to provide that feedback. I'm I'm sort of wrestling with you know the the reason swagger has succeeded. It's got an easier time, quite honestly, right because there's a clear orientation, there's an API provider and an API consumer, and it's it's very clear what you can do with a swagger right and if it's got enough information you can use it and generate code or Drive code and hook up to that server and start interacting.

C

It's a little bit more challenging to give that character again in an event-driven world, because these these brokers aren't always open to the Internet. You know various reasons so so that was just really it I struggled with what is this really gonna mean if you Tran hand me your API, doc and I'm supposed to now interact with that right?

C

Is it useful for me to have your your QA and your a dev et cetera, no I, you know I would expect to have you know if I were a dev engineer, I'd get one version. If I were a production engineer, I get to you know the live production version.

A

And it would only have one server.

C

And I, don't have to you know, figure out which one to use.

A

Yeah, when it's when it's uh when it's about generating code, for instance- and this is something that I already suffered- and this is true you're right when you want to generate code from an async API file, you have to choose which server you want to generate it for right.

A

Well, or at least you need to be clear on what what every server means like, because one is development, the other one is staging and the other one is production, for instance right, but some other people who might released three different brokers with zones, and they are all production Prince's. Yes,.

C

A

Ticks on the servers are not clear. That's true. Yes,.

D

A

Way to you know, this is gonna be development. This is staying. This is production, maybe.

C

They can't be I, don't know, that's yeah.

A

The thing is the reason that they they are in the right, for there are two reason is just to make it the same as an open API, so things are reusable or more or less reusable, which might not mix might not make more sense anymore, sir, because the server object is already different, so yeah.

A

And also it also because on the when generating documentation, you might want to have the three servers listed in your markdown or in your HTML okay. This is because you can have a description right. This is a development server. This is a stays every server or whatever so yeah. But yes, it's it's. It's it's a pain in the ass when you're in generating code having to specify which broker you want to connect to server'.

D

A

Otherwise, or and you're generating, this is fine, but for instance, when you're using it as part of SDK, like you say, for instance, you who could hook it up into a server async API file in conserver or into an application that would also configure itself from the async API file. Then you have to select yeah.

C

A

Right I suspect.

C

Again in in those use cases, you know.

A

B

Don't have multiple servers anyway, right.

C

The files will will be in alignment with the use case. You know whoever's using it. So I think this in many ways. This is this. This review is kind of working at odds with my earlier review, because my earlier review is arguing that you know don't be too opinionated about the semantics of above async api with with in it with an application to focus, and this one is saying well, if you're going to be opinionated, then the server semantics are weird so again, I just wanted to provide the feedback.

C

I think I agree with you in any case that multiple servers are necessary again in the spirit of the prior issue, to to remain open to different semantics and different interpretations. A.

A

Way of tagging servers to mean something.

A

Stage in the production, so it actually has it. They're like this is production.

A

And also yeah, and also have to be able to do some kind of relationship between the service I thought it was really complicated.

A

C

Else that occurred to me, sorry, the generally, when you're, when you're generating code, you know you would rarely actually bind on a URL right. You would, in the hard code a URL into the code typically anyway, that would be late bound injected as an environment variable or something so, for instance, if you had three servers and they all had the same protocol, then you know what kind of code to generate, and anyway the or.

C

So I wonder if that argued is for a little bit more. You know, rather than having three servers that have the same protocol have one server that has three URLs or you know something like that. I know that gets into a whole rat's nest of you know. How do you document the configuration of this broker versus that WebSockets, etc? So yeah I.

A

Always fear of counting to match the specification to generating code or during the contagion, or you know, to one a specific yeah.

D

A

That you can do with respect actually I like to think of the spec as like a book rag, do you read a book and you understand something, and then you can do whatever you want with this information.

C

A

But at the same time, I want to I want to think about it like okay, it sells for a purpose right.

A

I have enough information here, I have enough information here and say, and.

C

I think that's the right idea. You you have to let the community, you know, build their own practices around it and maybe maybe that will align in some particular direction and three oak and can be more targeted right, but yeah I think you have the verb approach so again, I I, don't I'm not advocating for any serious change here.

C

Unless it is more discussion of this, you know. That's maybe one thing that's missing from the collateral content around async API is you know, statements that you just made about which we were intentionally trying to be less opinionated about. You know the use cases for async, API, yep, okay,.

A

So maybe to a beer somewhere.

A

C

The worst kind of work I know when you're trying to stop with what you're not documenting.

A

Danny anyone has something to to say you're all very quiet today.

B

I've been thinking about, maybe we should have some sort of actor modeling, an actor does different things uses different servers, so an actor would use a particular server or they would publish only or they would subscribe to a channel. So there's there's no, who in this document there's no actor? That's what I've been thinking about and.

A

By actor you mean this will be, for instance, a server yeah.

B

An actor could be a server, an actor could be client.

A

Service or application or process, so actually, if I understand correctly, what you mean by actor is is, is a current focus of the spec of the question, so the whole document represents an actor just one.

B

Actor though I'm talking about representing multiple actors within a document, okay,.

A

So having like a list of async API definitions, maybe I.

A

Thought about something similar with API stop Jason from killing, and it might be interesting to have something not only for async API, but also for REST API is and for other kind of API. They have a document where you can list so here. Here's this application, here's this REST API here is event-driven application and from there you can generate your map of your architecture. Friends, right all the definition, although the day that you need I'm, not sure, I'm, understanding correctly, if I'm getting it it's what the main over or not correctly, I'm I'm, not.

B

While this, this could sort of be hacked on to the existing specification using the extensions, you could use extensions, for instance, to mark a publish entry as only for servers and to subscribe only for client. Oh no, you could do it at act.

B

Funny for a subscribe or X server only for a publish or something like that or you could also I guess for a server I guess you could stick extensions there. You could have an extension that says: X actor, Alice or X actor, Bob yeah.

A

The thing is same thing that will work only for client-server communication, but in the case of broker everyone is a if your service is publishing and subscribing. Maybe I don't know.

A

So that the the one, the one saying that your your service or your replication is, is actually a publishing actor. Let's say it's the published birth I, don't know if you know bro correct actor, it would make sense, but.

A

But I do I, do see what you mean on the princess on the client-server model, something like yeah, this is published. Operation is only for clients right, and this one is only for first servers.

A

But that kind of breaks the the purpose of the of the spec context of the spec, because the context is a single application right.

A

I, don't know so if you define an application, it's always gonna, be a server or is always gonna be a client. You know what I mean yeah.

B

And yeah that kind of uh yeah I'm just saying it could be both if you wanted it to and what.

A

Ladies faces yeah depends on the perspective, like we have a several application that that serves WebSocket connection. This could be the server of a front-end application, for instance, that could be the client of another of another server right.

A

Yeah, probably I think this is a good use case for my standardized extension that we're gonna create an extension registry. So maybe you want to create this whenever we have it as a standard extension, and so people can use it and, depending on the use cases that we see people, we see people using it, we can probably incorporate it owns it into the cells like this, because right now, I'm not sure.

A

I mean it's a it's a it's a great idea, I think, for instance, I know it would be easy. It would be easier to map.

A

To create graphs of communication, because you know if this, if this node is the server, is acting as a server, it's acting as a client.

A

Anything else went to add before me. We move forward. You.

A

Now very shy today.

A

Cool so, as per my conversation with Lucas Lucas I have to crunch his name correctly,.

A

So I don't know, I think you all have seen that there is an ID property at the root level of the document, and it's mandatory right now well I'm clear with my opinion here, but I want to know. Yours I think it should not be mandatory because and I and I did it. I'm gonna explain why I did it mandatory in in the first time and the idea was to make it clear that the scope of those of the document is a single application right and not many, because I saw people using the application.

A

Sorry, the document to document many applications and then you end up with this problem of who's, subscribing and who's publishing right, but.

A

But then is is creating problems or more, it's not exactly problems, but it's in some. In some cases, people don't really care so much about the idea of the application and I understand like when, in the case I think Lucas can can add more to that. But at Kemah they were kima is a solution for kubernetes right on on server glass and distributed distributed. Event-Driven architectures right I mean you. Can you can probably add that before I yeah.

E

E

So to how to explain kima in just few words but yeah, so kima is basically it's based on kubernetes and the one of the most important things it's tries to solve is that to enable a connectivity of old enterprise, size, monoliths applications into kubernetes. So you can then ya, extend it in any technology.

E

You want, you don't have to be locks to a technology of a given Mon on it, so you can have a situation that you have one kima cluster and multiple different applications connected into it and there's applications, of course, are written in different technologies. But at the end the most important is that they all send events to key mom and ya consumer. The developer can can subscribe to a specific event, even type with us and API.

E

It's called channel novel, so I need to remember about the new glossary. So that's how it was the purpose and for us we treat us in API rather say for to two things so I say document describing the list of events that you have available for a given application, and now then we nicely render it in the UI. Of course, as a reference, but then also the document itself, they are saying appear. Doc serves as a important foot. Sorry because my kids, just goodbye uno, momento.

E

I'm going back to the easier part of the ngpa yeah, so you see the same document as an input like we. We grew up out of it. A list of channels so developer through a CLI or UI can easily see the list of events you can subscribe to. You also take the payload from the a sync from the stack that is provided for each channel.

E

We take the payload, we display its 2d to the consumer, so he knows how it looks like we generate an examples for him, so we can test and trigger and I would say test messages before he actually subscribe to reading messages. So that's how how we can submit so we still look at it as a actually application right. So it's a expect, then describe describe, say a list of channels you get from a given application that you connect interview and including like so for us.

E

The idea ID is something that it's not needed, because we we of course have to have to somehow identify the application, but yeah it's kubernetes. So we anyway I didn't have a our own custom resource definition for applications. So we have ID on a custom resource level. We don't need to have in the in the stack itself. So anyway, we would just generate something there. If that would be mandatory.

A

That make sense, and also to add that.

A

In the case of testing, this is something that I've been exploring lately, how an API testing solution or API API. You know I'm not sure, if we'll call it API anymore, because it's has many meanings now, but probably event-driven architecture, testing solution. If you want to create something out of the box like really or on-the-fly, let's say, then the idea doesn't makes much sense right.

A

So because it's something like like generated and doesn't really happen and meaning so I, don't know if any of you have any thoughts um based on the application idea, if it's a remain mandatory because for you is something that you want to to keep it there.

A

Any of you have any.

C

Concerns about.

A

C

Would I would say it seems fine to make it optional.

B

You know, I grew up, Scott.

A

Okay, so we're go bang, it's not saying anything today say: don't be shy. Just.

A

Cause I think yeah I think we will make it optional in the next version and then release candidate version and see how it goes. In any case we have. We don't have some much time for reviews here, because the next point- today's agenda is exactly about this about dates and because the Specht, the spec, involves a lot of working tooling and you know and the ecosystem around it. We went to.

A

We wanted to make sure that we have at least good enough spec for version 2, that we can use it for many time right and then we can keep involved in it over time and we don't have to make the best spec right now for version 2, just as I said good enough. So thinking about about it a lot I I was thinking, and you can tell me what you think about it. But I was thinking I'm put in the 1st of July as a deadline for reviews.

A

So, whatever is on the July 1st inversion to accept minor fixes, it's gonna be the person to basically the defective one and so the reason I'm keeping it to July 1st is because I want to launch it for some Toulon September late September, if possible. So I need some time to update the whole community and you the ones using missing KPI in your products.

A

You need some time to update to version 2 and you don't want to be updating your products to version 2, really skin candidates, X right and then knowing that this is gonna break at some point. So so yeah I think after many meetings with you and other people- and you know with the community and talking about with the people, I think version 2 might be in a good shape to continue with this as it is, as I said, with minor fixes.

A

If, after first of UI, we see something like okay. This is this is crazy, like it's not to be like this, of course, we're not gonna ship it with a with a mistake there, but but yeah I'll close the review period. So so we can make it stable, at least for total development cuz. It does that sound to you. You think it's okay for you today, so you need more time for reviews. You mean you think I'm I'm, taking a lot of time, thumbs up.

C

E

Done with the review so for many deadlines can be tomorrow, so.

A

Okay, yeah but you're very biased.

A

Don't wait so much call so I'm happy damn that we can stick to these dates now and everything's gonna be easier from from now on, because the spec will remain and touch it or muslim' touch it until September, late, September, October.

A

E

So I had some connection issue, so I've heard the add the deadline for the for the feedback, it's 1st of July and the other dates because you're seeing dates, you say something from each mentions other dates. Late.

A

September, let.

E

It's in the late September would be the announcement of T to watch.

A

Yeah yeah actually I mean between us. We cannot really I, mean I'll release that that aspect I'll make that the final version final version too, before really before that, but the end of the announcement official announcement, you know going to an event and you know announcing it properly and all this stuff will be on late September.

A

So any- and you know this requires a lot of staff, not just a speck in the toilet, but also generating some marketing content and some some content, as well as a bit in the documentation and creating tutorials and yes, but this bit can be a final version to from probably on July 1st from on UI. Second right, so you it's so it's safe for everyone to say: ok, I can now start updating my product with a new version and and also it would be easier for tooling development as well.

E

Ok cool, then it's perfect because I plant, with my guys to start working on the some services July. Then it's gonna be perfect.

E

Oh cool! That's.

A

Good perfect, so any any other things that are not in the agenda today. I mean just feel free to Grayson equation now or after the meeting I'm happy.

E

So I have one question which is a bit embarrassing, I think so. I was going through the getting all the getting started guide she prepared for 2-0 and I have smoked Khan's friend I. Think we I mean me personally I. Think I made a mistake when I started using uh Singh, API, a10 I think I misunderstood some pretty important things. So, looking at the channels now you can have like all the topics in the past. You can have subscribe or publish and for10, and we started using it.

E

I modeled in in the way, I understood this back as a reader as a consumer. So I was when we started modeling. This back I said: okay. When we know we can subscribe to something from this application, then we in this peg. We should specify okay, subscribe and dammit I. Think it's the opposite right. Exactly.

A

This has changed the semantics at the point of view of the of the bird has changed, and- and this is actually this is being I, don't know- probably.

A

Probably regretting the feature now I, don't know. The thing is that for client-server architectures. That was the best point of view, though the one from one from the first version and from open API for instance. So you see it from the consumer perspective like in open API, you can get or you can post right, you can publish, or you can subscribe right from the consumer perspective, but given that facing API is mostly used on broker centric architectures.

A

This was highly confusion for people. It was really really confused like okay, it says, publish and subscribe, but people actually were thinking on this is this actually means that your application is publishing or is subscribing to the broker right in this channel?

A

So why I decided to change? It is because most of the use cases, as I said they are related to broker rock eccentric architectures and not so much about fine server.

A

Both are fine, to be honest, like both are correct in the case of, if you look at it from the consumer side in broker centric architectures, it can be highly confusing, but then.

E

Oh okay, so the answer is actually better better than I thought. So I wasn't wrong. Last year, it's just the it's just now download the change happened so actually last year, when we, when I understood it in the way that I was reading it as a consumer, it was correct right, yeah,.

A

E

Then it's perfect okay, some of this so so far it's.

D

E

Thank you because it's a Wii anyway so did the thing is that for me it would be problem if it's just a design problem I had that happened on my side, because I did not sure yet how we would solve it. But if it's because the spec is changing, then in our case anyway, we don't want to now force all the owners of the applications to now start generating that's an API to zero. We anyway we'll want to transparently support them, so they don't even have to really do any changes.

E

We will have a converter that will automatically always convert to the latest version. So for me it's our problem then, because I will anyway convert it. Actually.

A

If you go check that it was in my plans, I don't know: if I did it Indian, if you go to the no J's package that I created to convert from one to two, the ready-made said makes it change like if you have subscribed it changes for published so.

A

E

Went to zero, it totally make sense because you described application, so you is net and create document from the source. Point of view, like objects, are not the subscribe right. Nothing.

A

And that works for both cases for also for client-server. It's just that from for the client-server model, we are not used to Beth. We are used to Molly there's as from from the consumer point of view from the client point of view right, but in this way you can become model both broker, centric, architectures and client server. So the other way around it will be very, very weird for brokers and protectors, which happens to be the most. The biggest use case for is in KPI, so so yeah you.

D

Were right, let's say good message.

C

One challenge you have there is first of all, I agree completely with the approach you taken. You know you have to pick one.

C

A bit of the challenge you've had with aligning that with open. Api is the fact that you know OB, open e VI has get put post etc, which are operations, maybe you'd, be better off with roles and with operations right, because then it's more clear, I'm, a subscriber versus you know you can subscribe that sort of thing. Yeah.

A

Yeah exactly well actually the meaning I think Jonathan Cheban key updated that on the spec, but I think on the bird from the operation were from publish and subscribe. It says this: is it clearly like it means that these application can publish in this channel. This message not can Palace is gonna, publish it's going to publish eventually and that pun intended it's gonna palaces this event right this message, so it's it I think well the biggest problem that I found with async API.

A

So far it hasn't been doing or the spec or anything it has been mindset like explaining and and shifting the mindset, people really it's very hard, because people are so used to client-server model that some Lane brokers and.

C

It's like what and the problem is, there's many degrees of freedom.

C

A

Many yeah and hopefully we can help document then or define them so so they are still free but well-defined.

A

Who folds so I have to jump into another meeting now, as I said, if you have any concerns or any thoughts that you just want to share I'm happy to to chat at any time at any Central Europe time right.

D

A

Well, Central, Europe summer time.

A

So so yeah feel free to reach me and I'll be happy to chat yeah thanks for joining today and see you see you soon. Thanks.

D

For anything Scott, these are one thanks.