AsyncAPI Community, 5 Jan 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: AsyncAPI SIG meeting 39 (January 5, 2021)

Description

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

Attendees:
- Fran Mendez
- Kin Lane
- Zoltan Simon
- Swapnil Surve
- Dale Lane
almost Marc DiPasquale :D

Agenda & Notes: https://github.com/asyncapi/asyncapi/issues/472

Chat:
00:17:13 Fran Méndez: https://github.com/asyncapi/asyncapi/issues
00:19:10 Zoltan: {
"subscribe": {
"message": {
"oneOf": [
{ "$ref": "#/components/messages/signup" },
{ "$ref": "#/components/messages/login" }
]
}
}
}
00:30:15 Fran Méndez: https://github.com/asyncapi/extensions-catalog
00:32:05 Kin Lane (Postman): Here are the discussions around cataloging extensions across API specifications - https://github.com/api-specification-toolbox/home/issues/24
00:42:18 Kin Lane (Postman): http://api.specificationtoolbox.com/
01:03:25 Fran Méndez: https://www.youtube.com/asyncapi

A

Okay, okay, we are recording right now. um Yes, let me find the agenda but yeah, unless there is a last minute. Okay, so there's nothing in the agenda, just questions and answers, or just say hello and gather together and say and yeah and spend some time so um so yeah I'll start myself, I'm gonna start myself uh just want to send a message to the community, um which is I mean thanks thanks for these amazing 2020., this has been the so far.

A

This has been the best year of facing kpi so and- uh and we plan to make it uh the second best year this year. Right now, let me admit some people, some more people.

A

So I was saying that um this is the best uh the best year so far, and I'm thankful for that.

A

um It's been a tough year for many of us, probably not many of us here in the coal, uh because we are somehow lucky uh that we can work from home, but um but yeah for sure everybody has a family right and everybody has friends and you might have been impacted by my coronavirus so yeah uh anyway, um despite the the the bad year uh regarding the pandemic, this has been a a an amazing year for racing kpi and uh and for the community for our community as well.

A

I think, I hope and uh and yeah let's, let's keep growing like we're doing. Let's keep uh doing the what we're doing just continue, growing and being better in many ways and.

B

A

And uh and welcome kean and welcomes up neil uh and you know, welcome barbara finally, you're, not weird.

A

So so yeah, I was saying that um we don't have anything in the agenda today. Just questions and answers, and maybe just say hi and chit chatting uh so yeah feel free to ask any questions you might have and.

C

Have you have you, have you planned some kind of uh yearly calendar for your things like conferences or something like that? Do you know? Is there anything happening, not your you're, not maybe not in your organization but participating on targeting something with the thing have you have something I was participating this api days recently, uh which was, I would say that I was surprised the surprise. It was good content, so yeah. It was an interesting uh three, two and a half days online, uh something it's usually not online.

C

I think it's, uh but it was online and it was pretty well organized good tracks in in integration, api space, so yeah just just.

A

Saying so, I think I think we we chat on the on the last api days during. I think, after my my my uh my talk, I'm not sure anyway uh yeah I I was, I agree with you, it's it's. I was there, it's really good content.

A

It's really an amazing job that the api days, people are doing so so yeah we'll keep participating on on the day days as long as they want to invite us, of course, and uh we'll keep participating and we'll keep participating in other conferences, and we also have to organize our own conference this year uh again. So this time I hope, is gonna. Take us um a bit more than three weeks to organize them compared to last time right so last time we did it in less than three weeks and it was like a rash.

A

We, we were very innocent of us thinking that people will will not be confined in two weeks or three weeks and that people will go again to the streets and pandemic is over, and here we are 2021 and we're about to become fine again uh so yeah.

A

So yeah this time, we'll we'll do it also online and we'll do it um with a little bit more time and also with the support of our sponsors and and our um partner. You know postman so so yeah. We need to organize something better. This time it was great last year and uh to answer your question a little bit more, is we don't have a calendar?

A

It would be amazing to have one not that you mentioned uh it's, this kind of things that uh I never take the time to do and I'm just like flowing with the with the life and as they come. I usually accept so so yeah, but it will be great to have something and- and if you have something, if you have some calendar you want to share, I mean please do it, uh because we might not know all the all the conferences out there right related to api.

