Loosely Coupled - Adopting Event-Driven Architecture

Hello, hello, good evening, good afternoon, good morning, or well, maybe good night for some people watching in India, if anybody is in India.

Welcome to loosely coupled, our first live stream from bridging the gap.

I'm your host, I'm the co-founder of bridging the gap, an open source project aiming at educating about enterprise application integration.

With this stream, I want to bring some interesting topics loosely coupled with the field of application integration, and very loosely coupled with technical topics.

Now I made a mistake of having too many windows open, so I'm actually hearing myself all over the place.

All right.

A little bit of housekeeping.

We're live on YouTube.

We're live on LinkedIn.

Please keep the comments and questions and everything coming.

If something will be relevant for the topic, we'll be showing that on stream and asking that directly.

If not, we will still have some time at the end for a Q&A.

And with that, let me welcome our first guest to this lovely live stream.

First edition, Fran Mendes.

Hello, Fran.

Hello.

Well, how is your evening so far in Spain?

Packed and hot.

As you can imagine, I'm in the south, I'm in Balakot next to Portugal.

And, you know, we have a saying here that 35 degrees Celsius is getting cold, you know.

So, yeah, it's not getting cold.

It's quite toasty in the Netherlands as well.

The morning was cloudy and a little bit chilly, but the afternoon is quite, quite, quite warm.

So, very nice indeed.

All right.

We're having a lovely topic today related to enterprise application integration and software architecture as it is.

We're talking about event-driven architecture.

And who better to talk about event-driven architecture than the creator of Async API himself?

So, Fran, tell us a little bit first about Async API and your context and your background here.

So, for the people who don't know you, who only heard about Async API from, let's say, when they used MuleSoft or Solace or any other technology, so they have the proper context of who you are and what the hell is Async API and why did you even create that?

Oh, that's a lot.

Yeah.

I can own the whole live stream just with that.

Let's keep that part brief.

So, yeah, my name is Fran Mendez.

I live in Spain, as I mentioned.

I don't even know how to categorise myself.

Like, I've been a director of engineering in my last position, but before I was a manager, but before I was an architect, but before I was a CTO.

So, I've been, like, jumping from role to role.

And I keep saying that I'm just an engineer, and I do whatever it's needed to do, and I'm always adapting to whatever it's needed in each situation.

So, I don't like to label myself as one thing, for the good, for the bad.

And, yeah, so, I created Async API, as Karol mentioned.

So, this was almost nine years ago.

And the reason I created Async API, it was just for me.

It might sound egocentric looking back or explaining it like this.

But the reality is that I wasn't expecting this kind of success.

I was just building it for me for two reasons.

One of them is I wanted to learn OpenAPI well.

So, I had to create Async API.

I had to go from top to bottom of OpenAPI specification and read it and change whatever didn't make sense to me.

Didn't make sense for my use case.

And what was my use case?

That's the second reason.

My use case was I was using RabbitMQ to coordinate some microservices and, you know, and communicate between them and so on.

I was building an event-driven architecture.

And there was nothing like OpenAPI for that.

So, I decided to go ahead and modify OpenAPI.

In the beginning, it was mostly me.

Like, okay, maybe when it says get, the documentation generator can say subscribe.

And when it says post or something else, it can say publish.

And that might do the trick.

Well, for documentation, it kind of did the trick.

For code generation, not so much.

It felt a lot like a hack.

It was a hack.

So, yeah.

And then that's when I realised I had to go through the whole thing and change it.

And it was all done in open source because that's always my default.

So, I was not...

I already had, like, a bunch of other open source projects, but they never took off.

And this one started taking off because, you know, I started talking about it in conferences.

And I saw some interest from people and so on.

And it started to show some traction, let's say.

So, I created Slack and so on.

And started inviting people there.

In the beginning, it was me mainly talking to the wall, as we say in Spanish.

So, I was just like, hey, so today I did this.

And today I added that.

And the funny thing is that the other people on the Slack was the people from my own company, from the company I was working on.

And they already knew that.

And they were like, hey, we don't care, friend.

We already know.

So, they were not interacting with me.

And that was funny and desparating at the same time.

But eventually people start getting in and asking and so on.

So, yeah.

So, that was...

And here we are.

Here we are.

And now I had a look through the async API Slack.

Wow, that's a busy place.

I get so many messages.

There are so many pull requests going through the channel.

So many conversations happening around various topics.

It's crazy.

And so many people participating also with the async API conf and all that.

And I already saw a few streams online of the community.

It's interesting how that can grow.

Yeah, this is something I would love to highlight is we do everything in the open.

So, we aim for total transparency.

Not as a way to...

Not as a way to show off or something like that.

Or to justify our behaviour or something like that.

Because we believe in transparency, in radical transparency.

So, we try to do everything in the open.

We are conscious.

We are aware that just because you make everything in the open, it's not necessarily transparent.

You need to publicise it.

You need to advertise it so people know where this information is and how to consume it and so on.

We try to do it, but as you said, we generate a lot of content that is almost impossible for us to promote all the content we create.

All these live streams, all these meetings and so on.

So, meetings are not recorded.

They are live streamed.

Always.

All the meetings.

Unless there's something like code of contact stuff that is obviously handled separately for privacy reasons.

But other than that, everything is open.

Everything is live streamed.

And that's really cool because when someone wants to land on the community, the only thing they have to do, the only thing, is to start watching these live streams.

Start joining these meetings if they can.

If not, they can watch the recording.

Following these certain issues on their favourite repo and so on.

And it's really...

And it's easier, I would say, to get on board.

It's not easy.

It's easier.

It's not easy, though.

Because, as you said, it's huge.

It became a huge project with lots of people.

So, filtering in the noise is always different.

Okay.

But we met today to talk about even-driven architecture.

An adoption of said even-driven architecture.

Now, the key question I have is, how would you define even-driven architecture?

Because I'm pretty certain that from your perspective, the definition's a little bit different than from my perspective.

Okay.

So, I mean, in general terms, I would say, I want to make a...

I want to clarify something here.

So, we often talk about even-driven architecture.

All of us, including myself, when we mean message-driven architecture, right?

What's the difference?

So, to me, I don't think it's only to me, but the difference is in the meaning of the message, right?

So, message is like the broad concept.

There's a piece of data flowing, usually through a broker, from producers to consumers, and so on, right?

But to me, even-driven architecture is when you work with events, with facts that happened, right?

That's it.

Like, you send events to a broker and consume them from other consumers, and so on.

For which purpose?

That's not defining the term to me.

That's something that's kept open, right?

So, I just live there.

Even-driven architecture is something that is...

It's a kind of architecture that usually relies on a broker and where you exchange events as facts, let's say, right?

But some people, as I said, like, some people also, including myself sometimes, because it's useful to talk about EBA all the time, if you send an action, a command, and expect a response over a broker, which is also possible, we sometimes also talk about these things as even-driven architecture.

When it's not, it's not an event, right?

It's a command.

But that's a different discussion, let's say.

