AsyncAPI Onboarding, 13 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: AsyncAPI Onboarding - Part 3 - AsyncAPI in Theory

Description

https://github.com/asyncapi/community/issues/409

- what AsyncAPI is and what AsyncAPI Initiative is
- key concepts in the specification
- features overview

A

Sure, yet, if I'm really live or not so uh before, I start and say something more than just hello and my random rumbling. Let me check on youtube if the live stream actually started.

A

And yes, it it, it did start.

A

Which is perfect uh so yeah welcome. I'm mukash, gorinitsky and um today is a part three of the onboarding to asking api.

A

I'm not 100 sure if it's part 3 and the last one but yeah, let's see how the live stream goes um but yeah before we start, people are usually late.

A

That's how open source works, people it's slow and it's additional work. People do so people might be late. Then I'm gonna use this opportunity and drop some links to the onboarding.

A

In um in slug, in nothing apis like so bear with me, I'm just looking into slack now.

A

A

I'm just okay, I think I.

A

Okay, yeah, I'm in the right place.

A

Okay- and I just shared it in the docs channel.

A

A

Let me share it.

A

In the general channel.

A

How do I actually share what the heck yeah okay share message? General.

A

Fyi part three of on morning to class and just star that.

A

A

Watch and I'm gonna also send a link to other options to actually join in the meantime, like is there anyone actually watching already like because nobody's joining on zoom, but uh it's not needed. um So maybe there is someone already watching on youtube. Oh yes, so shinobi, hello, first person said hello, so others please also say hello, and do it only on youtube, because I'm definitely not able to watch all the chats in all the different social media during the meeting, because not sure if you know we are streaming also to linkedin, twitter and twitch.

A

Okay. Last link.

A

And yeah um so today we're gonna do two things like.

A

Today, like part, three will be like, so the part part one was about the um about like apis. In theory, where I try to explain uh with some examples like what apis are protocols specifications like in the context of asking api what you should know, and also like in the context of even driven architectures, that async api is for then part two was about the use cases in real life like I was like so the part one was theory part. Two.

A

Last week I was just going through all um different use cases like real life, products that are out there and they are using um even driven architectures, um and I was talking about something more. What was it.

A

ah Yeah I we were playing with apis, so yeah we were actually doing some real time play with the with real, even driven api, and today today is about um aced, hello, sergio and today is about, um like I'm gonna, do a introduction kinda to key concepts of async api like um it's a bit gonna be probably like, um like biased um by my experience with asking api but yeah. That's that's what I see first, what I think first about like key things, key features in async api.

A

I might be missing something. So if somebody is out there thinking that um there should be something more mentioned, when I will talk about the intro to the to the key concepts, please, um uh when I start the the live stream, I will share the link to the script uh for the onboarding. So please contribute like open, apo request and suggest uh what else could be added to the intro and last but not least after the intro.

A

I will be creating live a first asking api file and explain every single part of it.

A

And if it's possible, but I already think it isn't because I'm pretty slow when I'm speaking, I think we won't be able to go through like use cases, what can be done with the async api file that we will create today, so um so yeah, but like fingers crossed actually no like that's how you cross you like. Actually that's interesting so, like you usually like in english, you say fingers crossed, but we actually use it like when you're a kid and you promise something to your parents.

A

We do this, we cross it like. We hide behind the back and we say like yes, mommy. Of course, I'm gonna do it and then it means like you're, not a liar. It's like a like a talisman that um allows you to lie to your parents.

A

uh So for us, like always when you say like cross fingers, it's like it's confusing for people from poland. That is so uh we say che mike chooky, so like hold your thumbs, so let's hold our thumbs or cross your fingers that we will finish today, but all the stars in the heaven tell me that we will probably have part four next week but yeah.

A

um Let me let me share the message in the general channel and you might hear some noises in the background because, like today at my home, it's not only my three kids, but there are. There are also two friends of my older daughter and then a cuisine that is pretty young and he's like running around the house and he's super loud. Even though I asked him to not be loud but yeah. He probably promised me with crossed fingers that he will be quiet.

A

um So um if you have some questions, drop them in the chat and let's kick off the onboarding. By sharing my screen.

A

Okay, can you false confirm that you can see um my screen and it's a firefox browser.

A