C

D

uh Here, hey cran: this is swapnil and uh let me introduce myself to everyone, uh I'm uh I'm working for american express, and it is my interest that uh brought into async api, so my interest into cqrs and even fulfilling so we were. I was trying to see how we can better model uh axons axon framework cqrs into an a single pf for uh generating documentation and generating a code, uh so that because admon server accepts everything like commands, queries and events as messages so which it is built for even driven micro services.

D

So I was going through a single api uh because it we we literally fall upon on our google purchasing onto personal, so it fits in quite well for generating uh documentation.

D

However, when we were going through uh uh because it is the async api is designed today for publish and subscribes uh messaging models right, whereas in cqrs world we we publish a command and it results in certain set of events, and those events can be subscribed by some other event handlers.

D

So you and while handling those event, we can decide to generate some other set of commands, which will be again published onto axon servers context. We call it so this kind of flow we try to model it using uh using extensions, okay and how, however, in our use cases, what we see is uh one command.

D

Sorry, one context can be published with multiple types of messages command messages, so we we matched it. We matched it with the channel as such in the async api document, where we are publishing it. However, in one context we can publish multiple types of commands.

D

However, in in the channel today, you only can have one publish and one subscribe operation, so async api.

D

So we were thinking or you guys can tell us whether it is right way to do it or not, is allowing multiple types of publish and subscribe operations onto one channel, whereas today it is restricting uh to do only one, uh publish or subscribe operation, one type of onto one channel.

A

Okay, so so, if well, first of all welcomes up new, so uh glad to have you here um and thanks for for starting using amazing api. I think your point is very valid. uh Cqrs is now it wasn't in our mind when we designed async api, um it was kind of there, but it was like a second uh citizen right and, and we needed, we never thought about it very well.

A

um There's there's something that you said is that you can. You cannot have with this kpi more than one message per channel right like when, when you want to publish more than one kind of type.

D

A

Yeah type of operation: well, what type of operation you mean, publish and subscribe.

D

No, no okay, so one publish you you, sir, you specify one publish operation and one subscribe operation against one channel.

D

Okay, but operation has one message: yeah can and there, but we cannot have multiple publish operations on one channel.

A

You can, you can have it there is, there is a, uh let me find it, there is a one-off.

B

A

Yeah one of uh on the publish and on the subscribe you can specify on the message you can specify one off and a list of messages right, so it allows you to specify that it can be one of them right. So you list there all the possible operations, all the possible messages for this operation right. um However, it's like it's a playing list right, it's an array of of messages, so it's not it. They don't have like. um Oh, so thanks so much for sharing this.

A

um So the thing is that, because it's a it's a plain, it's a plain array: what's what happens? Is that there's no way to map? For instance, um one of the messages is actually a command um and uh or or, for instance, in an rpc in an rpc context. There's no way to map that this message is the response of this other. uh This other message, or you know what I mean right. So it's like there's no way to do this.

A

It will. It will be great to have this. I think regarding rpc there's something, but regarding cqrs like like annotating, if it's a command or if it's a query kind of message, there's nothing right. um You have to do. You have to use extensions. So so I will ask you please to to create an issue.

A

I left the link there um before sultan's comment uh on where to print to create this issue like what would you love to do with it's in kpi that is not possible regarding securities or regarding other stuff, of course, and um and we're constantly working on this right, so so yeah feel free to suggest any any improvements. You don't have to suggest how you want it to happen. Just maybe just mention that you wanted to do x and it wasn't impossible right, so so yeah I will.

A

I will appreciate if you take the time oh yeah,.

A

Sorry, sorry go.

D

Ahead, I mean yeah. That was my another ask that message type whether it is command message or query message. That was also so I am so. I would like to share what I have. I was able to create the document or a sync api document and what we would like to have on specification to support cqrs. So on the data issues, I can specify all those details right, please, if you can do it.

A

Of course, that would be amazing and then from there we can work. We can work on adding supports for upcom, more, let's say, native support for secure as an async api. That would be great because we're having the same sorry- sorry finish finish. Sorry, um so so we're having the same kind of request for our pce, uh like people want to have uh annotate the messages.

A

