Original subtitles

We just said that using synchronous communication was maybe not the best way of solving this because

although it's really easy for you and I it's not really the best solution from an engineering standpoint.

In this video we're going to take a look at a second possible solution as he guessed this is going to

be an asynchronous communication based solution.

Remember with asynchronous communication we frequently introduce something called an event broker and

the goal or purpose of this event broker is to receive notifications from some different services.

Take those notifications or those events and route them off to all the other services that we are running

so with this approach we're going to dramatically change how our application behaves.

We are going to introduce the idea of a query service down here.

The goal the query service is to listen to any time that a post is created or a comment is created.

So any time a post is created or a company is created we're going to have these services emit an event

the query service will then listen for those events and it's going to take all the different posts and

comes to get created and assembled them all into a very efficient data structure that can essentially

solve our root problem right now which is to make sure that we reduce all these number of requests down

to just one single request.

So again the goal of this query service is to take all the different posts all the different comments

and just serve them up to the browser in one very simple and easy request.

Let's take a look at how this would actually work in practice.

So here's where everything would start whenever someone makes a post request to the post service.

We're gonna have our Post feature emit an event and it might look something like this.

Maybe it's an event that has some type of post created and it has some data associated with it as well.

And that data might be the actual post that was generated that would have an I.D. and a title the post

service would throw that event off to the event.

Buzz and then the event buzz would automatically route that event or send the event off.

All of our different services that express some interest in it we might send that event off to our query

service then it would be up to the query service to somehow process this event and store some data from

it.

I've got here the query service and the event that it needs to process.

We might decide to create some kind of data structure like the one you see right here to store all these

different events that are coming in so in this case we might have a collection or object keeping track

of all of our different posts.

We might store the ideas of every post that has been created its title and all the relevant comments.

So anytime that we see this host created event come in we would take that idea right there.

And enter in a brand new post.

There'll be a one JP five as the I.D. The title is new post and then right now we don't have any comments

associate with this post but probably just default this comments property right here to be an empty

array for right now until we start to actually receive some comments then we can imagine that at some

point in time in the future maybe someone creates a comment tied to that post does someone I'll make

a post request for comment service and very similar to what we just went through.

We're going to have our common service event and event that might look a little something like this.

It might have a type of comment created and some data related or describing the comment that was just

made that will go to our event bus and the event bus is going to take that thing and route it off to

any service inside of our app that is interested in it now it's up to our query service once again to

process this new different incoming event so we're back to our query service.

We still have that same kind of data structure that we had before.

And we've got the definition of some existing post inside there already.

So we'll write out some code instead of our query Service to process this event it's going to take this

comment that was just created.

It's going to find the related post with this given post idea right here.

In this case the post I.D. is A1 GP 5.

There's the post right there.

So our query service will take this comment and add it into some kind of comments array.

I'll say the idea of this comment is to J 5 6 and the content is a comment like so then at that point

time someone can make a request directly to our query service and ask for all the different posts and

all the related comments and our query service really has to do now is take this entire data structure

and send it out and inside this thing we've got all the relevant posts all the relevant comments but

again this is this kind of asynchronous communication style then this diagram I just want to make sure

it's really clear rather than making a get request to our post service.

Now to get a list of all the posts and whatnot would instead make a get request down to the query service

instead.

So that would require making some changes inside of our ReACT application OK.

So at this point I want to go over some pros and cons of this approach and it turns out yeah the pros

and cons are identical to what we discussed before this query service that we're imagining creating

doesn't really have any direct dependencies on other services.

Yes till you're going through I understand it does rely upon some incoming events that are being issued

by those services but if those services go down for any reason if they stop functioning if they stop

working the query service is still going to work as expected the query service is also going to be really

really fast compared to that more synchronous style of communication the reason for this is that we're

not making any requests between our different services anymore.

If someone ever wants to get a list of all the different posts and comments associated with them as

can be one very simple request the downsides here are identical to the downsides we've looked at previously

we now have some data duplication.

One thing to be clear about is that even in this asynchronous style approach if we have say a post requests

come into the post service right here the Postal Service is still going to store a post it's still going

to have its own idea of what a post is though still being stored here.

But we're also storing what a post is or this some information about this post inside of our query service

as well.

So we now are now effectively duplicating data between these two services.

It might sound really wasteful to duplicate this data but there are some really good reasons to persist

data between these two services.

These reasons are something I will discuss a little bit later on in the last issue here is well without

a doubt way harder to understand.

No doubt about it from an engineering standpoint this is a lot harder to implement because we need to

be aware of all these different events that are floating around our application however when it comes

down to the actual operational efficiency of this it's going to be incredibly fast no issues with dependencies

on their services.

So again if anything else goes down this service will continue to work now at this point.

You might be thinking.

All right Steven.

Sure whatever.

Maybe this is how it's done.

You might have some really big questions.

So I put together a quick diagram here where I think I've got some questions that you might have at

this point in time and some possible answers to them.

This video is going a little bit long however.

So let's take a pause right here and we'll go over some of your concerns that you might have at this

approach in just a moment.