WEBVTT

00:00.000 --> 00:13.840
Hi folks, really happy to be here. Yesterday I had some issues and you can't imagine how

00:13.840 --> 00:18.400
difficult it was to come over. You don't want to know the details, although if there are some

00:18.400 --> 00:23.600
security cameras at the campus and they will release the footage, you're going to see what

00:23.600 --> 00:32.640
happened. So yeah, first of all, like it's an API truck and what the heck is even driven

00:32.640 --> 00:38.080
doing an API truck? Because you're not sure if in your company it happens, but there are

00:38.080 --> 00:44.880
actually many people doing even driven and refusing to call even driven APIs. And many of them

00:44.880 --> 00:51.520
just focus on the events on the schemas. They love talk about like what should be in this

00:51.520 --> 00:58.560
schema, how big this schema should be, if they even should have stayed or not. And even like

00:58.560 --> 01:03.600
two months ago I've talked with one company and they were even asking like tiny questions like

01:03.600 --> 01:08.080
well I really have to have a name or should I just have a reference and what I do later with the

01:08.080 --> 01:13.920
event, if the event is really stateless, what should I do, how should I process things?

01:13.920 --> 01:19.120
But the thing is that in even driven architectures it's not just about events. Of course,

01:19.120 --> 01:25.840
events are still important, but don't be that focused on just one part of even driven architectures.

01:27.120 --> 01:34.000
Now let's try to put all of us on the same page with even driven. First of all, from this slide

01:34.000 --> 01:39.600
which you can learn is that first of all I'm not good in graphics and I'm lazy enough to

01:39.600 --> 01:45.040
not generate diagrams with AI and I like to copy things from others. So that's a diagram from

01:45.040 --> 01:50.800
us in API docs that basically shows you that in even driven architectures, producers and consumers

01:50.800 --> 01:55.520
are totally decoupled, everything goes through the broker so you can have a lot of consumers that

01:55.520 --> 02:01.040
consume messages from one producer and you can also have producers that are also consumers at the

02:01.040 --> 02:06.400
same moment, but the most important is that there's this message broker in the middle and there's

02:06.400 --> 02:14.480
no tight couple between the client and the server. Now in the past when I was doing talks about us

02:14.480 --> 02:22.080
in API in driven, I tried to use different situations in life to explain it. So I did of course

02:22.080 --> 02:28.320
e-commerce but that's boring. I did IoT that's also pretty boring and common. Last time I even

02:28.320 --> 02:33.360
tried with even system in the browser, but today I tried to promote a bit also the us in

02:33.360 --> 02:41.760
API community. So let's talk about us in API community workspace on Slack that really well describes

02:41.840 --> 02:48.480
the architecture of even driven how things work in us in world and especially in open source

02:48.480 --> 02:56.400
communication tool that is purely us in. So what do you have in Slack? You have channels, right?

02:56.400 --> 03:02.240
So you really rarely talk directly to someone and you expect answer immediately, especially in open

03:02.240 --> 03:11.040
source, you should know that yeah, request the play pattern is not really common. So you have

03:11.040 --> 03:16.720
channels and as you can see in the last in API we have something that if you do even driven,

03:16.720 --> 03:20.240
you're already wearing these discussions about, okay? So we're going to have a lot of topics,

03:20.240 --> 03:26.640
a lot of channels in Kafka, but how do we name them? How many details we're going to put in the name

03:26.640 --> 03:30.720
of the channels should we put also a version in the name of the channel? Should we put the name of the

03:30.720 --> 03:36.880
company in the channel? In our case it's pretty easy, we just put numbers. So whenever you add all the

03:36.880 --> 03:42.080
channels for yourself, you see them ordered, it kind of gives you a feeling that it's an official

03:42.080 --> 03:48.160
channel that we try to follow. But you also have channels like in other communities that is just

03:48.160 --> 03:52.960
for announcement. So you have purely communication channel where you have only selected

03:54.000 --> 04:00.000
group of publishers that can publish to the announcement, but anyone can subscribe and consume the messages.

04:00.080 --> 04:06.400
So it's really, really depending on the use cases in even driven, you can have, again, one producer,

04:06.400 --> 04:13.760
many consumers. But it's really, like in our case, of course, sometimes it's a lot of people