If a message is a request or if it's a response right, um which is it wasn't our mind uh in our minds either when we created using api so but that's a valid concern as well, and this is something that we'll have to work on, probably this year right so so same thing like annotating messages in a way to specify if it's a command or a query or a request or response, or you know, and linking between them maybe like this is a response of this request.

A

This needs to be possible and doable uh at some point. We need to, of course, uh understand more and and and come up with a solution, but uh this needs to be done so something you were saying. I.

C

Think I think I think it's uh what you said uh on on that I think the valid way or or maybe that's what you're saying also the recommended way. If you have these kind of needs up, the best to do is if you already said that you created an extension, so I think.

E

C

Kind of improvements is good to start as an extension or and then then then you then the community can never eat it. Then, when that's listed the question, uh so I, if you have done something, for example, as an extension that so that's it's great. If you can publish it, I think so maybe you're maintaining your extension in github as a as an open source. Also so you can, you can do that and then the community can.

C

Chip in that could be also a great way of of bringing more people and debating on that, and then this listed the question to you I mean: do you have some kind of list of extensions or curated or known extensions, or so where people can see? It's also interesting. I was. I was just looking into the open api space if there is a an official list, but there is no official.

C

Of course there will be no official list or never been, and it's it's impossible to maintain one, but uh it's always good to have uh yeah.

E

One, I think I think an answer is yeah.

F

B

E

I have a list it's not published, yet um it will be. Probably you know in about a week um an open api extension list, because um I'm working I'm working on trying to pull together kind of the overlays and extensions conversation around open api. So also quick uh background. I'm now the co-chair for the oai as of this week, uh isabella- and I are the co-chairs for the oai so um creating.

F

An extensions directory.

E

As well as uh interoperability between the specs is is top top of mind right now, so.

C

Cool that's great.

A

So congratulations man, um yeah well well deserve for this long-term, uh long-term job that you've been doing on apis, so yeah.

A

um uh What's up and yeah. So I'm to you to answer your question consultants. Well, uh one of the projects that one of the things that we have in mind for uh this year is to create a an extensions registry or catalog or call it wherever you want, and um ideally it will be browseable.

A

You know to discover that it's unsearchable to discover existing extensions, and it's more, like you know, like a registry like a registered registry of packages like npm, is for javascript or maven, or you know.

E

A

And all of that- um and ideally this is something that we'll have to see how to do it- the software, our software, our parser, uh should be integrated with it. So if you can, if you want to use extensions and validate those extensions on the parting or the parsing, sorry on the person or the validation process, um it will be possible.

A

So you know right now: extensions are ignored in validation, they are not validated at all sure, and so it will be possible to to be able to grab the machine, readable definition of an extension and tell the parser to validate it right against this definition on the registry. So this this is an idea that we have in mind so we'll need an api for that yeah. Just.

C

A

Not to over engineer this, you know exactly. We need to be careful with this, so yes, please! This is just that's! That's why it's like this is just like an idea we have to explore. We have to debate uh how far do we want to go with this or if we, if we want to implement it at all, um so so yeah. It's like just ideas that we have in mind: uh it's no roadmap, I'm not I'm not creating a roadmap on purpose, because every time I create a roadmap, I never honored the road map.

A

So, in my opinion, having date on a road map, is this so um sorry for the word, but so yeah instead of maintaining a roadmap with what we're gonna have very soon is like a list of um features or options or things that we might implement, or we might consider uh without a date right um and yeah. So probably we'll we'll do this.

A

uh Well, most probably we'll do this we'll have this extensions registry um having this pension registry is for sure something that we will have if it's, if it's integrated with the tooling that's another question but um but having this, the register is fine because, as you said, people can start reusing these extensions, the existing ones find you know, find them and discover them and then using them, um and then they become kind of somehow standardized extensions.

A

If you want but becoming without becoming part of the spec itself, uh without polluting the spec right and precisely and then after and then and you can integrate, you can iterate there as fast as you can. As you want right, uh you don't have to wait for the release cycle of the spec um and then once we think that uh this is something that should be included into the course pack and it's mature, and you know it's stable. Then we include it into the spec, so so yeah.

A

So that's uh that's an idea that, like like, I said this is all to be worked on. um So we need to. We need to work on even on setting up the team to take care of this, and you know and the plans and everything so we're writing down this. But we should soon see the the outcome so yeah.