In the meantime, I'm just gonna continue: oh yeah, thank you sergio so yeah um that was day one that was day two. That was the uh oh sorry, part one. That was part two and we will try this today. Maybe we'll manage also point number six but yeah again. Let's, let's see, let's see how it goes so um so yeah.

A

The what is asking api like so so it's it's pretty important to uh to understand that at async api we uh like asking api, not only describes the the spec itself. um Sometimes people just use it to to call the entire organization uh they all the entire project that we work on here. So let's clarify some names so first of all asking api so asking api and why the zenhub is covering my screen.

A

um Okay, so it says like asking api: basically it's a specification uh for describing applications api and it's super important to remember this phrase like application api, and uh it basically means that you, you use async api, to describe um api of your application for your users.

A

So you don't when you start writing as an api file, you don't have in mind that you want to describe uh how your application behaviors internally.

A

So if it's, for example, publishing some messages, but you start writing as an api file by saying by thinking like what users could do with your application, if they can some send some messages that your application will consume or if they can um um yeah. Actually, that's it so uh remember, asking api, always from the perspective of the user.

A

Now it is um like um one of the main goals for us in dpi is like that. You can do much more with it than just describe the the api and and generate documentation out of it. So it's a machine, readable um format so um to to describe the api. You should use machine, readable format, it's a yamu or json.

A

um So let me just show it to you so here you can just see a single api studio where I can edit asking api files, and you can see like um that, for example, this example of a single api document. It's a it's a json but um yeah. It's a lot of curly braces uh quotation marks like who would like to write um json file by hand.

A

So we also support yaml file which in theory, people say it's easier, um but it's only um what say: people that like identitations and are careful when writing something so yaml is not much different from jason.

A

Like you can see, the structure is the same. It's just the uh that you don't have curly braces, you don't have, for example, you don't need to have question marks. Quotation marks actually quotations, but you just need to make sure that you have proper identitations.

A

Otherwise, things break.

A

Now going back to um to machine readable, so it's machine, readable, it's yaml or json. uh You don't have to care about any conversion.

A

That's what tooling providers should make sure that they um yeah support it out of the box. um You can use whatever you want now. It is very similar to open api. I don't want to go too much into details about open api in the script of this workshop yeah. Actually I promise to you to share the link and that's going to be actually very good opportunity to test something because recent yesterday I figured uh even though I'm moderator I'm not allowed to paste links on youtube.

A

So please follow us confirm, like I tried to change some settings uh so yeah yeah. Can you confirm in the meantime, if in youtube, you got the link to this workshop script? That would be perfect because I just pasted it- and I hope you can see it now, um so it's very familiar with um very similar to open api and then I in the script I linked to the document. That explains similarities.

A

So yes, thank you. So I got a confirmation from folks that, finally, I can share links on youtube like uh success of the middle of the week. Thank you. um So you can see that the open api that I talked about in part, one that is used to describe synchronous, apis and basically rest apis.

A

um I think api got was actually inspired by open api. So that's why the structure is pretty pretty similar.

A

You can already see it from this picture, and um so in theory, if you're open api user, it should be much easier for you to understand asking api. But um not uh I don't. I don't recall anyone any user saying like hey. I came from open api and asking api super similar. It was easy for me to understand because it's similar, so we don't know but yeah, I think in theory. It should be much easier to understand. um So that's like really in general.

A

So it's asking api is a spec um that tells you how you can write your yaml or json files that to describe the application that your user will use and to describe it in the way how they can use your application, and it's super similar concept to open api now.

A

Asking api initiative so like asking api is the spec as an api initiative? It's actually the name. We have for the project, so um asking api initiative is a project under linux foundation.

A

Later on, you can check the official charter we had between the the community and the linux foundation when, when the intellectual property over asking api was handed over to the linux foundation, it's pretty uh interesting. I think, at least for me to understand that the project uh runs under an open governance model, which basically means um it's not managed by just one company uh ip belongs to the foundation and the um the things we do cross project.

A

It's not my decision or someone else's decision. It's actually a decision of technical steering committee, um um which is a bunch of different folks, contributing to different parts of asking api initiative and asking api initiative is not only taking care about the specification. That's something different to open api. If you're familiar with how open api initiative works here, initiative uh takes responsibility also for basic basic basic tools.

A

So when we release a new version of async api, uh like the basic tools, should always be updated to to support the latest version, because in the end like what you can do with just a markdown document. That explains um how you should describe things.