So, that's what I live at usually.

This can be just to communicate microservices in your team, your domain, or something, or it can be as a means to integrate, to build integrations inside your company, or with partners, or with public, you know, with the public audience.

That depends on your business.

For instance, robotics.

We see a lot of this in robotics with MQTT.

They offer their open API as an I think you pay file defining an MQTT API, right?

So, and anyone can consume it, right?

Anyone, you only have to apply for a token.

And that's it as a token that it's going to be prepared to your MQTT topics and so on.

So, it's effectively like the counterpart, or let's say the sister of a public REST API, but using MQTT in this case, right?

So, yeah, there are many usages of event-driven architecture.

There is a talk that we have it on the Cinque Bay website on the documentation.

It's linked there from Martin Fowler.

And the talk is titled, the many meanings of event-driven architecture.

And I think that perfectly illustrates what I mean, this talk.

So, if you go to the website, and you go to the documentation, if not the first page, one of the first pages, I'm sorry because I don't follow closely the docs anymore.

It's too much.

It's fine.

But I'm sure we can find it later and put it in the description of the recordings for people to find.

That's going to be fine.

See, one of the highlights I have in terms of event-driven architecture, I have two perspectives on that.

First one is the interoperability and the way we design communication within the system, which, for example, like microservices, microservices go well with event-driven and choreography and all that, right?

Which is usually not of my concern because I don't design domain systems.

I look always on an ecosystem level, so the communication and interactions between various systems.

And there, event-driven architecture has a lot to do, but it differs slightly in certain areas, like, for example, do we use data-based contracts or key-based contracts?

So like anaemic events, usually in business systems, key-based contracts would be quite normal, while in ecosystems, they're actually more of a considered as an anti-pattern.

So there are these kind of small discrepancies of what would be acceptable on the level of a system using EDA and what would be acceptable on the level of an ecosystem using EDA.

Then also the differences are like the sets of patterns sometimes differ or what is the database topology.

So we usually work with completely distributed separate databases, separate sets of models, data, everything separated.

So that's my kind of take on EDA.

For me, these are just two types which drive my conversations in enterprise application integration at least.

I would say even more than two types.

It's like inside a certain domain, a domain understood as a domain-driven design.

It's inside a single domain to coordinate stuff in between a domain.

Sometimes you have services or microservices inside the same domain and they need to coordinate for whatever reason.

Usually these events are not useful for anyone other than these people in this domain.

But then you have cross-domain that starts behaving as integration as well, but inside the company, inside the organisation, doesn't have to be a company.

But then you have cross-organisation.

Cross-organisations in plural, and you have partners, integrations, and so on, or public.

So the scope can go well beyond my truth.

The funny thing is, because I've been sitting recently with a lot of domain-driven design people and discussing the overlaps of domain-driven design and interoperability topics, and the most amazing thing is that actually if you look at it from the perspective of domains, a domain can span across several systems.

And a specific system may represent within itself several domains.

So those overlays we can draw over those system boundaries and different block diagrams are quite elaborate at times, depending on how the company was built, how much design went up front into those systems.

And then the world of cloud comes in and with SaaS solutions, everything is wrecked all over again because obviously SaaS solutions have a completely different philosophy and they again represent multiple domains.

And it's over a layer, on a layer, on a layer, depending how we want to approach those layers, but there's so much to it to walk around.

And with that so much, I think there's a level of hidden chaos in all ecosystems.

I mean, entropy creeps in everywhere, so I would guess sooner or later everybody will experience chaos somewhere.

But in terms of even-driven architecture, I think one of the biggest challenges of a hidden chaos might be the overall lack of standards in a lot of companies or a lot of organisations.

While we have very robust standards for synchronous communication, I think not a lot of companies actually know how to standardise async.

Yep.

What's your take on that?

That's a good point, actually.

You're touching on the point of governance, right?

So there are standards.

There's async API.

There's cloud events that Alexander has mentioned on the LinkedIn comment.

There are a lot of different standards for messaging.

Then you have Avra.

Then you have for schema definition, right?

It's the schema itself.

Then you have this protobuf and so on.

So there are many different layers, different levels, but there are different standards for that.

Now, the thing is that it's funny.

Something that I'm seeing lately is that maybe I'm biassed.

So bear with me.

But way more companies now are starting to adopt an API-first mindset.

And I'm talking about synchronous, right?

So now they are starting now.

It's like the bulk of it, the bulk of the companies like everywhere you look around or almost everywhere you look around in tech companies or in companies with a mature, let's say, technical team.

You'll see more and more people adopting open API, adopting API-first mindset and so on, right?

So that's cool.

That's really good.

But that's just, to me, as I see it, that's just starting to happen now.

It started to happen many years ago.

But now is when I'm seeing it like, oh, it's starting to be everywhere.

Cool.

That's good.

Finally.

It only took us 20 years now, not 20.

But yeah, like when I was working, when I created this in KPI, we were already building a product to work with open API.

So open API was already around, not Swagger, open API.

So open API was already like, Swagger was already renamed by then.

So it means that it was there for a while already.

What I mean with this, and this reminds me to a panel I got invited in Silicon Valley, I think 2018, or something like that.

And I was there.

I remember my phone sitting there in the panel and listening to everyone, not speaking at all, and thinking, everyone was saying that how cool open API was, how cool, how everyone was using standards, how beautiful everything was, right?

And I was just sitting there and it's like, that's not what I'm seeing.

Like, what's wrong with this?

Like, is it just me that I'm not seeing enough or what's happening?

And I recall someone from the event, I don't recall the name of the guy, sorry for that, but someone from the event said, like, mentioned my comment in Twitter, I think.

And he was like, the point, the whole point of the day was this take by friend and they're saying, hey, get down to earth, like, this is pretty cool.

But we're just a bunch of us using it, right?

Like, we're those nerds that love APIs and open API and so on and API first and sign first and we're thinking about these things, but nobody cares, nobody out there cares, right?

Many people are building microservices and they don't even know what open API or Swagger is.

And it's not that they care about or not, it's that they don't even know what it is.

They don't even know it exists.

I'm talking about 2018, right?

And I was like, I don't want to disappoint people here, but my feeling is that this is still very niche, looking as API nerds, right?

Then now I'm seeing this with this in KPI as well, or with even driven architecture, driven in this case by this in KPI and or cloud events.

I'm seeing that more and more companies are adopting it.

But it's still very early in the days for these companies to even, some of them, they don't even know if these standards exist, right?

And I could even, I could see it from the Postman surveys.

So Postman was organising a survey every year and I think it was around 1% of people knew what ACMPI was.

And I was like, I know it's a very specific target audience, APIs, but precisely, it's very related.

It's actually coming from that same world when I created this in KPI, I created it from OpenAPI.

And I was always advocating for it on API days conferences and in API related conferences because that was when I was feeling comfortable, not for any other reason.

But you know what, I was like, when you're talking about the standards and the old nerds like hyping about those standards, I'm like looking back at my career, when I started doing application integration, REST was nowhere to be found.