A

That makes sense.

C

Yeah sure you know, keep it simple: stupid, create a gift, create a gift, create a grease with the links or this list of links. So then, here you go. You have the repository, so I mean.

A

Well, you gotta be careful with this, because then some people go to the gist and some people go to the new registry. And then you have everything like sparse and divided.

E

A

And it's like, so that's why we're taking it like we're sharing it, but whenever someone asks but we're not promoting it on purpose, so it doesn't get spread in multiple and and threaded.

C

Right, I know what you're doing.

A

A

So yeah um there was actually a repo for this.

A

Extensions catalog, I think it's called.

A

So yeah, let me just share this with you. There was some preliminary work which is probably outdated now, but it's there. Okay, so yeah. There's the intel. That's exactly the intent of this right to have a catalog or registry of extensions.

A

So that's one thing.

B

Nothing else guys folks.

F

Would this call be a good place to discuss some of the github issues, um maybe some of the ones that are a bit stale or maybe not being too active? I was wondering if it might help sort of make some progress.

A

On which one sorry, I missed that part.

F

I I haven't got a particular mind. It was more an idea of is this a good forum for discussing ideas that people have contributed well, I know I've put a couple in, but I don't mean particularly just mine.

A

uh I think the best place for long-term discussions and slow discussions is github, so github issues on depending on what is what the iss is about. If it's about the spec you you have to go to the kpi repo uh on the snk organization, um I think that's the best place if you want to have some quick chat about something um and then maybe reflect it into the into an issue.

A

I think the best place is to go to slack, but I think you're already on slack right, yeah yeah, so so yeah, that's that I will say that would be the the best, uh the best part uh the best way to to do it and um just to make it clear right now we are in the process of changing how everything works at async api in terms of organization, so we're gonna be moving into a um into a a an open source foundation likely something, like you know, like a linux foundation, um so we'll have to um we'll have to define all these things.

A

How how do we collaborate? What's the process of selecting certain issues and voting and all this stuff? So this is, this is about to be done basically and also, um as you may know, already we we joined postman recently massive. um I would say that all of the team or most of the team, so um so yeah, so we're still landing at plasma as well. So you know and informing the team there so this this is all gonna be changing soon and um and yeah. Hopefully it will be formalized also.

C

Does this affect this forum, or how do you see that? How will be do you have anything anything you can highlight from this new structure already or.

A

So um I mean the the structure: is um the structure that we're seeking here is everything is by the way everything is going to be like done transparently, so we don't have so much to share yet because we didn't have we didn't do it uh anything we didn't do anything. Yet. um We are right now selecting where we want to go like if we go to go if we want to go to linux foundation or somewhere somewhere else.

A

um Once we are into this foundation, I guess the process will be setting up the you know the all the legals all the ips stuff uh for the project into that foundation, and then the structure of the team will be uh most probably something similar to what open api is doing, uh which is like technical steering committee taking care of the spec, and um that's that I won't say that's it.

A

I don't think we'll emulate everything that open api is doing, uh but we'll take some ideas from open api from apache uh projects from you know, from different open source projects. uh I think redis is another good example and um and some others right, so we need to come up with uh with this. With this uh structural definition, but just to make it clear, some people will be working or most of the people will be working on the tooling, because there's a lot of work on the tooling on the basic tooling.

A

That's what I mean so basic meaning or core tooling. If you want, because it's not actually basic um accordingly, like the the parser, the documentation and code generators, um you know a the the cli to work with async api. You know all this core tooling, that can then be used by other companies to create better products right so or to use it on on their cicd pipelines or whatever or the process.

A

So most of the work is going to happen there. It's going to be a probably one or two teams working on okay, tooling and and also some some other people working on the spec um who's gonna, be on this working on the spec side, don't know yet. uh So I have some ideas. uh I've been talking to some people, but you know until they don't reply.

A

uh Of course, we cannot uh share anything right, so so yeah I'll I'm pinging some people and then as a starting point right. um This will be the starting point from there on we'll be uh doing. You know um inviting people to join the uh so that the committee will be inviting people to join other people, so the committee will be inviting people to join to the committee. You know by reference like I want to invite this guy, because I like what he's been doing on amazing kpi for a long time.