04:13.760 --> 04:20.880
in the channel, consuming messages, but that's not always the case. And the messages can be like,

04:20.880 --> 04:25.680
the best is introduction channels. So for us it's a state-change channel where we know that

04:25.760 --> 04:31.360
there's a new member in the community. And we have two types of events there. So one is the message

04:31.360 --> 04:36.640
where you have all the information in the message. So you don't have to look up. There's a new person

04:36.640 --> 04:42.640
joining where the person comes from, what's the experience, what they hear in the community for.

04:42.640 --> 04:49.120
So you have pretty stateful event. But for some people, it's really enough just to have a really

04:49.920 --> 04:54.880
tiny event with the ID of the new member joining the community. And again, in even driven,

04:54.880 --> 05:01.680
you're going to have different types of events depending on your use cases. Now, some channels

05:02.720 --> 05:09.760
are really just one producer, one consumer, talking to each other, breathing internal,

05:09.760 --> 05:15.680
should be avoided, especially in open source. So that's a really screenshot from my screen.

05:16.240 --> 05:22.080
But it's really, for example, for me, it's purely for discussing silly stuff and making jokes.

05:22.720 --> 05:28.400
But in even driven architectures, you should avoid that. Many companies when they start doing

05:28.400 --> 05:36.080
given driven architectures, they really go this direction where the teams do like DMs with themselves.

05:36.080 --> 05:40.720
So one team first, they go to another team, they talk to each other, they have a lot of meetings.

05:40.720 --> 05:45.040
And they agree, okay, you're going to send me the events. They'd one topic just for this particular

05:45.040 --> 05:51.440
communication. Avoid the secret stuff agreed between teams, make sure that everything is

05:51.440 --> 05:54.400
clearly transparently available to the whole organization.

05:57.040 --> 06:02.880
Also, in even driven, you have external connections. That's also come on in Kafka,

06:02.880 --> 06:09.200
you have Kafka connectors, but also in many other cases, the most visible case I see is in

06:09.200 --> 06:16.000
IoT, where you have all the teams, all their services, they integrate over Kafka broker,

06:16.640 --> 06:22.880
but the IoT system communicates over MQTT. So what happens is that everything happens over MQTT,

06:22.880 --> 06:28.960
it goes to MQTT broker, and then it's less an external connection pipe into Kafka, and that's

06:28.960 --> 06:34.720
your integration point. Still, still community, nothing API. So if we have something with Jason Schemafals,

06:34.720 --> 06:40.960
we don't go to their workplace, they workspace. What's the point? Like, if we can connect

06:40.960 --> 06:45.840
to different channels and talk to each other over this connection with external system, let's do it.

06:49.040 --> 06:53.440
In even driven, you also have request reply pattern. So sometimes it happens when you drop a message

06:53.440 --> 06:59.360
that actually somebody will reply, which is nice, and you have threats in Slack. And it's also

06:59.360 --> 07:05.600
getting more common in even driven. The approach that you want to drop a event, and even though

07:05.680 --> 07:11.920
it's async, and you don't expect answer in 200 milliseconds, you still want to get a reply

07:11.920 --> 07:17.360
to this specific message. So that's the request reply pattern. And there are two types of this

07:18.240 --> 07:24.000
pattern, so you can just have a message back, like from Florence, I got a message back to my message,

07:24.560 --> 07:29.360
but sometimes you can just have a small acknowledgement, like a thumbs up. So you can, for example,

07:29.360 --> 07:35.040
later look up the API, the web socket API of Slack. So for example, in Slack, if you want to integrate

07:35.040 --> 07:40.720
with Slack, basically, and you subscribe to some specific event, and you connect over web socket,

07:41.280 --> 07:48.080
the thing is that Slack doesn't want to keep the connection open all the time. They want to

07:48.080 --> 07:52.640
have a connection open with somebody that actually consumes this event. So what you have to do,

07:52.640 --> 07:58.080
that whenever you get an event from Slack, you have to send back a reply with acknowledgement

07:58.080 --> 08:03.040
with the correlation ID of the statement of the event that you received. So you have to acknowledge

08:03.040 --> 08:06.960
that, okay, I received your message, I received your message. So they know that they should keep the

08:06.960 --> 08:13.760
connection open. And in open source, do it, do this acknowledgement. It's pretty important for