Nobody was using JSON because it was non-existent.

We were using XML.

It's still nowhere to be found, REST. I'm going to get to that one in a moment.

So looking back 14 years ago when I started as a junior developer, we were building SOAP services over HTTP or SOAP services over JMS. And that was already a very robust standard and was already a very established standard.

Very rigid, had to be very precise, so it was very prone to errors.

You could do a lot of errors and everything will be just returning you a 500 HTTP error, right?

Which is fine because where I worked, we actually needed very high rigid standardisation of the APIs so that we can have that quality of data.

But even though that was a very established standard at the time, we still stumbled into people who had no idea what they were doing, even if they were senior, right?

So I remember this lovely conversation some time ago where somebody was debugging a SOAP service and the guy had no idea why it was not working.

The message was sent according to specs.

The specs said that the specific element could be empty.

Like no string at all, right?

So basically in the XML, they got an empty tag.

So a tag that doesn't have two elements has one element so it's already closed.

Self-contained, yeah.

And I remember the lovely comment from that developer debugging that communication because it was wrongly interpreted.

It's like, I'm getting a very weird tag here.

It's neither open nor closed.

I don't know what that is.

And I'm like sitting there and it's like, after a few years later, I mean, when I started doing proper research into interoperability and why we're doing certain things the way we are doing things and I started reading the specification of our XML, I was like, that self-contained tag is in the first version of the specification.

It's old as hell.

It was there for a reason.

It's pretty common in HTML as well, yeah.

Yeah, exactly.

The new line tag, that's basically what it is, right?

Line, link, all this stuff, yeah.

Yeah, plenty of those.

And I was like, right, perfect.

So we have standards but nobody actually even reads them.

They apply to the use case.

Sometimes good, sometimes bad.

And now looking at the REST standard, I would say that over 95% of REST services are not aligned with the REST standard.

We call them REST services, but they're not actually up to par.

They don't have the next page.

They don't have the related objects, nothing like that.

We just use this to convey messages based on crude, create, read, update, delete.

And we have standards.

But who read the REST API standard?

I mean, hands up, probably nobody, other than the two of us, I would guess.

No, no, no, I haven't.

I just went through it like a little bit, but couldn't finish it.

I mean, it's an interesting one, probably.

I just didn't have the time or energy to do it, or even the need to do it.

So if I have had the need, probably I will have done it, and that's fine.

Yeah, the need is also quite important.

So I never had the need to have, let's say, a proper REST API.

Because what you said, even consuming this kind of APIs will become more difficult for teams that are already like being pressured to deliver quickly, quickly, quickly.

Right?

So yeah, this sort of SCRAM methodology that we have been applying for the last decade, it's a little bit of a culprit there as well for telling people that you should be rushing out and delivering things quickly in the next two weeks without looking farther than just two weeks.

So I know it's not exactly what SCRAM says, but that's how it was usually applied.

So in the end, we'll get back to the same thing.

So basically we could say that, yes, we have standards, but nobody's adopting those standards.

So we basically live without standards.

And that's one of the usual problems.

Now, I would love to give, let's say, a vote here to these people who never reach standards and try to build things and so on.

I'm one of them as well.

And I think everyone is, everyone, like we all do it with certain things, not with all of the things, right?

But the thing is that if you are under pressure to deliver, deliver, deliver, you could not be reading MSN.

All the standards that are out there and so on, sometimes it's faster and easier for you to deliver something that is, meh, it works, right?

And you're not going to be fired because you deliver.

Then to say, you know what, let me properly read this and let's build this in eight weeks instead of two.

But the cool thing is that next time we have to build something like that.

Actually, next time we have to build a feature on the API, we don't have to change the API.

Like the whole API will adapt itself, right?

Like the web is doing with HTML, for instance.

You don't have to encode each website in the world, like everybody got a language, which is HTML, and then you can create the content.

And then you have link tags and so on, script tags, and all this kind of references to other webs, the A tag, the anchor tag, and all this stuff, which are hyperlinks.

So there's a system there, right?

The thing is that for some reason, at some point, we decided to say that XML or HTML is not good enough.

Let's just jump to JSON because it's more readable.

I can relate to this, like I failed myself.

I prefer to read JSON than to read XML.

But it's true that it's not comparable, so we're losing features when we jump from XML to JSON.

I mean, I know a few people who would argue that nowadays JSON already has those features that XML has.

That was like a kind of patches and so on, but at the time, it's already late, let's say, because people have too invested in using plain JSON with no structure and so on.

So it's a bit of a mess, but I will not point to those who are using the standards without reading the standards.

I will instead point to these organisations who don't give enough space to these engineers to iterate and to experiment and to build better systems, right?

And instead, it's like ship, ship, ship, ship quickly because we need to go to another feature and another one more feature, one more feature.

We don't care.

It's like technical debt.

Who cares, right?

This is not going to give us money, right?

So I will point to these people instead.

Like there's company cultures, organisation cultures that don't enable for engineers to experiment and fail and develop things in a calm way while you're reading things and develop things properly.

In the automotive industry or in the aerospace industry.

I'm pretty sure it happens to some degree, but it doesn't happen as much as with software, right?

Why?

Because she cannot just ship a half-baked plane into the air with people, right?

Because if it fails, it will kill people, right?

So that's why it takes so long time to build something that is, okay, this is now properly tested.

It's not going to kill anyone.

And if at some point there's an accident because of a failure of an aeroplane or something, that will become the rare news of a plane accident.

That's really rare.

But blocks, software bags, we see them daily.

Because who cares?

Who's going to die for this?

I mean, yeah, one could argue that there are certain systems where people could die of software bags.

But in general, who cares?

Like, well, what's going to happen?

Like, someone's not going to be satisfied.

I don't care.

Let's just keep rolling.

That's why we say that if we're testing software, we're never 100% sure that there are no bugs.

There are always bugs, and software we just haven't found them yet because we just found that the right deterministic situation is everywhere.

That's the situation.

Hardware as well.

It happens as well.

So the thing is that if you are serious enough about it, if you have that need, like in the aerospace industry, you don't want to be in the news constantly because you killed a lot of people, you want to make sure that you reduce this probability to the very minimum you can, right?

And you do a lot of tests.

And so before you even launch something, right, before you even launch a beta version, right?

Yeah.

That's something they do at all.

So that's my point.

So I will not point to these people who don't understand the standards and so on, but instead point to our shitty organisation, organisation cultures, and that don't provide psychological safety to engineers to experiment and to fail.

That is my take.

And learn from those failures.

Yeah, exactly.

And this is a very nice segue to the next topic at hand, which is the non-technical barriers, but also the mindset shift that is required for proper governance and proper placement of even driven architecture within organisations.

Because from my perspective, it's extremely easy to jump into doing point to point.

That's amazingly easy with open API spec, with just all the libraries that enable you to put in just a REST API in seconds, with LLMs that just give you a definition of a REST endpoint in matters of seconds, and with a spec that you can send to somebody and they will use it.