A

So you know what I mean. So it's like this is just we're. Gonna set up the beginning, the the foundations of of the project, and then from there on is. It will depend on the committee on the technical committee on how this is going to evolve right so yeah, that's all I can. I can say right now, cool, not because I want to hide anything.

A

I don't have anything else. It's not not yet yeah sure.

C

A

Lots of work- I can tell you.

C

Yeah yeah yeah yeah.

A

You guys have big.

C

Plans as usual, so I think it's not uh not a surprise, big ambitions that that brings forward so yeah.

A

This will have only you know, like small ambitions, you know like going on the.

B

Holidays or something like this.

A

Go to the forest.

C

Don't forget to reach out for help if you're new yeah.

A

Of course, of course, of course, so and same thing is if you think that any of you want to get involved more uh closely to the project and we are not reaching out to you or something like feel free to bring us on slack and say: hey just raise your hand and say like hey.

A

I want to help more just count on me and whenever we are working on this, we'll uh we'll take into account for sure now sold them, for instance, but I mean like an example, is, I will say an example is lucas, so lucas was part of the community before I hired him back a year ago, more or less almost a year ago now um and um yeah, he was always.

A

Looking to help and talking to me so it was natural right and then same thing happened with with johnny magic here on the call as well. um They were the biggest contributors of facing kpi aside from lucas, and I so so yeah it was natural. This way right, we're happy to we're happy to onboard new contributors for sure.

A

It's not that we're happy. We need it.

B

A

The project is there right, cool.

A

A

So anything else someone wants to cover. We get some time still.

C

Not much now, uh I'm still, uh you know, I'm one of the earlier one of the in in somewhere in summer or somewhere.

C

I mentioned this uh catalog problem space, I'm I'm digging, I'm still digging into this one and that's an interesting area that uh I could say that from an again from an enterprise lecture point of view, what I'm working with it's uh in this year, I already got some good insertion disk, interesting discussions about this catalogues or integration catalogs across technologies like open api, sync, api, graphql, so eddy all these things, so that's still on an ongoing journey. For me, you appointed me some of this uh works at uh cloud events, so.

F

C

Think I think that's something we'll be popping up through the year how this standard supported across, especially for bigger enterprises, because that's where now, with this microservice architectures and all these things, this kind of population is kind of getting messy.

C

So I have to say that I'm looking forward to to go go continue that journey and see that, for example, like rapid api or other vendors, how they are implementing this kind of supports for making registries across.

C

So that's an interesting development in mice, I'm in my of course, I'm looking it from a high level. So it's not a technical level. It's more like a governance level, but uh interesting to see. There is a demand, definitely a demand, and uh because you also mentioned that you are also you have this endeavor of the sync api hub or something else or what was it?

C

What do you mean when when when, when you have as I've seen somewhere, so that then you can have a registry of your async apis or whatever so, but people looking for for things like across.

A

C

What was it, what was it.

A

I don't know, I don't remember it.

C

Was I think I.

A

Have yeah but um yeah, but uh yeah. This is slightly repurposed. Now like this.

C

C

There, so that's that's! That's that's! I think it's an interesting topic, but of course it's on not on a technical level. It's not it's more like when I'm looking for these things, I'm always asking like. I have the list of asking which kind of technologies they should support, and my usual list was like graphql, open, api and store, and now I'm adding. Okay, do you have a sing api also, and people like looking at what does that so.

A

So I think, regarding lists of technologies uh and governance, I think keel lane has a good list. I was waking you up mate.

E

So I'm actually here here's a link in the chat. um This is totally proof of concept right now just to sell the oai.

E

um But this is my api specification toolbox, which is um so it's here's all the standards um that you should be considering and think about, and I'm I was just adding avro and thrift and others this morning. So I haven't done that push yet. But then it's here's, the specs, here's the kind of news around the specs, here's, the commercial services that uh you adopt, the specs, here's the open source tools and this is across to all of them um and then here's videos you mentioned you know api days, videos, I'm doing api specification conference.

E

So I'm aggregating videos here and then and all of this runs on github. So this is meant to be a community project that anyone can just submit a pull request and add anything to the list.

E