A

That's why um sometimes people take shortcuts and they talk about initiative by just saying asking api, so don't feel confused. It's just like. uh I think it's pretty common, that people don't like to use too many words and they always find. I mean look for shortcuts now.

A

um Like the specification key concepts, uh what I told you already like the basic I'm so annoyed by the zen hub, wait. It's like.

A

A

Let me find this component and let's do some hard.

A

Yes, ui just got hacked nose and up so the basics, like I told you asking api, is for describing the interface of the application and it's not to describe the the broker basically but yeah. What is broker um again part one. I explained that in even driven architectures. Sometimes you have the architecture where the messages in the system are um orchestrated by the by the broker.

A

That is a central point um between different applications. um But you need to remember then this.

A

um um This basic thing that, like even driven architecture, is not only broker because like what um and I'm emphasizing it because many people that come to us in api, they want to use us in api and a lot of them come from kafka world or something like this, and they are pretty much thinking just about even driven architecture as an architecture where there is a broker in the middle and your apps do not talk to each other directly, but they talk to each other through the broker.

A

So that's why sometimes people that come from the world of broker-centric architectures they're, pretty much confused with like like why asking api is used to describe what people can do with the app because in the end um they do not interact with applications directly. You know what I mean like they actually interact with the um between each other, but through the broker so um yeah like from their perspective.

A

uh They should uh rather describe what application, um how application behaves um and that's how they feel they should use asking api to describe how application behaves and not how others can work with the um with the app so yeah. That's pretty pretty often confu very confusing for people so but yeah, it's not just a broker in part one. I talked to you about the example of websocket, for example.

A

um Sometimes you will find uh and people find it confusing like um like harassing api, and the decision was to use a a phrase, a word channels to describe um different channels in a broker that people can send messages to, but yeah again, like even driven architectures like the even driven world, is pretty messed up. There's a lot of different patterns, different brokers, protocols uh like um wild wild west and the names are different for different worlds and just remember, like channels are topics um like, for example, in kafka.

A

You have topics, not channels so yeah um yeah in the spec one name had to be chosen, it's channels but yeah. It's basically what people some people understand this topic. Some people understand, excuse me and yeah our best.

A

Our best confusion in asking api is the publish subscribe operations. So basically, whenever you describe what people can do with your application, you um tell people like you, you describe what people um can, for example, do with a specific channel if they can like. Okay, you describe I uh that me as a user.

A

I read your asking api file and I understand that I can publish my message to a given channel and you will receive it or I can subscribe to a specific channel and I will receive messages that your application is sending, and this is this is what is causing this. That's the core of the confusion when people think about asking api as a interface that users use and between people.

A

That think, like asking api, should be used to describe what application does because, like what does it mean like if, in asking api file, you have an operation called publish um people that use your application and they've? Seen your assigned api file information publish that it means that these people can these users can publish messages to this given channel and you will receive them uh yeah. Your application will receive them, but the like people from uh with this approach of like broker-centric, and they like they automatically assume asking apis to describe your application.

A

Behavior uh they're confused, because they, they think publish, means that actually, their application is publishing to the given channel and that's um people very often twist. The meaning.

A

You should definitely like. I did not push yet all the changes. Let me just quickly, do it and refresh the script now real time.

A

Oh yeah, perfect, so um in the script, there's a link to a pretty good article. uh That explains this semantics. Where this confusion, uh confusion about publish subscribes, is coming um is coming from, but just be aware of this um uh issue and, of course, after we refreshing the screen, the zen hub uh button appeared again um the if it comes to the flexibility.

A

The concepts key features, uh something you should know like um asking api is protocol agnostic, um which means that doesn't matter what kind of protocol you're using if it's websocket, if it's um mqtt, async api core features, allow you to describe any application and add this as an addition to this core futuristic announcing api, we have a feature called bindings and bindings is basically a way to describe protocol specific information inside asking api.

A

There's a dedicated repository where we keep all the bindings and you can. I don't think we came up with the like final uh definition of it. um I call them like micro micro specifications um because, like they are they're independent from using api itself, like um from the governance point of view, asking api spec is governed by um some people and then specific bindings for websocket for different protocols.

A

