Hi folks, really happy to be here. Yesterday I had some issues and you can't imagine how
difficult it was to come over. You don't want to know the details, although if there are some
security cameras at the campus and they will release the footage, you're going to see what
happened. So yeah, first of all, like it's an API truck and what the heck is even driven
doing an API truck? Because you're not sure if in your company it happens, but there are
actually many people doing even driven and refusing to call even driven APIs. And many of them
just focus on the events on the schemas. They love talk about like what should be in this
schema, how big this schema should be, if they even should have stayed or not. And even like
two months ago I've talked with one company and they were even asking like tiny questions like
well I really have to have a name or should I just have a reference and what I do later with the
event, if the event is really stateless, what should I do, how should I process things?
But the thing is that in even driven architectures it's not just about events. Of course,
events are still important, but don't be that focused on just one part of even driven architectures.
Now let's try to put all of us on the same page with even driven. First of all, from this slide
which you can learn is that first of all I'm not good in graphics and I'm lazy enough to
not generate diagrams with AI and I like to copy things from others. So that's a diagram from
us in API docs that basically shows you that in even driven architectures, producers and consumers
are totally decoupled, everything goes through the broker so you can have a lot of consumers that
consume messages from one producer and you can also have producers that are also consumers at the
same moment, but the most important is that there's this message broker in the middle and there's
no tight couple between the client and the server. Now in the past when I was doing talks about us
in API in driven, I tried to use different situations in life to explain it. So I did of course
e-commerce but that's boring. I did IoT that's also pretty boring and common. Last time I even
tried with even system in the browser, but today I tried to promote a bit also the us in
API community. So let's talk about us in API community workspace on Slack that really well describes
the architecture of even driven how things work in us in world and especially in open source
communication tool that is purely us in. So what do you have in Slack? You have channels, right?
So you really rarely talk directly to someone and you expect answer immediately, especially in open
source, you should know that yeah, request the play pattern is not really common. So you have
channels and as you can see in the last in API we have something that if you do even driven,
you're already wearing these discussions about, okay? So we're going to have a lot of topics,
a lot of channels in Kafka, but how do we name them? How many details we're going to put in the name
of the channels should we put also a version in the name of the channel? Should we put the name of the
company in the channel? In our case it's pretty easy, we just put numbers. So whenever you add all the
channels for yourself, you see them ordered, it kind of gives you a feeling that it's an official
channel that we try to follow. But you also have channels like in other communities that is just
for announcement. So you have purely communication channel where you have only selected
group of publishers that can publish to the announcement, but anyone can subscribe and consume the messages.
So it's really, really depending on the use cases in even driven, you can have, again, one producer,
many consumers. But it's really, like in our case, of course, sometimes it's a lot of people
in the channel, consuming messages, but that's not always the case. And the messages can be like,
the best is introduction channels. So for us it's a state-change channel where we know that
there's a new member in the community. And we have two types of events there. So one is the message
where you have all the information in the message. So you don't have to look up. There's a new person
joining where the person comes from, what's the experience, what they hear in the community for.
So you have pretty stateful event. But for some people, it's really enough just to have a really
tiny event with the ID of the new member joining the community. And again, in even driven,
you're going to have different types of events depending on your use cases. Now, some channels
are really just one producer, one consumer, talking to each other, breathing internal,
should be avoided, especially in open source. So that's a really screenshot from my screen.
But it's really, for example, for me, it's purely for discussing silly stuff and making jokes.
But in even driven architectures, you should avoid that. Many companies when they start doing
given driven architectures, they really go this direction where the teams do like DMs with themselves.
So one team first, they go to another team, they talk to each other, they have a lot of meetings.
And they agree, okay, you're going to send me the events. They'd one topic just for this particular
communication. Avoid the secret stuff agreed between teams, make sure that everything is
clearly transparently available to the whole organization.
Also, in even driven, you have external connections. That's also come on in Kafka,
you have Kafka connectors, but also in many other cases, the most visible case I see is in
IoT, where you have all the teams, all their services, they integrate over Kafka broker,
but the IoT system communicates over MQTT. So what happens is that everything happens over MQTT,
it goes to MQTT broker, and then it's less an external connection pipe into Kafka, and that's
your integration point. Still, still community, nothing API. So if we have something with Jason Schemafals,
we don't go to their workplace, they workspace. What's the point? Like, if we can connect
to different channels and talk to each other over this connection with external system, let's do it.
In even driven, you also have request reply pattern. So sometimes it happens when you drop a message
that actually somebody will reply, which is nice, and you have threats in Slack. And it's also
getting more common in even driven. The approach that you want to drop a event, and even though
it's async, and you don't expect answer in 200 milliseconds, you still want to get a reply
to this specific message. So that's the request reply pattern. And there are two types of this
pattern, so you can just have a message back, like from Florence, I got a message back to my message,
but sometimes you can just have a small acknowledgement, like a thumbs up. So you can, for example,
later look up the API, the web socket API of Slack. So for example, in Slack, if you want to integrate
with Slack, basically, and you subscribe to some specific event, and you connect over web socket,
the thing is that Slack doesn't want to keep the connection open all the time. They want to
have a connection open with somebody that actually consumes this event. So what you have to do,
that whenever you get an event from Slack, you have to send back a reply with acknowledgement
with the correlation ID of the statement of the event that you received. So you have to acknowledge
that, okay, I received your message, I received your message. So they know that they should keep the
connection open. And in open source, do it, do this acknowledgement. It's pretty important for
open source people. When you drop a message in Slack, if you don't have emojis, you feel like
you're really in a cave, and the world just ended, and you're alone. So please help open source
people to know that there's somebody on the other side. And even driven is also important for
people that do stats, do data analytics. So of course, you want this even driven architecture
setup, also for your data analysis experts, for AI people that want to get this message,
aggregating information in some database, build up information for managers and others to react
to the system. So like for example, we can learn how many people join every year our Slack.
And of course, when we do the stats, we don't call the endpoints directly to get the answers.
It's everything ready in some data based in Slack. You can really, is the export into CSV files.
But there are still even schemas. So majorly in Slack, of course, when we communicate,
it's just type, shrink, right? But there are some channels that like we have a channel,
well, we drop errors from GitHub actions. And they all follow a specific schema, everything is structured,
the given information that we require, it's provided, and then it's displayed in the channel.
In another channel, we have like a schema that we agreed to follow as well. We have a dedicated channel where we send
information about the events that take place or like we send also information about hey,
there's a new blog post, please community help us amplify the message. And we'll always write
these messages in a pretty followed schema that we don't, of course, validate, etc. But we know that
we also want to provide like an overview, we want to provide links to different social media.
So people can pick up links that they actually like to pick up and amplify. And this can be
easily represented as JSON schema. Although in us in the API, you can also have further schemas
like Avro or whatever you want in even driven. But here, and that's actually one, so I'm lazy with
AI, but this one was something to explore. So I actually took the message from Tuli, I put it in
Chad GPD, and I asked for JSON schema, and without any modifications, I actually got a real
good JSON schema that describes the message. And what it means that if we really have this schema,
we really do even driven. We would be able to with the JSON schema, we would be able to validate
the message. So if Tuli next time drops a message, and she forgot about what the required website,
if she forgot to put the website link, then she's going to get a feedback from slug like you kind of
put this message, you have to add the website link because we have a schema. So of course,
in even driven, you still have schemas, different types of schemas, different syntax that you can follow,
even in real-time communication with people. So if that's not an API, then what is it? Like you
have all the important details that every API has to have, it's not really just this schema.
It's security who can access channels, who can read from the channels, how to subscribe,
if you can subscribe or not, all these details have to be described. So if you really focus just on your
schemas, and you forgot about all the other things, then who's going to know about your work?
Seriously, like who's going to know what's the point of just focusing on this event and
having a beautiful, beautiful event. So of course, I think API has the answer, that I'm
and they're going to know if you have us in the API document, if you really follow it,
then you describe everything that is important in the document because it's so simple. Look,
it's just like five components. Of course, the real YAML can be more complex.
I'm not going to show you the YAML, I promise myself to not show YAML to people.
Already a few other people showed YAML to others. But yeah, of course, YAML can be more complex
because you put more and more data and details into YAML file. But this complexity is not on
us in the API. It's even driven architecture. They're complex, and we just try to make it simpler.
So don't blame us. We didn't invent all these protocols. So info, you have an info object in
us in the API document where you can write, hey, it's an us in the API workspace like
that you can use. So we have all the info, what's the purpose, et cetera. You have servers.
So we can also provide the information how to connect to a given Slack workspace or how to connect
to a given Kafka broker or any other message broker. So all the details about how and where
to connect, what's the security on a given server to get a access. Then channels,
like you could see, it's like really the same as Slack channels. So you put all the channels
available in the system, introduction, whatever general, you describe them, you specify what messages
can go inside the channel, this key must of the channels, what's the purpose of the message,
what's the purpose of the channel, et cetera. Then the operations is like the this meet that
you need also for code generation. So you describe what you can actually do as a given in a given
us in API document that describe a client or whatever, you describe okay. So you can actually
send messages to this channel. But in case of the other channel, you can only receive messages.
So you can only sometimes you can be just a producer, sometimes you can be on the consumer,
sometimes you can be both. And sometimes you're going to have operations where you know that you
send a ping and you expect that you're going to get a reply with a pong message.
And the last one is components. So it's like typical dry,
kipid dry. So if you have a lot of messages that are common or schemas that you can reuse,
then of course you're going to put everything into components so you can use references
and reference the reusable components from the system. But it's all
fluff, really like yam, but what really people use it for, it's not just for dogs,
if you didn't know. So last two years I was doing a research with different companies
that's why we also organized asking API conference to give a stage to different people from
different companies to come over to the conference shared. They stories how they actually use
asking API in production. I'm working full-time on asking API five years and I already noticed
that whenever people ask me how they should do things, my opinion doesn't really matter much
because I know it only from a theory point of view. I don't use it anymore in production.
So I only know how people use it. But now it's easy, I just say like, hey, Lego does it this way.
Or some other company does it this way so we can actually much better convince people to use
something like the other big companies. So there's a lot of case studies. A lot of are not visible
on this slide. It's because I decided that I will only promote and describe case studies
that I already know some companies using really in production and implementing in production.
So that's why you, for example, don't see testing, which is pretty common. But simply I didn't
find a nice enough company to share it openly that they do testing. Although I'm pretty sure
they do, actually, I know that they do because they're a really nice testing open source project
called microbes or speckmatic that does really nice implementation of us in API. But yeah, life.
And today I'll focus on two that for me are the most mind blowing that I love the most from
asking the API that people can actually do it. So the first one is infrastructure is code.
Although there's another term next to it architecture is called and it's coming from
guys from Morgan Stanley, not sure if you're familiar, but Linux Foundation,
instead of CNCF or hosting projects like asking API or GraphQL. They also have many other
foundations and one of the think tech foundations is Spin OS and it's for all the think tech industry
and they're working together on open source projects. So the same stuff that I'm calling
infrastructure is called, they call it as architecture is called, they have their tools now building
up for the think tech industry for their website solutions. The other is certification,
something that maybe even somehow relates to the scoring concept, but that's something we learned
in December the last year that there's one organization doing it. But yeah, infrastructure is
code, what does it actually mean? So infrastructure means that asking API document is your configuration
file. And what it means is your configuration file. It's like, like in case of Lego, what happens is
that the infotain tells the other teams, like if you want to gain access to Kafka, you want to
have a new topic in Kafka, or you would like to send messages to Kafka. You have to provide us
an asking API document, nothing else. You just write an asking API document. You upload it to our
endpoint, of course, we'll give you CLI, whatever GitHub action or GitHub action, and then we're
going to consume your asking API document. And out of this asking API document, we're going to call
Azure services to give you proper tokens, success rights, whatever, and then we're going to create
a new topic if it doesn't exist yet in Kafka. And at the end, we're going to take your asking
API document and would publish it to backstage on a deaf portal to have it make it available.
So you get a really nice service out of the box. And you can do it like in hundreds of different
ways, and that's a screenshot I took from the presentation from Kunnago. It's a company that's
like managing shipping ports, and what they do is basically the one that I love the most, because
it's Kubernetes native. So basically asking API document is a source of truth. Dazing on the changes
in asking API document, they generate home charts, and then when they apply the home chart,
what it actually is, what it's applying to the cluster, it's a CRD that is following the
streamsy operator, not sure if your familiar streamsy operator is for Kafka, for Kubernetes,
for managing Kubernetes. And in this streamsy operator, we basically provide the information that you
need the new channel, and out of the box, of course, the operator understands the CRD,
and creates a new channel for a given team for a given service. So everything is really automated,
and you can imagine that you can plug in whatever else you want into the still self-service,
not just publishing dogs, but like validating governance, like whatever, taking schemas and putting
them in the schema registries, and a lot of cool stuff. But the cool as a certification,
so TM forum, TM forum, it's a, anybody familiar with TM forum? Okay, one person.
So I wasn't last year, and then also had a really nice group of contributors from speckmatic
they came in, and they said, like, hey, we're actually working with TM forum on some concept,
and I was saying, and I said, just like, hey, whatever, I don't know what TM forum is,
so I wasn't really excited, but then they came in to Paris, and they said, like, hey,
we're actually an organization that is grouping 800 different telco companies around the world,
and our goal is interoperability of all the systems of all the telco systems. And of course,
one of the solutions for this interoperability is to have a common API. So if you work on an API
that you for selling cell phones, you want all the vendors, all the companies in telco,
follow the same API. So their first approach was let's define open API documents for the
restful communication. But they went really to the not to another level, they decided that
rest is not scalable enough. They want to do request reply pattern for everything, even for simple
things like add something to the car. So let's do everything given ribbon. So they decided to
switch to us in the API. But then how do you make sure that everybody follow the defined us in
the API documents? How you make sure that this particular partner that says, okay, I'm compliant,
how do you actually make sure that they're compliant? So they choose one of the open search tools,
specmatic. That is allowing you to really easily test the implementation basing on the
us in the API document. And they build entire certification on top of it. So if a vendor says,
hey, I have my us in the API document and it's following your us in the API document 100%.
Then of course, they will take your us in the API document. They will put it in this certification
set up that they have and they will say, okay, everything works. You're certified and you're
going to be visible on the portal as a certified API that you can rely on. And everything gets
actually really possible if they just follow the us in the API document. And I love these two
the most because you really can forget about the docs, because they are a side effect. If you
just follow about us in the API as a config or we're doing certification, we really have to take
care of us in the API documents. Then docs will come, they will be always compliant because
if developers don't care about docs, they will take care of them because they anyway have to take
care of us in the API documents to have a pretty good infrastructure set up. If they
break things, then their applications will not work. So you really solve the issue of the docs.
And that would be it. Although I'm saying that docs are a side effect, they are still important.
So at the end of this track, there will be presentation from David who's working on an open
source tool called event catalog. Where still the event catalog put events in place as the
most important thing. So just to make sure my messages don't forget about other things when you
think about events. Events are important, but other things as well. But I'm not saying that the
event catalog or solutions that are around focused on events are bad. Actually they're very good
because in the end, when you consume in even real-enarchitectures, you think about event
because that's what gives you the need. So even catalog is pretty nice because it gives you
this overview of events and all these details that are also later important. They're still
available, but it's all about the focus. And yeah, that's it. Any questions?
Yep. So if I never service, which is publishing messages to talk about it,
it's not that I would come aeration. I think if I don't make it, I would channel and
let's talk about it. But should I put that in operation if you've done publishing messages?
Yes, because then it's clear that your application is sending messages. Because somebody else can
have, for example, in asking if you are document, as a for client generation, and they will
write, okay, I can consume messages. But in your case, you're sending. So you have to specify
the operation that you're sending messages. Because the channel is just saying that there's a channel,
message that the message is accepted on the channel. But if you don't specify if you're sending
on consuming, there's a possibility you would have to send it. Yeah, yeah, yeah.
Yeah, operation is critical. Yeah. Any other questions?
Don't forget about the stickers. Thank you.
you