08:13.760 --> 08:18.080
open source people. When you drop a message in Slack, if you don't have emojis, you feel like

08:18.080 --> 08:23.600
you're really in a cave, and the world just ended, and you're alone. So please help open source

08:23.680 --> 08:33.840
people to know that there's somebody on the other side. And even driven is also important for

08:33.840 --> 08:39.840
people that do stats, do data analytics. So of course, you want this even driven architecture

08:39.840 --> 08:47.040
setup, also for your data analysis experts, for AI people that want to get this message,

08:47.040 --> 08:53.760
aggregating information in some database, build up information for managers and others to react

08:53.760 --> 09:00.800
to the system. So like for example, we can learn how many people join every year our Slack.

09:00.800 --> 09:07.040
And of course, when we do the stats, we don't call the endpoints directly to get the answers.

09:07.040 --> 09:13.360
It's everything ready in some data based in Slack. You can really, is the export into CSV files.

09:13.440 --> 09:23.680
But there are still even schemas. So majorly in Slack, of course, when we communicate,

09:23.680 --> 09:28.480
it's just type, shrink, right? But there are some channels that like we have a channel,

09:28.480 --> 09:36.160
well, we drop errors from GitHub actions. And they all follow a specific schema, everything is structured,

09:36.720 --> 09:40.720
the given information that we require, it's provided, and then it's displayed in the channel.

09:41.680 --> 09:47.520
In another channel, we have like a schema that we agreed to follow as well. We have a dedicated channel where we send

09:47.520 --> 09:54.720
information about the events that take place or like we send also information about hey,

09:54.720 --> 09:59.200
there's a new blog post, please community help us amplify the message. And we'll always write

09:59.200 --> 10:06.240
these messages in a pretty followed schema that we don't, of course, validate, etc. But we know that

10:06.320 --> 10:10.640
we also want to provide like an overview, we want to provide links to different social media.

10:10.640 --> 10:17.120
So people can pick up links that they actually like to pick up and amplify. And this can be

10:17.120 --> 10:23.120
easily represented as JSON schema. Although in us in the API, you can also have further schemas

10:23.120 --> 10:29.440
like Avro or whatever you want in even driven. But here, and that's actually one, so I'm lazy with

10:29.440 --> 10:34.320
AI, but this one was something to explore. So I actually took the message from Tuli, I put it in

10:34.400 --> 10:39.840
Chad GPD, and I asked for JSON schema, and without any modifications, I actually got a real

10:40.960 --> 10:45.600
good JSON schema that describes the message. And what it means that if we really have this schema,

10:45.600 --> 10:50.560
we really do even driven. We would be able to with the JSON schema, we would be able to validate

10:50.560 --> 10:56.640
the message. So if Tuli next time drops a message, and she forgot about what the required website,

10:57.200 --> 11:01.520
if she forgot to put the website link, then she's going to get a feedback from slug like you kind of

11:01.520 --> 11:07.200
put this message, you have to add the website link because we have a schema. So of course,

11:07.200 --> 11:12.240
in even driven, you still have schemas, different types of schemas, different syntax that you can follow,

11:14.560 --> 11:20.560
even in real-time communication with people. So if that's not an API, then what is it? Like you

11:20.560 --> 11:29.520
have all the important details that every API has to have, it's not really just this schema.

11:29.600 --> 11:35.360
It's security who can access channels, who can read from the channels, how to subscribe,

11:35.360 --> 11:40.960
if you can subscribe or not, all these details have to be described. So if you really focus just on your

11:40.960 --> 11:47.360
schemas, and you forgot about all the other things, then who's going to know about your work?

11:49.120 --> 11:52.320
Seriously, like who's going to know what's the point of just focusing on this event and

11:52.320 --> 11:58.000
having a beautiful, beautiful event. So of course, I think API has the answer, that I'm

12:01.120 --> 12:05.360
and they're going to know if you have us in the API document, if you really follow it,

12:05.360 --> 12:09.920
then you describe everything that is important in the document because it's so simple. Look,

12:10.960 --> 12:16.400
it's just like five components. Of course, the real YAML can be more complex.

12:17.120 --> 12:21.040
I'm not going to show you the YAML, I promise myself to not show YAML to people.

12:23.120 --> 12:28.880
Already a few other people showed YAML to others. But yeah, of course, YAML can be more complex