They have sometimes totally different maintainers because, like um yeah, just look just look at that list of all the bindings of for all the protocols- and I bet not all protocols are here so there's a lot, uh there's a lot and it's basically impossible to have one person that is expert in all. So um that's why, for some um protocols, um some different people are taking care of the of the specifications but um but yeah let's the best is always to look at the examples.

A

So uh the example here is the um the mqtt binding and that's how I'm gonna explain to you what it means that asking api is protocol agnostic but then, like you, can still provide some protocol, specific information so um yeah.

A

So you can see that again in the bindings, we have mqtt specification, mqtt binding specification uh that we version separately from the async api spec and you can describe um like you can see that in the markdown file we describe what additional fields can be provided for a specific binding, uh for example, for mqtt and like in case of mqtt.

A

uh One pretty important information is that when you exchange um like when you connect to the um to the broker to the mqtt broker, you have to specify and the client id. So it's pretty specific, it's pretty specific to the to the mqtt protocol and mqtt brokers and therefore we could not have a default uh client id field in async api itself in the core of assetting api.

A

So, basically, what you can do in asking api is that you um say: okay, there's, that's the server, that's how you can all the details about the server like generic information, url, etc, security, uh but then, like you, have binding and you can say okay, but um this is a web socket server. So for this particular web socket server, there are some websocket specific information and still users can provide in a machine, readable format. Some additional protocol, specific information, but they are additions.

A

They are not required, which means like um um again asking api. Its goal is to be protocol agnostic. So whatever is specific for a given protocol goes into the bindings.

A

um Pretty nifty stuff yeah again, let me get rid of zoom.

A

uh Not so actually, multiple message schema formats, so um like um yeah, we need to like again like in even traditional architectures. As I said, it's pretty messed uh world. There are many standards, many protocols and also in case of schemas people might just want to reuse stuff.

A

So async apis has very strong feature that this, in my opinion, which is schema format.

A

So when you're describing your message- and you say how the message should be structured, what fields should be provided in a given um in a given message?

A

We support people to provide different schema formats, um so yeah examples um asking api schema. So, of course, like uh um we like basically asking api schema, is a super set of json schema.

A

So uh it's basically json schema with some additional fields or, let's say um fields that exist, but we extended them a bit. uh I'm gonna go into it into in a second but then open api. So in open api, if you're an open api user, you know that the old versions where um the the schemas um that you could write for your um for the for requests uh in your synchronous api.

A

um It was a bit different version of json schema. It wasn't a super set, so um um so we again like, um if you have your synchronous um apis already in place, you have your op, you use open api and you have your payloads already described using open api. Then, um if you want to plug in and use async api as well uh to describe your asynchronous communication, then you could reuse the payloads that you already have there defined in the system and then there are all the other schemas but yeah.

A

Let me show you an example. What like? Basically, what is the schema uh in general? So let's, let's have a look at this right. So so that's a that's a simple example of of a message, so you have an object with some fields like display name, email and age, and it's a it's a correct message. So um yeah one application can send this message to the broker and it's valid and it's going to go through the broker to to the application and application on the other side of the system.

A

Will will read this message right, but then, um as you can see here, age is a integer. But what? If? What? If somebody makes a mistake- and they say and send a message like somebody- some team made some error in the implementation and they, instead of the number they're, sending a a string information about the age.

A

So how do you? How do you make sure that the incoming message is actually valid? um Like what you do? You basically write a custom validation code, uh so every single message that comes into your application.

A

You have to parse it and then check if age is provided as a number and not um as a string but like luckily, at some time ago, people came up with the approach that, like um this is an object that can be like the validation can be also described in machine readable way.

A

So you don't have to write your own validation, custom validation code. You could actually describe the schema of the message and um and use this schema to actually validate messages like then build tool, generic tool that can consume any json schema, for example, and validate um a a json object against the the schema.

A

So what I mean like okay, so there's a display name, email and age and for example, there is a json schema, one of the one of many schema specifications out there, and here you can see an example like how, in a json format I can describe, and how should the message look like that it should be an object that there are no additional properties allowed and the properties that are allowed is display, name, email and age and pretty important information that you can see here.

A

I can describe that the age property, the value of the age property, must be an integer and then yeah. I can use some library like in case of json, schema it's aj val and then that is implementing the spec. The json schema spec. I just provide this schema and then I can use aj file to check the schema, um the message, the incoming message against the uh the schema to validate, if it's valid or not to if it should be dropped or not.