I mean, it's extremely easy.

But to properly govern asynchronous communication, I think that's something completely different in that sense.

That's really happening by the way.

So you can really do that.

And with LLMs as well, like you can generate async API and you got pretty much, I will not say the same coverage as with open API, but this is not yet as mature as open API.

I like to remember that open API has been around for probably around 10 more years, or a little bit less probably.

Yes, while you can generate, that doesn't really change anything in terms of governance or the non-technical obstacles.

That's my point.

That's my point.

So you can generate even mocks or stops for like people can use postman, for instance, for open API, but people can use also microx to generate mocks for, you know, for, I was going to say a Kafka topic, but I have to learn myself to stop saying Kafka for everything that it's even doing architecture because it seems like it's the same.

So let's say for an A in QP topic or an A in QPQ, depending on your configuration, or an in QT topic or whatever, right?

So you can mock this already with microx as well and with A in QPQ contracts.

And you can have people who are, let's say not very technical, like product managers who understand a little bit about the topic, but not so much.

And they can already create some mocks, some fake data that will be published to a broker and things like that, right?

So it enables, let's say, non-technical people to go one step, let's say one step ahead, one step beyond without having to wait for the engineering teams to apply these things.

And you have similar technologies like Spectral that it's used to create, to link open APIs, to link this into API as well, right?

So you can use both, right?

All right, but going to the mindset shift.

Yeah.

And that's actually a very nice, also a point where we could pop this lovely QR in.

Fran is actually writing a lovely book about, what is that about, more human challenges of adoption of?

No, no, no, actually, lately I'm talking about a lot about these things, the human challenges of adopting engineering architecture, because that is the most overseen aspect of it that I found out, right?

So I know, like I can write a book about the technology needed to build an event-driven architecture and apply some governance to it and so on.

That's fine.

That's what I've been doing for the last 10 years or so.

The problem usually relies on a more human side of things, right?

So like, I'll give you an example.

So for context, in the last four or five months, I've been interviewing more than 20 people from different companies at different stages, but they all were doing event-driven architecture for the sake of the book, right?

I want to understand how people are doing, what are their challenges and so on.

So I wanted to make sure that it's not, this book is not just based on my experience or in my opinion, but also on facts, let's say, right?

And I'm glad I did because I was not going to even mention anything about the human side of things, right?

And what I found out is that every single company out there, their major challenge is about communicating, you know, like convincing their faults.

I'll put you an example.

If you're an engineer, if you're an architect that you want to introduce event-driven architecture or certain practises related to event-driven architecture, and you are in a well-established company, old company and so on, the rest of the teams, the rest of the engineers are super comfortable doing what they used to do, right?

They don't want to change, right?

So how do you convince them to adopt this new mindset?

Likely if you are a, if you're a leader in the company, like let's say head of engineering, CTO, whatever, how do you convince the rest of the teams, the rest of the engineers that EDA is what they should be doing and there should be a mindset shift in this case.

That's why it's called shift, right?

So why, how do you do it and why?

Because what I found out is that people were sure that EDA is what they needed and what they should be doing, but they struggled to convince their faults, their peers on the why.

Like why is it what we need?

Like we've been working with without it for years.

Why is it needed now?

And what I found out is that most companies don't even know where to start.

I only found one, by the way, one company that I think in my opinion, either they were lying to me or they're doing it pretty well.

So it was like a combined effort.

Like it was a bottom up and top down approach.

It was a combination of both.

That was alignment from, let's say architects, but also senior engineers, staff engineers, all the stuff, stuff plus in here with the leadership.

So everything was coming from, let's say from the bottom of the organisation, not right and sideways as well as much as possible.

But when someone was not buying the idea, then you have leadership saying, no, this is what you have to do.

I'm not asking for your opinion.

Like we want to convince you, right?

We give you the option to be convinced by faults and so on, right?

And everyone is pretty much in, but sometimes you have the black ship around, right?

That said, I don't care about that.

I'm disobeying whatever they tell me.

I don't buy it.

Well, in this case, it's useful to have someone from above, right?

And say, no, no, you have to do it.

Like there's no chance I'd say that this or you leave basically.

I mean, they should never be using that card if possible, but it's useful to have it, right?

I'll put a opposite example of not adoption.

I've seen many companies adopting new practises in terms of interoperability.

And I've seen some really bad examples of those adoptions, one of which was to create a whole integration team from scratch from former database developers and database administrators.

And if we put people that don't have the right mindset into these kinds of roles where they need to do interoperability, I mean, some really wonky stuff happens.

The wonky stuff that happened there was that they, with their database mindset, they persisted everything.

Imagine just purely persisted communication, like everything has to be written down, persisted in the database, then redistributed by usually point to point.

It was magical.

And one of the reasons I observed why they did that is because that company, in terms of how they communicated between teams or how they communicated between departments, between each other, was mostly on meetings and with robust documents.

Like they just made humongous paper trails.

And from my observation over the years in application integration is that if we look at the way that a company communicates internally, that translates directly to how systems communicate in that company.

So if we have lots of meetings, we're going to have...

Yeah, Commonwealth is low, pretty much, yeah.

If we have meetings there's going to be a lot of request reply.

Yeah.

If those people are accustomed to using...

And synchronous.

Yes, definitely synchronous, yes.

If that company is accustomed to using chats and they're accustomed to not rely on instant reply, well, we'll probably have some even driven in the systems, a decent amount.

And then if a company is relying on documents, that's going to be batch, batch, batch and file-based transfer, file-based transfer and file-based transfer all the way.

I mean, it's fine if it's proper ETL, ELT or batch, but if file-based transfer, I mean, come on, are we like in the 70s?

That's still useful sometimes.

It is.

I mean, think about it.

Like if your system is not...

I mean, if it's not relevant for your system or for your company, to have this information right straight away, like in real time, as much as real time, you want to define it.

File transfer, like a batch overnight, it's completely fine.

Like if it works, if it's not, let's say...

If it's not a problem, if it's something that can be done secondarily, it's not critical for your system and so on.

That's another technology.

Like I said, it's a technology.

Use it whenever it makes sense.

Exactly.

And I agree on that.

Whenever it makes sense, but then...

Exactly.

Don't use it for everything.

If you have 90% of your communication being robust operational communication because batch is great for analytics, batch is great for long-running processes, it's fine.

But if you're doing your operational communication with file transfers, there's something definitely very wrong in the way people do not communicate with each other.

Because if I'm looking, if most operational work is done over sending a document...

Honestly, I think, again, like every time I dig down into this topic, I find out that it has nothing to do with technology.

So every time I found that, and I scratched a little bit of surface and asked, why do you keep doing these file-based transfers, these batches overnight and so on?

Every time I kept scratching, I instantly found that...

Instantly, sometimes even in the same meeting, like one question away or two questions away, I was just not even asking directly, just asking around.

And instantly what popped up is it's a psychological safety in the organisations.

So picture this.

