AsyncAPI AsyncAPI Talks, 3 Feb 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: The Future of API Specifications, Fran Méndez, AsyncAPI Initiative| Postman Galaxy 2021

Description

In this session, Fran will walk you through his vision and predictions for the future of the API specifications. As the creator of the AsyncAPI Initiative and a long-term user of OpenAPI and JSON Schema, he'll provide insights on how the future API specs landscape will look like and how the different specs are meant to play together for the benefit of the user.

With:
- Fran Méndez, Founder of AsyncAPI Initiative

A

Well, thanks michael for this wonderful introduction uh to my two two big words I will say for me, but thank I I really appreciate. um Well um just let me just let me uh introduce myself a little bit. My name is from mendes. I am the director of the async initiative and and- and I also created the spec and and this whole thing about async api.

A

I started it, uh but I didn't create everything right, we're more than just uh one one person and more recently I joined postman as a director of engineering and and also to to help move postman forward in terms of supporting, even driven, architectures and and so on, so stay tuned, because uh there there will be some some good news.

A

Let me just uh start this. um This talk with a little bit of story. This is stockholm. uh This is one of my favorite cities in the world. By the way uh I love it. um It was october 20 2018, and I was there to speak at the nordic apis conference. To be honest, I was freaking nervous. It was my first, uh my first keynote uh in an international conference. Let's say about a apis and- um and the reason I was also nervous was the reason I was about to announce right.

A

uh I got the first uh set of sponsors that were going to support async api and I was leaving my job at new relic to commit myself hundred percent to making async api grow so so yeah. The thing here is, I finished, I finished my talk and uh the time for questions started. I was so relieved like I did it. I it was, it was done and it was time for questions.

A

I I love questions because I love interacting with people which is such a pity and this uh online conferences that I cannot really uh interact real time with you, but uh we'll get there again. So one guy raises his hand and asks uh what about avro schemas.

A

You know apache avro um is: it is async kpi a replacement for for avro, and I said no, I mean they're actually solving different problems, so more questions came in and after uh after the talk, two guys came to talk to me uh separately, one after the other right and they did exactly the same question and it's like have you thought of merging with a open api specification and well my my answer at that time was like.

A

Okay, we've been discussing it because it's true we've been discussing it, but uh the the the answer was always uh look. It's gonna pull up put a lot of pressure on tooling vendors right now, right if they have to support open api classes in kpi.

A

So so the final answer was like: let's not merge, both specs, even though we they're very similar and and and we want to collaborate and we we collaborate, um we don't want to merge the specs right.

A

This is uh the entrance of the api days, paris.

A

It was december, uh two months after the other conference on stockholm, and this was my first api days in paris and I was overwhelmed because I mean the amount of people there was insane and I was pretty new there, like my first time in paris, but luckily kin lane was there and to lend me a hand, and- and I always will will be grateful for that right.

A

uh Also, my friend angie garcina was there too, and they used to work for adidas, and he introduced me to samir I'm saying uh to to me and when we got a a great chat about api management tools and how they were thinking, uh async api could benefit adidas apis.

A

The only problem was they already have api management tools right. They were using can't remember exactly what tool was was it, but they were using already a tool for api management and they were using already open api. They actually have pretty good uh guidelines, a bad guidelines. I recommend you have a look and- uh and the problem here is that they would love to have everything in a single place.

A

So you don't have some guidelines and some developer portals and api management tools for open api and then the same thing for async api uh which didn't exist. Yet uh I mean I mean the tools right uh and uh and share you'll have some doc some some json schema documents like I mean the models, the data models right, uh so it will become clearly it will become a mess and- and they wanted to have everything in in a in a single place, but the tool that they were they were using, wasn't supporting us in kpi.

A

So what can we do right uh and almost a year after we, I was helping organize organizing api days barcelona. I was living at barcelona at the time and uh then actually they helped async api even more by giving me the opportunity to have a booth there at the conference right so baptist, uh medi, denis and team. Thanks for that folks, because I really appreciate that- and I also get invited to the speaker's dinner, uh which is usually done the the evening before the conference.

A

uh This is spain right. So I was in the street with my beer having a bunch of great conversations with many apa folks and uh guess what uh this evening I got the same question three times it was hey. Have you thought of merging async api spec with open api spec, and I was like, oh guys, I can't believe again the same question and this time three times over beers.

A

So you know the answer already. So I was like what the hell is happening here right. So why am I telling you all these stories? uh Because this is cheaper than a therapist? uh Maybe I don't know I'm kidding now now seriously. So the the thing here is that I was I was. I was asking myself. I was wondering why people want us to merge into a single spec like why merging open api and async api, and when I was giving this response, this hard answer like no.

A

This is not going to happen because we already discuss it and blah blah blah. Whatever the face of the people were always like yeah, not my problem right, uh so it's still not a a great response for them right. So so the thing is that why so coming back to the to the questions like why people want us to merge with open api, um I'm not gonna respond. I'm not gonna answer this question now. I just want you to look at this, so let's have a look briefly.

A