But this is me trying to so I'm trying to pull it together, because I'm you know trying to reach out to all of the providers, the service providers and going. How are you using the specs? What you know how much of the specs do you support um and then widening that you know I'm. You know this is json schemas in here too, um you know I was just pinging daniel from curl.

E

You know behind curl asking him what his needs are, and so I'm really trying to as part of and then uh trying to get the oai to put some money investing and actually moving this forward to uh drive the conversations around this. So this is all still work in progress. It's not quite ready, but you're, welcome to browse around and and and provide me with any feedback or thoughts of what you would like to see here. So.

C

Definitely I was never ever. It was not ever of this, but this is looks pretty cool. I might promote this also, if, if you say so well,.

E

Feel free, I mean, feel free to share it, as is I'm not I'm not afraid of my work being out in the public and people you know being unfinished. That's how I work so don't be.

C

E

It doesn't scare me, um I actually probably should add a github link to the github repo behind this, so people can submit github issues and pull requests. I notice, I don't have one so um so. Yeah look feel free to share feedback because yeah, I kind of feel like right.

E

Now is the time to kind of start unifying the vision, because I get a lot of questions you know I mean I I worked on the you know the api blueprint rammel kind of swagger early days, and there was always a question: when are we gonna have one spec to rule them all and I said never um and then I know we.

C

E

Same question now with async and open api and I'm like my same answer: never we're gonna have multiple.

C

E

Long time, but with that said, we need better interoperability. We need better, uh not just interop technical interoperability, but business and and financing, and all of that so yeah. This is my effort to do that. Yeah sure.

A

Totally agree, that's totally agree. That's also. One of the plans, I would say, long-term plans for facing kpi is, is to become more in in the technical sense to become more interoperable with other specs right. So you probably have realized that we now support. We already support um json schema as the schema language for defining. You know, message schemas, but we also support avro and rammel right, so ramble data types and other right.

A

So that's that was done on purpose and we want to continue growing on that on that um on that path, not on the not on supporting every kind of uh every kind of language ourselves, because that will be unmanageable but respect the spec must be at least ready to do it to support it. uh The tooling it's another thing, the tooling you might, you might be able to implement all these things or you might not, depending on the number of uh combinations that we end up having.

A

But um but for instance, one of the things is we have an http binding, amazing, kpi and um right now is is um it's custom is something that we we made in in a few weeks like okay, let's just let us define some http interactions and http protocol things on the interaction and uh and after some time, working on this I realized like. Oh, this is open api. What I'm doing what I'm doing here inside the http binding is is actually an open api operation.

A

uh So so why am I duplicating the work and doing it in another way? So next version, it's still in zero point something so next version, it's gonna probably uh break what we have, but uh in the binding itself, um but next version is gonna, be like no. This is actually an open api operation. uh It doesn't have to be something different and we don't define how the open api operation works.

A

Open api does that right so and an open api maintains this and at some point we might also end up supporting graphql schemas right for the schema definition of the of the data, maybe not right inside the the file, but using a like something like dollar, ref or similar, to link to a an existing file, defining a a graphical schema or a grpc or protobuf message somewhere uh in another file right.

A

This will work this. All of this will work together because nobody's nobody is using only open api or only using api or sorry nobody's, nobody's doing only rest apis, or only even driven architectures, or only grpc, or only graphql.

A

You know people are using all of them right, like mix of them right, um and you cannot force people to use only your technology, because that would be stupid right from our side like with I mean it will be like a an ego ego booster for us for ourselves to say, like hey, we won the the the spec battle because we like, like king, was saying like we become the speck of respect.

A

Yeah for us, for our ego will be great, uh but for people will be a pain right like it will be like I have to migrate everything that I have an open api and in graphql and then blah blah blah. You know I have to migrate everything. No, why again a new technology again, uh even if you succeed it will be not. It will not be good for the people, so um we don't want that. So we want to. We want to make something, useful uh and and being useful. I want to I want to.

A

um I want to underline the the word use right. So it's useful right because it's something that you have to be uh able to use yourself right as an and easy right, uh so so yeah so there's there must be a solution, um an easier solution.

A

I know that in the past some people took the the decision to say like no we're not going to maintain this or we're not going to support this or this and this and this and that because it's going to become too complicated.

A