If you are an engineer that's been in a bank for 20 years working there, you know the system inside there, right?

Now someone comes to you and say, we now have this Kafka broker, right?

And we are doing...

We're now doing everything over Kafka.

But you still have to deliver stuff, right?

So what you will probably do is either say, no, I'm not going to do this because I don't need it.

If you have the psychological safety to do that, and meaning that you know that you're not going to be fired for disobeying, or you say yes, but you don't do it, right?

Which is even worse, right?

That's even worse because everything...

What happens in this case is that everything seems to be working.

Everybody is buying the argument.

Let's use Kafka.

Let's react on real time or, yeah, as it happens, to all the events and everything.

We process them and so on.

And we do the calculations in the very moment as we get the event, right?

Instead of just relying on overnight batches, right?

It seems that everybody is buying your argument.

But then you find out that adoption is like, this is not happening as fast as it should.

What's happening here?

They keep putting excuses here and there, like we have some deadline that we have to match, whatever, which might be true as well.

And then it's almost impossible to migrate to this new kind of system, right?

Let's say in an acceptable time because these people are boycotting you, right?

Even if you are their boss, right?

Because for different reasons, it can be because their manager is not aligned with the leadership making this change.

So their manager is still like putting them pressure, like you need to deliver this, this, this, this, this, more feature, more things, more blah, blah, blah, whatever.

So we don't have time to change our mindset here or to study or to start experimenting because it's a new technology.

You have to experiment because you don't know how it works.

So you've got to experiment, right?

So the manager is not letting them experiment.

So they never have time to experiment.

So since they don't have time to experiment, someone, some colleagues, some peer come to them, maybe an architect, usually an architect comes to them and say, hey, why are you not already publishing this information to Kafka or consuming from Kafka or whatever, or from, I mean, I mean, I mean, you're the brother, right?

Why aren't you doing this already?

Like it's been two months or whatever.

Then you have this problem that they need to keep shipping because the manager is putting them deadlines.

Now, the other thing that I've seen is this is if the whole technology changes, I may become redundant in this company.

I may lose what makes me special and what makes this company not fire me, right?

And so I will lose this job and I don't want to lose this job because as opposed to us who are passionate about software, many people are working in companies just in exchange of a salary just because of debt, which is perfectly fine.

You don't have to have a passion for software or for your job.

That's completely fine.

And it's totally acceptable, right?

The thing is that if these people fear for their job and they know they've been doing this for 20 years, so they know that if they go out, they're going to struggle to find a new job because that world is not there anymore, right?

It's only in a few companies here and there.

Very true.

And they're not hiring for these roles anymore.

So that is creating a lot of stress and their instant reaction is saying...

Resist, exactly.

Resist here.

I'm going to boycott this initiative because that doesn't make sense.

Sometimes, I will even argue, most of the times, if not all of the time, they don't do it on purpose.

No.

It's just unconsciously.

And it happens to all of us in every aspect of our lives.

So what I'm researching a lot for the book, for writing the book, is precisely on the organisational psychology.

I mentioned the safety.

I mentioned also the resistance and so on.

Alexander is in chat, he's mentioning the architectural comfort zone.

Totally agree with that.

It's the comfort zone.

And nobody wants to leave the comfort zone because the comfort zone is comfortable.

That's why it's called comfort zone.

Nobody wants to leave that.

It takes a lot of effort to leave your comfort zone.

It's very annoying to leave the comfort zone.

It takes a lot of courage and a lot of energy to get used to pushing that comfort zone further and further.

But it's a fallacy in its own if you don't do that.

Because those people will, sooner or later, will end up without the job and they will realise how...

Maybe these people are already 55 years old and they're aiming for less retirement without any complications.

So that's also valid.

The software industry is already becoming so old but it's already common to see people over 50 years old in teams.

So we're getting there.

Just last week I spoke to Mark Riches on a live stream with Utrecht Mulesoft Meetup.

And Mark has...

Let me not get that wrong.

42 years of experience in IT, 31 years of experience as an architect.

I mean, he's a dinosaur in the field.

An absolutely amazing guy and an absolutely amazing architect and he's very comfortable with moving his comfort zone and stepping out of his comfort zone which is an amazing thing to watch.

But he's one of the rare people there that actually is still capable to do this with his years of experience.

That's amazing but that's such a rare thing to observe.

That's passion.

That's passion.

That's only possible because of passion.

And there is...

If we look at our organisations, I mean, those people are there to make a buck.

They want to make a living and move on with their lives.

They don't have to have that passion.

It's fantastic if they do.

That's awesome.

But it requires really strong leadership and actual leadership that leads to spark the minimum of passion for those people to be able to step out of those comfort zones without fear with that psychological safety somewhere there.

And that's difficult.

That's extremely difficult.

It is because we all have a boss, right?

So that's the thing.

We all have a boss.

Even your boss has a boss, right?

Nobody wants to be the guy that is like, why are you so weak with your team?

Like why don't you tell them what they have to do and if not, fire them, right?

There's still this mentality, especially in these old industries like banking.

It's the mentality, the very specific mentality called the Peter Principle.

You heard probably about that.

So for those who don't know Peter Principle, it's a concept described in 1969 by Dr. Lawrence J.

Peter.

It basically means that, especially in larger environments, the smaller the company, the less it happens.

But in large corporate environments, people tend to be promoted to higher positions based on their time with the company, not based on the competence for that next position.

So they're great at their role.

They're like, let's say, you're a great junior developer.

Okay, you get a promotion to a mid developer role, right?

You're a great mid.

You get promoted to senior.

And then all of a sudden, you get promoted to a team lead, right?

And then you become incompetent because being a team lead is something completely different in terms of skill sets than being a senior developer.

Because being a team lead requires a different set of skills in terms of soft skills.

Being a senior developer, you just need to communicate clearly about the code you're writing and the technology, maybe a little bit of a coaching of juniors, etcétera, your colleagues in the team.

But as a team lead, that's something different.

So if you never have any interest in psychology or any interest in building your soft skills as a developer, and you get promoted on the basis of a Peter principle, then all of a sudden, you become completely incompetent in your job.

And that's horrendous.

And I've seen managers and directors being promoted that way.

Where they're completely incompetent to lead the whole departments and they destroy the company from within.

And then you have a large turn of employees and it all becomes very costly and difficult for everybody.

I must say, I face that myself.

In my last job at Cosmo, I was a director of engineering.

I don't know how to be a director of engineering.

I still, I mean, I more or less know now after four years being in that position.

But when I landed there, I was like, I mean, can you imagine the imposter syndrome on me?

Let's not get started on my imposter syndrome.

Can you imagine that like, yeah, I created this in KPI, cool, whatever.

But when I quit my job to work 100% of my time, full-time, on Async API, I was just recently promoted as to manager position at New Relic.

But I think I was in the manager position.

I was just one month and then I quit.

So I didn't quit because of the company.

I quit because I had the opportunity to dedicate full-time to Async API and I took this opportunity and not looking back, right?