We get rest apis, we got graphql apis, grpc, apis, messaging, apis or asynchronous apis, as you prefer so apis. So there can soap apis still exist. I can't I can guarantee so um so yeah and for all of those uh type of apis. There are like um a list of different api specifications that you can use um this this one here is this simplified list of api specifications.

A

There are many more, but I will say that these are the the most used for each of the types.

A

So let's go through them like if you, if you got a rest api, you have open api and, and you have ram and uh because you have open api you also have in, even though you maybe don't know it, but you're using json schema behind the scenes. So there are three api specifications involved here, working completely separated.

A

If you have graphql, then yeah it's simpler um because you have the spec, the spec and the tooling is created by fql. So that's fine.

A

If you have grpc, you have the grpc spec and you have protobuf and and also some tooling, that they provide that google provides for that. I also want to make a point here that it's not that you have rest or graphql or grpc you have rest and probably and graphql, and the messaging and soap probably and in bigger companies you probably have all of them right. So so yeah, it's not a it's, not a matter of or right yeah.

A

So then, if you get messaging, you have async api, but you know because of the the ways kpi works uh by default, you get json schema behind the scenes. That's the way you define your your documents, your data models, and uh we knew it. We knew it from the very beginning. Actually, I think the first issue that I created in asian kpi reaper was uh just a link to avro and cele for inspiration.

A

Have a look at the avro like just uh have a look at it just for inspirational purposes, let's say, and um we knew that uh that avro was pretty heavily used on the on messaging on the messaging world, specifically on apache products, right and and so telling people uh that they have to translate all their avro to json schema like we did in the beginning. uh It was a. It was a pain like we were, transferring the the load, the complexity from ourselves to the user.

A

It's like now, it's your responsibility to adapt to my tool. uh So, in the end, what we did is like okay, we need to get over this and we added support forever. So now you can use avro using schema, whatever you prefer and even dramaal data types. That's why ramallah is in yellow there. It's like it's, not that you can embed a whole ramble document, except you can embed your ramel data types inside async api.

A

So when you're, using async api you're, actually using many more api specifications, not just async api right and if you're using soap you have you have whistle, I don't know how you pronounce that I pronounce it whistle- and I hope this is correct and xsd, which is like xsd, is similar uh to what jason schema does with jason, but in this case, with xml, right and um and now so so now.

A

Imagine that now imagine having this uh having this uh this whole this whole uh set of specifications right and uh and and and that you have to maintain them all right. All the documents right, so I'm gonna ask this question again: okay, so why people want us to merge with open api, then I was asking myself again if we merge the two specs open api, instant kpi, we still have json schema, avro and ramel, not being part of the spec.

A

So what about people using dremel? uh We leave these people out, like oh, no you're, not using open api, so yeah yeah. You know what you cannot get any benefit and what about those using graphql and grpc, like imagine that you only have graphql and kafka in your company or whatever or amqp whatever another messaging, apis right or synchronous apis.

A

If you have graphql and kafka for instance, then what? How do you? How do you share the data models? Data models in graphql are not compatible with the with avro or json schema. So you have to define things twice.

A

I don't think this is what you want to do, right and and and the same thing applies for grpc, so what people will do, and they will ask next, uh is- uh is that you add support for or you combine with graphql or you combine like open api and snk api combines with graphql into a single spec or into a single uh document somehow, and then your pc, as well and and and so on, and so on.

A

So but you know what you know, what the the the thing here the thing about that here is that it's already happening so the the very moment we added support for ramall and data types and for avro. What happened next is that hey we want to use protobuf inside async api, hey, we want to use grpc. We want to use uh graphql schemas inside async api right now that we can use open api as well inside async api, so some some parts of it.

A

uh We also want to take advantage of this, and- and so you you when I when I stopped facing this, I was like what the hell is happening here. Like people really want a single spec, uh I don't think so. People really want a single file. Maybe I don't think it's just a single file, because specs are often composed of multiple files.

A

Already like this, like that, you probably have your open api files, your recent api files and your json schema definitions somewhere else in a github, reaper or somewhere else right.

A

So um so, after asking the community a lot, we learned that what people are asking for is actually a single tool or a single process or a single workflow right, like people want their processes to become easier, more more seamless right and you know what- and you know why, because people have other problems too, when you, when you're developing an application or creating a product, you have to make other choices or take care of other parts.

A

Like think security, deployment, storage, uh the the testing strategies that you're gonna use uh api definition, it's just one of them just just another one, not a special one, not a special one or anything for them. It's not for us, which we love as apis, it's a special one, but for developers this is just another tool right and we the specification authors, we're not making it easy, we're not putting it easy for the user and that's uh and- and that's a that's a pity. Actually.

A

So how do we solve this challenge without merging it into without merging into a single spec without all of the specs merging into the the one and only spec right that everybody has been looking for for years? um Let me uh let me go through this list uh here. I I listed a bunch of uh of things that, in my opinion, are working.

A

You see it in green uh others that aren't in grant and others that are kinda working or can be close to uh going well or close to going bad, so so yeah, so so specs for instance. Let me let me get just one one, one by one like the specs uh in the in the case of the specs, we have multiple schema definition languages we have just in schema, average drama data types and the others. We have multiple paradigms. We have, you know, request response event, driven architectures uh rpc.