But it's your job right. It's your job to handle this complexity, or are you handling this complexity, to the users and sorry for the work, but- and you say them they have they they handle the every time. I say a word like this kim looks at me like this. Guy speaks so bad, so.

C

Hey it's a public.

A

Channel you know.

C

You have to keep.

A

So it's like no, but it's true. It's like uh we are here to handle this complexity. We should not be the ones telling you uh please handle this complexity for us right. Of course we have to start slow and simple and all of that right, but at some point this is going to become complex because the world is complex, so yeah.

C

Maybe there is a practical there's, a practical implication. What you're saying here under that question about a modeling x on x on things, maybe for you, for you, maybe have you considered to combining async api and open api spec to model and document your ex on message, flows? Isn't that an answer? I don't know, I'm just you know.

A

C

No, I'm just saying that that was that question about axon the action on.

A

C

And cqrs, who was that uh swap name? This is.

D

C

Yeah yeah yeah, have you considered to have you consider to combine open api and skpi to document and model that thing what you what you have to achieve, instead of just you know, shoehorning into one spec, I don't know, if does it mean because it has any meaning? I I don't know your use case. I'm just.

D

When uh really speaking, amazon is for event, given micro services so and open eps specs more towards the api's synchronous api calls, I would say so because uh in axon we have everything as message that is command message and an event message or a query message it. It seems to fit more with using api and whatever poc we did over last week, just a week we spent it really uh seems that it fits more into uh a single api world rather than open epa. That's fine! Yeah! That's fine! Okay!.

A

Can I ask you one question because, uh like regarding accent, I don't really know so well uh the framework, uh is it imposing their own uh protocol or you can use it with different protocols.

D

A

Okay, okay, so it is grpc, always it has to be grpc. Always yes, okay, okay, interesting.

D

The that is axon server basically, and they have we have ads on framework as well, which is uh independent, uh which uses the database as the database as the message even store. In that case, it is not required to have grpc form, because the message, the command bus is implemented in the framework itself. So we are just sending the message on the bus and that is internally implemented.

A

Okay: okay, thanks thanks for that um yeah, so yeah. I guess at some point uh at some point. uh Smkpas will be able to help here uh with grpc and protobuf, but uh because you define the messages with protobuf right or you don't define your messages at all.

D

uh The server defines it so so for an application. Yeah, the foreign application is just creating the java uh uh produced java objects, but the.

E

Server is taking care.

D

Of you know, uh serializing it to a proper program of message.

A

Okay, okay, so it's a, I will say it's a code first tool. You write the code and then the code is responsible for registering those messages in the server and using yet yeah. Today,.

D

It is code first tool. Yes, what we are.

D

So what we are trying to do is, uh you know, build uh build, you do even storming session and you come up with the commands and queries and types of messages, and then we want to generate a documentation and code for it and then use it in the application. So we are trying to reverse the flow, but today it is code. First, yes,.

A

Okay, no it's okay! I mean you can actually use a combination of both right like um you can you can continue like that? That way, like you start, like you said, designing what what the api is going to look like uh and then before you even have the code. You write the async api file and then use the sdk file to generate the code, and then you can continue from the code. uh You can continue from there right. um So that's.

D

That's totally fine, but that's uh yeah. That is our intention. That is the end state. What we are looking at and then we keep on document uh maintaining it using the spec so that uh so that uh whenever a new message comes or the version upgrade happens on the message, we maintain it using async api spec. That was the idea.

A

Yeah, it's at some point regarding that. Let's say that conversation or context, something that I've been trying to play in my mind with is a something like a framework. We're not saying that amazing. It has to be an excellent pay framework.

A

Maybe um you know talk to the existing framework uh authors and this cas async async api integration directly to the framework, so I was thinking that maybe you don't have to choose either the sign first or code first, but rather what you do is it's like you get the best of both worlds right, which is you define basic kpi file? First, if you want that's, that will be one way of doing it and um and you, uh along with your code, you place the file.

A

There can be discuss if it's the best way or not, but that's I'm gonna just throw my thoughts. So, along with the code, you put the async api file and then imagine action, server or action framework.

A