So it was a different reason.

So I jumped straight from lead engineer, let's say that I was usually playing that role in different companies.

Sometimes architect but of smaller companies.

So it's effectively it's like lead engineer.

I was instantly promoted to director of engineering, managing other managers managing people, managing the project, the budget, the strategy, you know, all these kind of things.

Alexander says I figured that we make it.

That's what I did usually is I kept going.

I kept going because also I was like, there's another point by Kubele saying that is it really being an imposter?

Well, if you hide it, and you don't try, you're imposter.

In my case, I was trying hard.

I was trying to learn as much as possible, learning from peers within books, taking courses and so on.

I was trying hard.

It was just not made for me.

It's not what I should be.

It's not what I like.

It's not what I enjoy.

And it's not what I'm good at, at managing.

I can be decently good.

At least I'm not.

I'm really good at the human level in the sense of like something that I'm proud of is that I acted as a as an umbrella for my team.

kind of like a two way, two ways umbrella.

So I was filtering all the shit from the organisation so they don't have to worry about things happening at the higher level.

But letting them shine to the rest of the organisation and promoting their work and their achievements and so on.

So I'm happy with that work that I usually did.

And even when I quit and when they all were fired one month after I quit, the whole team, right, at Postman was led off.

Even after that, I was on holiday time and I was trying to find them a job and so on and talking to people so they could find a job.

So I'm happy.

I'm proud of myself at the human level.

But I don't know how to do that.

I don't know how to properly do that and I don't and even more important I don't enjoy it.

So yeah.

I mean, I must compliment you because this kind of behaviour absolute leadership.

Well, and I must say as well, I appreciate that but I must also mention something that I don't want to miss.

I want to make sure that everybody understands this point.

So and this took me a few sessions of therapy.

I'm not joking about that.

It's true.

It took me a few sessions of therapy.

So it was really painful for me to see my team being led off this way.

it's really like it takes true leadership as you said and as many people say that this is what you should be doing and so on.

But if you ever if you are ever in this position my piece of advice is don't do it.

Don't do it to that extreme.

So I've spent more than a year at Postman being burned out just to protect my team because I knew or I felt it that if I quit they all will be fired.

Because our hire basically was a marketing hire.

It was not a technical hire or product hire it was a marketing hire so if they don't have the founder of Facing KPI why keep investing it in this ship right?

Or they don't care.

And I felt that because of their comments and so on.

I don't agree.

I would have left the whole team there because also Lucas was still the director of the initiative so the director of Facing KPI was still there.

So it could have continued even as a marketing hire or as a marketing investment.

Now the thing is that my biggest mistake there was allowing myself to stay there to protect the rest of my team.

Don't ever do that because you can get to a point where recovering from the burnout is not recovering from the burnout anymore and it's recovering from the depression.

So because you are trying to you are trying to protect people that first of all they never asked you to protect them.

That's the first thing.

You're doing it just because you want to and you feel that you should be good.

That's like the saviour role like you want to save everyone from the pain and so on.

And secondly, they are very good professionals and adults and so on.

So when they were laid off nobody was like or almost none of them was like hey, let's rush out to find another job.

Most of them were like who cares?

Cool.

I've got holidays now and they were fired in June by the way.

So in the beginning of summer like it's been a year now.

So most of them thought like cool, let's just have holidays and proper holidays and so on and now slowly find another job at the end of the summer.

That was like I've been worried.

I've been worried for all these people when and yeah, they are sad that they've been laid off but they're not worried for their financial situation or anything like that.

So don't overload yourself with things that are not your problem.

Right.

If your team loses a job it's not your problem.

I know it's hard to say but it's not your problem.

Yeah.

It's their problem.

So it's something they have to solve, not you.

You can try to make it harder to happen but not at the expense of your own health.

That's what I would say.

Never at the expense of your own health.

And you're touching a very, very important topic which I didn't really expect to land in this stream which is mental health.

We discussed that offline that the industry is just a perfect hiding spot for a lot of people with a lot of different disabilities as in ADHD or being on the spectrum of autism.

A lot of the issues we're having we are having in our works especially also burnout and like the comment from you to Bright Hair will burn out middle name, right?

Is that common?

Yes, that's very common in the industry.

But it's common also not because the industry is burning us out or the bad leadership or bad management more likely is burning us out.

It's because we also suffer from ailments that we are not even aware because our industry and our jobs are great at hiding those.

So, for example, there are actual studies that certain industries like IT, events, et etcétera are absolutely great at hiding ADHD.

People with ADHD can hide there indefinitely.

But that also means that they will suffer because they don't even know that their ADHD is causing them a lot of problems including that burnout.

So, as we're talking about mental health and as a person that I've been diagnosed this year with ADHD, right?

Go seek professional health help and dig into the topic because if you're having depressive thoughts if you're having a burnout that might be just the symptom.

That might be just the symptom of the fact that you have ADHD and it's wrecking up your life because you left it unmanaged for too long and you're overburdened with certain things and it starts kicking you in the butt.

If you're overstimulated constantly if you're constantly feeling overburdened if you're constantly feeling tired there might be something more to that.

It's not only your imposter syndrome kicking you down it's not some sort of a depressive thought or something.

It actually might be something that was hidden because you work in IT because the amount of changes you need to go through oh man ADHD people love changes.

If the environment changes around them in the fast-paced yes I'm really great at that right because I have ADHD we love those changes but then you don't realise that you actually have that.

You don't realise that your brain works a little bit different you kind of think that oh everybody has that everybody everybody's brain works the same way.

no it doesn't that's not normative that's neuroatypical so for those finding themselves in what Fran just said about burnout about depression about having that kind of a a little bit of a saviour syndrome because what you described in protecting your team was kind of that saviour syndrome there.

Take a look at that

dig into the topic

if you're feeling

burnt out

if you're feeling

depressive

and you feel like

it's because of your

work

it might not be

have nothing to do

with your work

your work might be

contributing to the

state you are in

but you might be

just neuroatypical

and that's

that's also perfectly

fine but

go to a specialist

yep exactly

I agree with that

and that

links back to

what I was saying

that

this psychological

safety

and organisations

like

it's not just

for experimenting

it's not just

for you know

for adopting

any technology

and so on

it's also for

feeling this burnout

which by the way

I would like to clarify

burnout is not

a clinical term

right

this is a

this is a

beautiful name

we invented

to describe

depression

so that is

depression

right so when you

when you feel

burnout depending

on the stage of it

you might be in the

beginning of a depression

you might be like

straight into a

depression

so it's

let's call it

for what it is

it's called to call

it burnout because

most people are

searching for this

work

but

let's call it also

for what it is

the clinical term

is depression right

so

search for help

that's what I would say

and

and yeah and

if you are a manager

if you are a team lead

or something

or you're managing

people

I'm not going to say

I'm not going to say

that you should be

acting as a

as a

as a psychologist

because that's

probably not your

not your problem again

but at least give them

space

for expressing

expressing their