A

Now, as an api schema, as I said, it's a super set of json schema, um and here you have like. I I don't remember, actually all the um all the additional um stuff we have on top of json schema.

A

I think it's examples uh probably examples as far as I remember it's something that have to be checked in in the spec, but what I know the the most is like this description like so basically, json schema by default description can be just a simple string and in our case we say like no description can be actually something more. It can be a um it can be markdown common marks, so you can see like with json schema.

A

I would use description like this, but with asking api schema, I can do something like that and then yeah in docs, for example, we bought a user in the text now and and then others like avro again like it's just a a different spec, different different way that you can um describe um the the the payload of the of the message.

A

So that's the the same, um the same use case so display name, email and the and and the age, and you can see um like the the idea is the same. Like you, the schema is the way you want to describe how the message should look like just in case of different specs.

A

The information is presented differently, but the concept is the same but yeah. The most important is to know um because, like for some that people that understand already what schemas are, I was pretty boring last five minutes, but yeah um just uh remember that one of the really nice async api features is that you can like by default. We if you do not specify schema format.

A

We assume that you use async api schema to describe your.

A

Message a payload how it should look like, but you can also use schema format to specify like now. Actually I'm I'm my my schema that I provide the nothing api file, it's avro, so please please keep that in mind whenever you're, rendering docs or something else.

A

Now let me scroll a bit and last but not least, something that I think people many many times um forget, and I think it's also, um I don't have proper words in english, but it's like demonized, I'm not sure. If demonized, it's a it's even a word in english, but it's like um I sometimes. I have a feeling that people are afraid a bit of using extensions uh because they are obviously like extensions.

A

Something that is not described in the spec is not supported in all the tools, but that's the best way really to experiment with the spec with new features that would be added to the spec. So it basically means that um yeah.

A

Let me just quickly show you in the studio with yaml, of course, like um let's say like in asking api, I cannot add just a additional element: additional property in the async api document, because the validation will fail because, like only properties that are described in async, api are allowed to be added to as an api file. So um we will fail validation. But if you do.

A

Dash test, then um this will be allowed, so you will be able to pass some custom extension um properties to asking api files in big tech like in enterprises it's commonly used. I would say people don't share much extensions, but it's just the way that they extend async api, but it's because in the enterprises in major majority of cases, people write their own tools uh instead of using the the open source. So they in the end support their extensions.

A

But yeah just remember that it's asking api is extensible, it's limited if it comes to specific properties, but if you want to add something new x dash and and it's gonna work now, two last things is uh and features it's uh for information structure, optimization that this. That's how I call it is it's trades and and references traits uh not sure how much people use it like it's hard for us to understand how people use us in api.

A

But it's uh uh as far as I know, uh people that use raml uh standard, um not open api, but rammel. They should know what trades are.

A

I think we followed actually the same approach, but, to be honest I mean uh the last time I used ram was like ages before and I'm pretty sure I didn't use trades because I would remember, but yeah trades are a way to kind of reuse information inside asking api um document like, for example, um if you use um kafka and yeah kafka also have client id, um and you can say um what type of data is the client id when you connect um with kafka broker, and so that's an information that you would have to repeat in every channel right, at least I think yeah in every operation.

A

Sorry, it's actually operation trade. um So yeah I mean you know um not only developers, but basically every single human. Whenever you do something and you see you're repeating yourself, um I think majority of people like to optimize and they don't like to repeat themselves.

A

um So um that's what traits are for, like you, don't want to repeat the same information every time in every operation, publish or subscribe um in your um in your asking api file. So you just specify operation traits once you call them like kafka, and you say like okay, it's a it's a binding for kafka and that's the information.

A

So um now what you later do is say: okay, like I, have a published operation, and I have some trades and you point to this trade and what basically happens by uh under the hood like what we do in the parser is that we will just.

A

Crap, um what is here and it's gonna, be I basically paste it uh like in using simple words like a paste. That's there in the structure where it was referred to so yeah, basically reusability.

A

Now the other stuff is something that um yeah in short, can be called dollar ref, um it's json references, so it basically means again, like um you could see it with trades like this dollar ref. So it's again for reusability um and the best example without actually explaining. I think the the best is just to see um the example itself.

A

So we have some example of social media uh application that you, like actually social media products that you could write and you have multiple like you- have a backend front-end, some other stuff in your system that build your social media. So you have several asking api documents and um you basically don't want, like.