12:28.880 --> 12:34.880
because you put more and more data and details into YAML file. But this complexity is not on

12:34.880 --> 12:40.160
us in the API. It's even driven architecture. They're complex, and we just try to make it simpler.

12:41.120 --> 12:48.080
So don't blame us. We didn't invent all these protocols. So info, you have an info object in

12:48.080 --> 12:51.840
us in the API document where you can write, hey, it's an us in the API workspace like

12:53.440 --> 12:59.280
that you can use. So we have all the info, what's the purpose, et cetera. You have servers.

12:59.280 --> 13:04.160
So we can also provide the information how to connect to a given Slack workspace or how to connect

13:04.160 --> 13:11.520
to a given Kafka broker or any other message broker. So all the details about how and where

13:11.520 --> 13:17.280
to connect, what's the security on a given server to get a access. Then channels,

13:18.720 --> 13:23.440
like you could see, it's like really the same as Slack channels. So you put all the channels

13:23.440 --> 13:30.240
available in the system, introduction, whatever general, you describe them, you specify what messages

13:30.240 --> 13:36.480
can go inside the channel, this key must of the channels, what's the purpose of the message,

13:36.480 --> 13:41.680
what's the purpose of the channel, et cetera. Then the operations is like the this meet that

13:41.680 --> 13:47.840
you need also for code generation. So you describe what you can actually do as a given in a given

13:47.840 --> 13:53.360
us in API document that describe a client or whatever, you describe okay. So you can actually

13:53.360 --> 13:59.040
send messages to this channel. But in case of the other channel, you can only receive messages.

13:59.040 --> 14:04.240
So you can only sometimes you can be just a producer, sometimes you can be on the consumer,

14:04.560 --> 14:08.320
sometimes you can be both. And sometimes you're going to have operations where you know that you

14:08.320 --> 14:13.280
send a ping and you expect that you're going to get a reply with a pong message.

14:15.440 --> 14:20.240
And the last one is components. So it's like typical dry,

14:20.240 --> 14:25.840
kipid dry. So if you have a lot of messages that are common or schemas that you can reuse,

14:25.840 --> 14:31.040
then of course you're going to put everything into components so you can use references

14:31.120 --> 14:39.600
and reference the reusable components from the system. But it's all

14:40.560 --> 14:46.640
fluff, really like yam, but what really people use it for, it's not just for dogs,

14:48.320 --> 14:54.800
if you didn't know. So last two years I was doing a research with different companies

14:54.800 --> 14:59.440
that's why we also organized asking API conference to give a stage to different people from

14:59.440 --> 15:03.920
different companies to come over to the conference shared. They stories how they actually use

15:03.920 --> 15:10.960
asking API in production. I'm working full-time on asking API five years and I already noticed

15:10.960 --> 15:16.320
that whenever people ask me how they should do things, my opinion doesn't really matter much

15:16.320 --> 15:22.400
because I know it only from a theory point of view. I don't use it anymore in production.

15:22.400 --> 15:27.680
So I only know how people use it. But now it's easy, I just say like, hey, Lego does it this way.

15:27.680 --> 15:32.240
Or some other company does it this way so we can actually much better convince people to use

15:32.240 --> 15:40.240
something like the other big companies. So there's a lot of case studies. A lot of are not visible

15:40.240 --> 15:46.240
on this slide. It's because I decided that I will only promote and describe case studies

15:46.240 --> 15:50.320
that I already know some companies using really in production and implementing in production.

15:50.960 --> 15:55.680
So that's why you, for example, don't see testing, which is pretty common. But simply I didn't

15:55.680 --> 16:01.200
find a nice enough company to share it openly that they do testing. Although I'm pretty sure

16:01.200 --> 16:05.440
they do, actually, I know that they do because they're a really nice testing open source project

16:05.440 --> 16:11.440
called microbes or speckmatic that does really nice implementation of us in API. But yeah, life.

16:12.240 --> 16:20.320
And today I'll focus on two that for me are the most mind blowing that I love the most from

16:20.320 --> 16:25.920
asking the API that people can actually do it. So the first one is infrastructure is code.

16:25.920 --> 16:30.800
Although there's another term next to it architecture is called and it's coming from

16:30.800 --> 16:34.880
guys from Morgan Stanley, not sure if you're familiar, but Linux Foundation,