thoughts openly

and if they need help

and the company

supports it

like for instance

paying for the treatment

paying for

the therapy

sessions

paying for coaching

their ADHD

coaching

sessions

paying for holidays

like for instance

I remember

a friend of mine

like he was

he was in my team

he was

I immediately detected

him to be like

like super

like

about to collapse

you know

and he was not taking

holidays

because he

in his own words

I have to

finish this

I have to

and I said no

no you don't have to

it's good if you have

if you do it

it's good if it happens

but you

you don't have to

you don't have to

finish this

we're not

we're an open source project

it's okay

if you leave this

for the community to

complete it

to contribute and so on

and if it doesn't happen

this summer

and it has to happen

next summer

that's completely fine

we're not a product

company

we're not trying to sell

anything

we're building an

open source project

so

if something is not

developed as fast

as you like

then maybe we

should focus in

inviting more people

to join our community

and contribute more

not you doubling

down

the hours

and the effort

you put in

right

so

and I sent him

like four weeks

straight in

into holidays

like

finish whatever you

have at hand today

tomorrow you're

ready

and I don't want to see you

connecting for weeks

but he came back

recovered

and with the mind

clear like

shit

I was like

so deep into

the

into this

that I was

even like

believing that this

this was all my

responsibility

down the rabbit hole

you go

down the rabbit hole

exactly

and so

this is something

that I also ask

managers whenever

whenever they

detect these kind of

things

protect your team

don't protect the company

right

I mean

if you protect your team

you're going to protect

the company anyways

so

yeah

but don't look

at

look down

look to your team

protect them

right

because in the end

the company is going to

fire you

someday

right

you're just an asset

that is easily

removable

whatever company you work

for

they're going to

either you're

going to quit

or they're going to

remove you

so

protect your team

because they're probably

their colleagues

as well

and also for human

for human

for humanitarian reasons

don't let people

suffer for

for the

for the sake of

just a few

movie layers

right

I don't care about

that but I'm a little

bit punk here

I will say

but you know

what from my own

experience when I

learned that I have

ADHD and I started

sharing and talking

about that with

people

and meeting

with my previous

employer

and that was very

interesting that

all of the sudden

I had things

on slack

from people

I didn't even know

at the time

in the company

they were like

hey

I heard you have

ADHD

I also have ADHD

but I haven't

come out of the

closet

nobody knows

but I want you

to know because

you have

ADHD so you'll

understand

and there was so many

people that didn't

feel

psychologically

safe

in the company

to be

themselves

and to be

open about

themselves

so instead of being

open about

themselves they

we just basically

created an internal

community

of people with

ADHD

and that worked

to an extent because

we started

doing body doubling

sessions etc

to just help us

work through

certain blocks

I didn't feel

along as well

and then you feel

that you belong

to somewhere

right

but it's

it's

it's very difficult

the psychological

safety

topic is a very

broad topic

and there are so

many reasons why

somebody might

not

feel safe

psychologically

in a company

and then

act out

based on that

lack of safety

and create

even more troubles

in

the core topic

that we were

talking about

for example

so adoption of

event driven

yeah

yeah

so

let me let me

get back

because I was

I was reading the

comments

yeah

and

we have some

questions

we have some

really good

technical questions

and I think we

can we can

jump to

another point

of a discussion

meaning the evolution

of Async API

which

some of those

questions would

be very fitting

so let me

quickly scroll that

up because

I found one

somewhere somewhere

somewhere at

the beginning

of

yeah

Alexander I have

first question

yes there we go

yes

yes

cloud event

specification

if it's

you want to

reply

go ahead

I mean

it's about

included as

a recommendation

to Async API

I have nothing to do

with Async API

at this point

I will say

it's

mature enough

yes

not sure how

widely adopted

it is right now

but I think

I see it more and

more

which is good

so everything that

whatever

it is

sticking to standard

is

it's always good

so

so I will celebrate that

now I must clarify

some things

some people think it's

either

cloud events or

Async API

and they are complimentary

they

we actually tackle

different problems

right so

I wrote a

blog post about it

and

they think it's

a blog

because I found out

at some point

people were like

even like

throwing fire at us

right like

hey come on

say something

bad about cloud events

somehow think about it

and it's like

no I'm not gonna say

something bad

because I always

recommended myself

I was

when I was

consulting with Adidas

I was

I was helping them

to adapt

Async API

they were using Kafka

as well

and they were

already

using cloud events

and I saw it

in action

and I think

it's pretty cool

so

let me clarify

so cloud events

it's defining

what's it

called

the envelope

the envelope

of the data

right

pretty much

it's not exactly that

but it's pretty

it's pretty much

the envelope of the data

so I think about it

like

enveloped in the

in the post

in the post

system

in the postal system

you don't send

your

your letter

straight away

when you

you put it inside

a letter

right

an envelope

sorry

and then

you send the

you send the envelope

with the letter inside

right

so that's pretty much it

it's like

it's a common

it's a common

envelope

it's a format

so that

all your messages

across your system

they all follow

the same

structure

when it comes

to

metadata

when it comes to

specific data

then

each one is different

right

and

not even

cloud event

patches on that point

cloud events

has a field that

it's called data

and this is free form

you can put there

whatever you want

now

the funny thing

about this

is that

async API

helps you

define

helps you

helps you define

you know

the communication

not the communication

the messages

that your

your application

that

think about microservices

for instance

your service

is sending

and or receiving

from a topic

from a broker

from so on

right

you define this communication

but when it comes to

defining the message

itself

the message piece

there is a field called

payload

right

and this one

is free form

so we don't dictate

how

the payload of a message

should look like

right

this is free form

you can put there

whatever you want

actually in the JSON

schema definition

this is

the value is true

because we always want

to pass the validation

like

we don't validate it

it's always

whatever you put there

it's valid

right

we don't want to get there

so there

in the payload

is where

payload

and all also

headers as well

is where cloud events

belong

right

the envelope

and as the envelope

of the data

so actually

I think there is a pull request

or an issue discussion

right now

in async API

if I recall correctly

something I started

at some point

I want to integrate

the two standards

in a better way

like if you're using cloud events

you should be able to somehow

natively

say it in async API

I'm using cloud events

the format of the message

is cloud events

because the cloud events

format itself

it's then going to tell you

which format your data is in

is it XML?

is it JSON?

is it following certain schema definition?

so it will be cool if they could if you can already use both together but it would be cool if it could be blended even better right right so so yeah so that is so just to just to be clear on the article because I did some quick Google searching would that be somewhere around May 2019?

but the thing

I have to update

this article

at some point

is not exactly

how it's done

anymore

yeah

so

but you see

like six years now

and I was already

recommending this

yeah

so that's the

original article

to be updated

I see the

different sheaters

in the description

is there

as you

as you just said it

maybe there would be

some

discrepancies over the past

six years

yeah

because things have changed

but

that's pretty much it

at this point

I was exploring

and telling people

that different ways

you could

use both

different ways to use both

now

there are