A

Maybe, let's use different words so, like you have multiple applications in your system and but they exchange the same message like one is publishing a message: the other one is subscribed to it um and in two asking api files, uh you don't want to describe the same message twice like the payload.

A

The json schema, for example, that I told you before, like you don't want to in comments um micro service as an api file, you don't want to put schema there and then just copy paste it in the other async api file, because it's redundancy, it's not even about being efficient uh to not do it. It's also about like avoiding iphone to avoid mistakes like if you have the same information in two places.

A

You already are in a big risk to make some mistake that, when something updates you just update it in the in one file, so refs are to share information uh inside the async api file, but also between using api files or different files. So you can see here um that was this comments service, there's a message that is described in the comments um service and the message.

A

Actually, the whole definition of the message is not here, but it is in some file which is called com messages yaml and it's in the common folder, and it's um comment liked key in the yaml file. So let's, let's go to this yaml file.

A

So common folder, that's okay, message is yaml, that's okay, and was it and I'm too old and I already forgot what was the name.

A

Yeah comment liked and yeah there's a key comment like so basically again what happens um when we parse uh such as api document, um because you want to reuse stuff from other files. What we do is we basically um dereference. That's the process that that's how we call it like. So we there are some references that we directly reference and basically embed uh whatever is there in the other file. We embed it in this file after parsing and yeah. That's so that's!

A

um These are again, at least from my perspective, um like most kick-ass um features in sorry. For that.

A

In asking api um so traits uh for information structure, optimization like references, um extensions.

A

The ability to use sorry- oh my god, my my laptop- is hanging yeah, um the reusable, the the reusability of the um of different schemas, um the protocol agnostic nature of asking api, and this, like uh amazing, bindings feature uh where you can have then like the core async api is without any protocol specific information and then down like on on the bindings level. You can actually plug in some specific um bindings information.

A

Like that's, uh that's kick a kick ass, really uh feature and then just remember always like whenever you use you you're about to write, publish, subscribe, think twice like and most probably you're wrong.

A

um Now uh I don't see any questions there.

A

In the uh in the chat, so I guess you're still following you did not leave the or you left actually, which I also would not be surprised, because the problem is it's like already 48 minutes of the um of the onboarding, and I only covered like the asking api intro like how is this even possible?

A

um I don't want to start with creating the first asking the api file, because I'm gonna speak a lot again like because I um so I'm sorry if you're already tired by this uh onboarding, like that, it's like it's already our like, like taking into account part one part two and now part three. It's already three hours and I still did not finish like, um but I really want to explain every single thing by examples.

A

It's because that's how I learn and I don't I'm not able to teach others in a different way. That's why every single thing I want to show you some example in in in real life, and that makes explanation a bit longer and that's why the creation of the first async api file. I don't want to just show you the file I actually want to create. It live every single line and explain while creating it, and it's definitely not something we can do in 10 minutes like not with me and my slow speaking.

A

So anyone can drop a comment.

A

You, okay with part four.

A

And maybe maybe it's gonna be the last one, maybe, but I'm not hundred percent sure anyone can drop. Any comment like don't feel bad. Oh gosh, it's okay.

A

um Please um but yeah, I know it's holidays, but yeah um next wednesday we're gonna do another onboarding, sorry folks um in the meantime, just remember, especially if somebody's watching that is already experienced and have different views on asking api. I'm super interested with your input to this asking api intro. If you have some other things that you love about asking api or you think it's just basically kick ass in async api that should be highlighted in the intro.

A

A

Please um go to this workshop script and yeah simply open an issue or apr.

A

Okay, folks, like uh so yeah to summarize before I end the live stream, uh I actually uh so I promised to to folks in the invitation that we will create async api file today. But we will do it next wednesday, and today we were only able to do a asympto intro.

A

And remember it takes so much time, not because I think api is complicated, it's because I'm just slow. So um thank you uh to folks that joined, live.

A

Definitely thank you to folks that watch the recording.

A

And the most important is thank you to folks that provide feedback, because that's what I don't get the most and it's super important for me to really get feedback from you. What should be improved in the script? If I may be too detailed, and it's just boring um yeah just let me know.

A

Arrivederci and see you next wednesday or tomorrow, when we talk about passing api conference, cheers.