A

um You know different uh paradigms. We have multiple protocols in the case of async api. You have all the protocols, basically so, whatever protocols you want to use it's possible and um and and that's it's more or less like covered right like if we have specs for each of these areas and that's fine right uh if they're working well together, that's another thing, but at least we have that.

A

Then we have extensibility right so extensibility, I think uh specs most of the specs are extensible in some in some way or another like, for instance, open api and and therefore, as in kpi um they're extensible. So you can use these uh specification extensions which is x dash whatever you want to put and the parsers will ignore it. It will validate um so that's a way to extend uh specifications, but some others, like I think graphql, doesn't allow any kind of specific syntax to extend it.

A

So so yeah there's some work there, but there's some work needed to be done there and then there's the problem of composability. If you think about uh um like uh think about component architectures in in in development right like you, can use one component inside another and you can actually build things out of many small components right, so we're failing here, we're but miserably we're failing here like uh open api and async api can more or less work together, because they're very similar.

A

So actually I started facing api from open api so that that's why they're very similar and uh but they're completely and radically different to graphql and and protobuf for grpc. So so, how do you map a gamble, definition, radiation, definition inside protobuf or or graphql? You can't right, you can't do it because it's not gonna parse, so we're failing there right. um We know the reasons, I'm not blaming anyone here, I'm just saying that the reasons is that everyone has their own reasons to choose one format over the other.

A

That's fine, but again for the purpose of of this talk of like looking into the into the future. I think they are not composable. uh It's not that I think it's they're not composable, so uh that that would be uh great in terms of tools. We are failing in a lot of areas like we're, not collaboratively, building, parsers or validators, we're not building tools to facilitate evolution, we're not making each one uh each other tools interpretable between between them.

A

So I put an example here so when we had to add when we had to add support for avro into into async api, we didn't have a tool that will do that for us, like we will. That will allow us to parse other documents and uh and easily have that almost done right like we have to do almost anything, and we didn't have that for open api, because open api is not maintaining official, tooling.

A

So yeah you get a lot of parsers, but who knows if they're working well or not, right and uh and then you have for for ramble data types, we had something, because the meals of folks were maintaining something that so that that was great. So uh the thing is that when we wanted to integrate async api with another spec, it wasn't easy right. We had to build the tools ourselves and maintain the tools ourselves and that's a pain right.

A

uh That's fine, but it would be great that avro will maintain their own tool uh for parsing, open api, their own tool for parsing as well, and each of them right um and also for and also of course, they have to be open source and and to be honest, uh what we found so far is that most of the times they are open source. So that's that's fine, that's fine! And for the end user, I would say: I'm I'm gonna just uh highlight the last one is uh for the end user authoring tools.

A

I think uh postman, uh um stoplight and and other and other products are doing well here, at least in the in the in the rest apis world. For now uh they are they're doing a great job here and that you can actually prototype or or author your api. Even if you don't have uh any single idea of how open api works or graphql works right that you don't have to, you, don't have to know the the syntax, but in the end I think it all goes down to yeah.

A

Surprise people right like it goes in line with what uh steve wozniak was saying precisely today and uh it's it's always trying to put the the people into uh into the the first place right into the the gold and.

A

And the thing is that uh I think uh we have to we: we have to learn as uh as organization leaders, we have to learn how to collaborate and we have to uh start making combined marketing efforts and financial support between specs. uh I'm raising a hand here like please support jason schema. uh They have an open collective and they doing a great job and nobody almost nobody's supporting them, so they need it, uh and- and I think the user experience must be the the the end goal and transparency here must must prevail.

A

Right, like everything needs to be done transparently in all the organizations. The uh working on api specs right. So um wrapping up uh would like to would like to um mention and and make a strong point here that uh hey realize everyone realize that the api ecosystem is diverse, that the specs must be composable and extensible, that we should facilitate evolution, interpretability and that uh you know spec authors must collaborate more and put the user in first place right, uh not our own problems.

A

So, just uh just to to finish, um I think this is the real feature of api specifications like what I've been describing is is the future of api specifications.

A

If we manage to solve all these problems, I'm I'm confident that uh that this is. This is how it's going to look like in in the next years and and I'm confident that we're going to solve it like uh from from here, raise a hand like this. We are also a culprit of of this, so we need to collaborate more and from the async initiative.

A

uh We're gonna make everything that's possible for us to to make the process of using multiple specs, really seamless uh and and but that that's one more thing like I think community is super important here without you, the community will not be able to accomplish uh sorry without you that the community right will not be able to accomplish any any goals, and- uh and I ask you to get involved as much as you can from here right now, even if it's just to give feedback to complain respectfully or just to say how much you love our work uh like uh just uh chime in and say uh and say something like we.

A

We learn from from your comments from your feedback right, so so I think I have some time for for questions just uh okay, so we don't have. We don't have questions so thank you and uh I hope you enjoyed postman galaxy.

A