let's say

best practises

for using both

that are not describing

this article

because now in version

three of the spec

things have changed

a little bit

so now it's easier

we have trades

I think we had trades

at that point

but there are other ways

to do it

honestly

from the top of my mind

I don't recall how

people are doing it

right now

but there are

let's say

best practises

so

it's not like that

like I described

in this article

yeah, but

you know

things change

article has six years

that's only obvious

that

this will

no longer be

fully up to date

so

yeah

it will require

a little bit of a

fixed nup

in that sense

all right

let's see

there were some

I think

oh, quite long questions

from

Maxim

really a packed one

best practises

for designing

data models

for messages

hmm

that's a

canonical data model

that's packed

my personal take is

I'm not a fan

of

canonical data

models

never

will be

I seen that happen

the larger

the org

the worse

it gets

in canonical data

models

or if you do it

you do it as an afterthought

so

after you've been

after you've been

having let's say

probably hundreds

or thousands of

message

types

and you notice a pattern

maybe you standardise that

because you make it a pattern

because it's already a pattern

anyways

yeah

so cool

in that case

cool but if you do it up front

you're probably going to be

restricting yourself

and

unnecessarily

well

that's

that's where I am a fan

of domain driven

design and bounded

contexts

with an

interoperability

topics

exactly

because then we can define

each object

several times

for each bounded

context

or each domain

separately

so a definition of

a customer

in terms of a

customer domain

will be a different

customer

defined in the order

domain

different attributes

even that's still

the same

core object

core

data

it's still

it's still a customer

yeah but it's

a different representation

of the

of the data

yeah different

context of usage

which

I will link it to the

previous question

about cloud

events

it's needed

so I'm seeing

many people

define their canonical

data models

using cloud

events

as well

so

because cloud

events is

extensible

so you can add

your fields

your own fields

whatever you want

so

you just have to respect

certain fields

that are mandatory

I think

maybe one or two

are mandatory

if I recall correctly

the rest are just

like optional

and you can add more

of your own

so

so some people are

opting for that

it's not exactly

a canonical data model

but it's

it gets close

yeah

and a twist

which is a lot shorter

of a question

sharing resources

data models

between

open API

spec

and async API

ooh

many people do that

yeah

I think that's

in general

that's not a bad idea

especially if you're

if you're having

a

integration platform

and especially

in API-led architecture

where you

can actually do

the domain partitioning

and

some of your

services

are

at the same time

synchronous

and asynchronous

because you have

a lot of

orchestration

and

different things

are happening

within the

composition layer

yeah

that means that

that sharing

would be

actually a very good thing

actually

I actually recommend it

because

and actually the reason

why async API

is so similar

it's still so similar

to open API

it's because we

we want to be

both of them

as interpretable

as possible

to be

as a fun fact

while we were

designing version

three of the spec

that is

it's a current version

of async API

we were even

considering

if there could be

a way

to make it

like

not the same as

open API

because we were

already convinced that

we had to change

certain things

in the spec

but to

in coordination

with open API

which we're always

in contact

in constant

attach

the two communities

right

so

to tell them

that hey

we're going in

this direction

because of this

this and that

we're putting

operations on the

root level of the spec

instead of

inside the

the channels

or

like for instance

if you're familiar

with open API

they have the

operations get put

pause and so on

inside the path

right

yeah

instead of at the root level

but there were some

already some people

in the open API

community saying

we should move

the operations

to the root level

and then link them

with dollar ref

and so on

right so

instead of

instead of having

them nested

inside the path

and so on

that's the direction

we took for async API

so operations are now

in the root level

as a

as a first

first class

citizens

people call it

right

and we were thinking

if we

if we managed to

convince the

open API

faults to do the same thing

at some point

we could even

if not converge

into a single spec

we could build really

close

really really close

right

right

but

that is

this is a

philosophical

philosophical problem

because

if you look at

the

days of saw

and soap services

the

soap had

a very different

philosophy because

soap was

primarily used

to build

business services

so they

they didn't

represent an

object

they represent a

function

while if we're

looking at

rest

rest by nature

is supposed to

represent an

object and

functions on

that specific

object

so

moving

the

operations down

to the

to that level

would

shift back to

kind of

shift back to

business services

rather than

representing

objects

and

and that

philosophically

might

rub

rub people

the wrong way

when we're

looking at

these kind of

services

this would be

against

rest principles right

that's my point

so open API

is

not

a

spec for

rest

APIs

it is

very true

but the

underlying

philosophy is

coming from

the rest

specific

yes

I will call it

like it's

for

HTTP APIs

in most

in most cases

I will say

it's a

resource-based

HTTP APIs

and some

cases

it's RPC

APIs

like you will do with GraphQL

but instead of GraphQL

you use your own

syntax

with endpoints

containing the action

and so on

which is pretty common as well

but that would be a very interesting

evolution to actually

shift back to that

my point with this here is that

we are

we've been trying

we're not trying right now

but we've been trying

the thing is that

this is a little bit like forcing

the things

to

like to match together

when they are not the same thing right

and it's not even representing the same

kind of world

so it's a different thing altogether

now

whatever can be reused like schema

definitions and so on

they're still the same

mostly the same

actually not the same

they you can use

so OpenAPI uses the

the latest

schema draft

but the most

used

OpenAPI version which is

two point

something

or the three

I think it's

still two point something

it's still swagger

the most used

it's on

JSON schema

draft four

you can use

any of these schema

versions with

some API

for that very reason

so

they were interpretable

right

so yeah

so

we actually recommend it

because it's a

it's a really good idea

because think about it

like

or picture this example

you have a REST API

or next to the API

you receive a request

and as a result

you publish a message to a broker

right

as a result

as a side effect of this request

you publish a message to the broker

containing

some information

that was in the request body

right

say for instance

you are signing up a user

or something like that

I mean that's a

that's a very common use case

in API led architecture

where you have the

channel layer

the first layer

or as

in mules what they call it

the experience layer

you basically call it

call a REST service

and then that translates into an

asynchronous call

for warding that event

the request is actually

a disguised event

and the only

reason why it's

done over a

synchronous

call

is because

we want to

give back

the information

that it was

accepted for processing

to that system

so that system can move on

and it's easier

to consume

a

HTTP

API

than to figure out

how do we connect

directly to the broker

from each

separate team

to learn that broker

and then you

move that complexity

to the integration platform

to learn

how to use the broker

and facilitate that use

so that's a very

common use case

and also a common

use case is

right now

popping up in

API management

where they

offer

protocol

mediation

to mediate

from a REST

call to

an event

or from

an event

to a REST call

like a web

call

in fact

it's a

you know

if you

are building

with a

mindset of

microservices

you might have

an API

that is

a REST API

or an HTTP

API that is

receives a

post

call

let's say

slash

sign up

whatever

sign user

app or whatever

this microservice

might have

its own database

where it

stores

the

it stores

the

you know

the user that

just

have signed up

right now

and as a result

either the microservice

or the database

triggers