16:34.880 --> 16:41.440
instead of CNCF or hosting projects like asking API or GraphQL. They also have many other

16:41.440 --> 16:47.520
foundations and one of the think tech foundations is Spin OS and it's for all the think tech industry

16:47.520 --> 16:52.960
and they're working together on open source projects. So the same stuff that I'm calling

16:52.960 --> 16:58.480
infrastructure is called, they call it as architecture is called, they have their tools now building

16:58.480 --> 17:05.440
up for the think tech industry for their website solutions. The other is certification,

17:05.760 --> 17:11.920
something that maybe even somehow relates to the scoring concept, but that's something we learned

17:11.920 --> 17:18.480
in December the last year that there's one organization doing it. But yeah, infrastructure is

17:18.480 --> 17:25.840
code, what does it actually mean? So infrastructure means that asking API document is your configuration

17:25.840 --> 17:33.280
file. And what it means is your configuration file. It's like, like in case of Lego, what happens is

17:33.280 --> 17:40.240
that the infotain tells the other teams, like if you want to gain access to Kafka, you want to

17:40.240 --> 17:45.760
have a new topic in Kafka, or you would like to send messages to Kafka. You have to provide us

17:45.760 --> 17:51.520
an asking API document, nothing else. You just write an asking API document. You upload it to our

17:51.520 --> 17:57.280
endpoint, of course, we'll give you CLI, whatever GitHub action or GitHub action, and then we're

17:57.280 --> 18:02.240
going to consume your asking API document. And out of this asking API document, we're going to call

18:02.240 --> 18:08.400
Azure services to give you proper tokens, success rights, whatever, and then we're going to create

18:08.400 --> 18:12.640
a new topic if it doesn't exist yet in Kafka. And at the end, we're going to take your asking

18:12.640 --> 18:18.240
API document and would publish it to backstage on a deaf portal to have it make it available.

18:18.240 --> 18:24.080
So you get a really nice service out of the box. And you can do it like in hundreds of different

18:24.080 --> 18:29.520
ways, and that's a screenshot I took from the presentation from Kunnago. It's a company that's

18:29.520 --> 18:36.960
like managing shipping ports, and what they do is basically the one that I love the most, because

18:36.960 --> 18:42.960
it's Kubernetes native. So basically asking API document is a source of truth. Dazing on the changes

18:42.960 --> 18:48.240
in asking API document, they generate home charts, and then when they apply the home chart,

18:48.240 --> 18:53.680
what it actually is, what it's applying to the cluster, it's a CRD that is following the

18:53.680 --> 18:58.800
streamsy operator, not sure if your familiar streamsy operator is for Kafka, for Kubernetes,

18:58.800 --> 19:03.280
for managing Kubernetes. And in this streamsy operator, we basically provide the information that you

19:03.280 --> 19:08.240
need the new channel, and out of the box, of course, the operator understands the CRD,

19:08.240 --> 19:14.720
and creates a new channel for a given team for a given service. So everything is really automated,

19:14.720 --> 19:20.000
and you can imagine that you can plug in whatever else you want into the still self-service,

19:20.000 --> 19:27.360
not just publishing dogs, but like validating governance, like whatever, taking schemas and putting

19:27.440 --> 19:35.200
them in the schema registries, and a lot of cool stuff. But the cool as a certification,

19:36.320 --> 19:43.040
so TM forum, TM forum, it's a, anybody familiar with TM forum? Okay, one person.

19:44.000 --> 19:50.000
So I wasn't last year, and then also had a really nice group of contributors from speckmatic

19:50.000 --> 19:54.160
they came in, and they said, like, hey, we're actually working with TM forum on some concept,

19:54.240 --> 19:58.320
and I was saying, and I said, just like, hey, whatever, I don't know what TM forum is,

19:58.320 --> 20:04.080
so I wasn't really excited, but then they came in to Paris, and they said, like, hey,

20:04.080 --> 20:09.200
we're actually an organization that is grouping 800 different telco companies around the world,

20:09.200 --> 20:14.480
and our goal is interoperability of all the systems of all the telco systems. And of course,

20:14.480 --> 20:23.520
one of the solutions for this interoperability is to have a common API. So if you work on an API

20:23.600 --> 20:29.360
that you for selling cell phones, you want all the vendors, all the companies in telco,

