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.