I don't know um so action reads this async api file to understand um how the messages should look like right or how to register those messages in the server or it will create the codes for you, um so you didn't have to do it right and then your your um your let's say your application will become only business logic right because all this code that you have to maintain sometimes like a project uh with um you, know, serializing this your license service right.

A

It's always the same. It's it's a repeating thing that you do over and over in every project, and it's like: why do we want to maintain this right? It will be great, of course, that you can override this. If you want, you have the possibility to do it. That's that would be great, but uh I don't know if you follow me like it will be like it will be super great to have like framework, say action or say: um what's it called the spring framework right spring.

A

uh Imagine spring framework being integrated directly with async api or open api as well um in in the sense of you, don't have to register the public's or the subscribe.

A

Sorry, the problem is different, but you don't have to register the subscribes, um because the framework is it's going to read the file basically file and subscribe for you automatically it's going to generate on the fly.

A

It's going to generate the projects in the case of open api, it will generate, it will generate the endpoints for get put pulse on specific paths, so you don't have to do it in your code and in your open api file right, you do it only on your open api file and the framework creates the opening open api file as a config file, right as if it were a config file, a true config file.

A

So doing it like this, if we can make manage to do it like this, for open api for async api and also for graphql and so on, and your pc, if we manage to do it this way, documentation will always be up to date with the code, because, if it's not up to date, your code will not work right. Absolutely yeah.

D

A

You know what I'm doing yeah.

D

I'm following only concern with this is uh at a lot of uh if we are maintaining pojos. That is fine, because uh nobody is gonna manually, update them and we can extend. We can have it decoupled from the application completely.

D

If we are putting on to something like string controllers will get input and types of messages. A lot of people tend to write some sort of business logic at the at those points, and then it will be difficult to maintain them using automation tools but yeah.

A

Yeah right, so what I was thinking is more about like this is the default right. This is the default. The framework offers you and but of course you can override this behavior right like you can, it would be great like, for instance, you might be interested in complete completely automating the generation of the projects, but some people might not be happy with that. So um so it should be a.

A

You should be able, using the framework integration with async api open api to define your own, your own project, for instance right and you maintain it yourself. It will be like a kind of duplicate work because you will have. You will have to maintain it in into the cpa definition and in your project definition in your code and they have to match.

A

But um but again the the code can take care. The framework can take care that they truly match.

A

So they are, they actually define the same thing, but you should be able to define it yourself by hand if you want, and, uh for instance, like you said some people on using spring framework, they tend to put some business logic on the on some annotations uh or in some places where it should probably not be uh located right so uh again like this should be overrated or overrideable right. um I don't know like just flowing thoughts like maybe this.

A

This could be interesting for for some people, but for sure this is something that uh I mean we could create an amazing kpa framework to so to that we'll do that we'll do this this thing, but um yeah, if you're already, if you already have like you know american express already- has a bunch of micro services using axon uh tell them to migrate everything to the asymptotic right.

A

B

A

So it's a no but almost nobody's starting from scratch, so there needs to be something a solution that fits also this use case where people already have a lot of failed already greeting in a specific framework so and then they can slowly uh adapt right. um So yeah, I don't know just throwing some thoughts here that maybe this could be interesting.

A

Cool, so it's it's almost time um and if anything else someone wants to cover. No, um so I'm I'm sad that nobody noticed or mentioned that we don't have lucas today on the call so.

D

Yeah, hey, uh is this called recorded yeah? I think it is recorded right.

A

D

A

D

A

And I uploaded to youtube to our youtube channel, so it's going to be a kind of kind of meta once we upload this into into youtube right uh and with a youtube link, but uh yeah should.

E

I be worried what'd, you do to lucas.

A

um You should be worried what happened to lucas? Not what I did.

A

Are you? Okay? No he's. Okay, he's! Okay, but you see nobody asked.

A

We are respecting.

C

Privacy, you know.

A

Yeah and uh yeah, just to finish, I wanted to to welcome mark the pasquale to the call one hour late.

A

So yeah man so welcome. uh I know it's 2021 and you might be a little bit delayed, but.

B

Yeah, uh sorry, no.

A

Problem, I have the recurring.

B

A

I hope there is no uh mistake on the calendar and that's why you you got the event wrong. uh I don't know I hope so so yeah um thanks for for joining today and um take care, uh see you around soon. Thank.

A

A