20:29.360 --> 20:34.720
follow the same API. So their first approach was let's define open API documents for the

20:34.720 --> 20:41.280
restful communication. But they went really to the not to another level, they decided that

20:42.320 --> 20:48.640
rest is not scalable enough. They want to do request reply pattern for everything, even for simple

20:48.640 --> 20:54.320
things like add something to the car. So let's do everything given ribbon. So they decided to

20:54.320 --> 21:02.400
switch to us in the API. But then how do you make sure that everybody follow the defined us in

21:02.400 --> 21:08.960
the API documents? How you make sure that this particular partner that says, okay, I'm compliant,

21:08.960 --> 21:13.760
how do you actually make sure that they're compliant? So they choose one of the open search tools,

21:13.760 --> 21:20.320
specmatic. That is allowing you to really easily test the implementation basing on the

21:20.320 --> 21:27.040
us in the API document. And they build entire certification on top of it. So if a vendor says,

21:27.040 --> 21:32.560
hey, I have my us in the API document and it's following your us in the API document 100%.

21:33.280 --> 21:37.920
Then of course, they will take your us in the API document. They will put it in this certification

21:38.000 --> 21:43.600
set up that they have and they will say, okay, everything works. You're certified and you're

21:43.600 --> 21:49.440
going to be visible on the portal as a certified API that you can rely on. And everything gets

21:49.440 --> 21:55.680
actually really possible if they just follow the us in the API document. And I love these two

21:55.680 --> 22:04.320
the most because you really can forget about the docs, because they are a side effect. If you

22:04.320 --> 22:09.360
just follow about us in the API as a config or we're doing certification, we really have to take

22:09.360 --> 22:16.000
care of us in the API documents. Then docs will come, they will be always compliant because

22:17.120 --> 22:22.560
if developers don't care about docs, they will take care of them because they anyway have to take

22:22.560 --> 22:27.440
care of us in the API documents to have a pretty good infrastructure set up. If they

22:27.440 --> 22:36.880
break things, then their applications will not work. So you really solve the issue of the docs.

22:39.120 --> 22:45.360
And that would be it. Although I'm saying that docs are a side effect, they are still important.

22:46.000 --> 22:52.480
So at the end of this track, there will be presentation from David who's working on an open

22:52.480 --> 22:58.960
source tool called event catalog. Where still the event catalog put events in place as the

22:58.960 --> 23:05.760
most important thing. So just to make sure my messages don't forget about other things when you

23:05.760 --> 23:11.040
think about events. Events are important, but other things as well. But I'm not saying that the

23:11.040 --> 23:16.800
event catalog or solutions that are around focused on events are bad. Actually they're very good

23:16.880 --> 23:21.600
because in the end, when you consume in even real-enarchitectures, you think about event

23:22.400 --> 23:27.840
because that's what gives you the need. So even catalog is pretty nice because it gives you

23:27.840 --> 23:33.360
this overview of events and all these details that are also later important. They're still

23:33.360 --> 23:39.840
available, but it's all about the focus. And yeah, that's it. Any questions?

23:47.680 --> 23:54.880
Yep. So if I never service, which is publishing messages to talk about it,

23:54.880 --> 24:03.200
it's not that I would come aeration. I think if I don't make it, I would channel and

24:03.200 --> 24:08.560
let's talk about it. But should I put that in operation if you've done publishing messages?

24:08.560 --> 24:14.720
Yes, because then it's clear that your application is sending messages. Because somebody else can

24:14.720 --> 24:19.760
have, for example, in asking if you are document, as a for client generation, and they will

24:19.760 --> 24:24.800
write, okay, I can consume messages. But in your case, you're sending. So you have to specify

24:24.800 --> 24:29.840
the operation that you're sending messages. Because the channel is just saying that there's a channel,

24:30.400 --> 24:34.960
message that the message is accepted on the channel. But if you don't specify if you're sending

24:34.960 --> 24:44.160
on consuming, there's a possibility you would have to send it. Yeah, yeah, yeah.

24:44.160 --> 24:53.120
Yeah, operation is critical. Yeah. Any other questions?

24:55.760 --> 24:59.440
Don't forget about the stickers. Thank you.

25:14.160 --> 25:16.160
you

25:44.160 --> 25:46.160
you

26:14.160 --> 26:16.160
you