1
00:00:01,860 --> 00:00:06,300
We just said that using synchronous communication was maybe not the best way of solving this because

2
00:00:06,300 --> 00:00:11,620
although it's really easy for you and I it's not really the best solution from an engineering standpoint.

3
00:00:11,670 --> 00:00:15,390
In this video we're going to take a look at a second possible solution as he guessed this is going to

4
00:00:15,390 --> 00:00:18,600
be an asynchronous communication based solution.

5
00:00:18,720 --> 00:00:24,000
Remember with asynchronous communication we frequently introduce something called an event broker and

6
00:00:24,000 --> 00:00:30,250
the goal or purpose of this event broker is to receive notifications from some different services.

7
00:00:30,420 --> 00:00:35,430
Take those notifications or those events and route them off to all the other services that we are running

8
00:00:37,210 --> 00:00:42,030
so with this approach we're going to dramatically change how our application behaves.

9
00:00:42,030 --> 00:00:46,170
We are going to introduce the idea of a query service down here.

10
00:00:46,170 --> 00:00:53,310
The goal the query service is to listen to any time that a post is created or a comment is created.

11
00:00:53,310 --> 00:00:57,900
So any time a post is created or a company is created we're going to have these services emit an event

12
00:00:58,910 --> 00:01:03,460
the query service will then listen for those events and it's going to take all the different posts and

13
00:01:03,460 --> 00:01:09,280
comes to get created and assembled them all into a very efficient data structure that can essentially

14
00:01:09,280 --> 00:01:14,440
solve our root problem right now which is to make sure that we reduce all these number of requests down

15
00:01:14,440 --> 00:01:16,740
to just one single request.

16
00:01:16,750 --> 00:01:21,400
So again the goal of this query service is to take all the different posts all the different comments

17
00:01:21,700 --> 00:01:27,400
and just serve them up to the browser in one very simple and easy request.

18
00:01:27,410 --> 00:01:30,430
Let's take a look at how this would actually work in practice.

19
00:01:30,470 --> 00:01:36,200
So here's where everything would start whenever someone makes a post request to the post service.

20
00:01:36,290 --> 00:01:41,720
We're gonna have our Post feature emit an event and it might look something like this.

21
00:01:41,720 --> 00:01:47,390
Maybe it's an event that has some type of post created and it has some data associated with it as well.

22
00:01:47,390 --> 00:01:53,240
And that data might be the actual post that was generated that would have an I.D. and a title the post

23
00:01:53,290 --> 00:01:56,210
service would throw that event off to the event.

24
00:01:56,200 --> 00:02:01,640
Buzz and then the event buzz would automatically route that event or send the event off.

25
00:02:01,840 --> 00:02:06,580
All of our different services that express some interest in it we might send that event off to our query

26
00:02:06,580 --> 00:02:12,480
service then it would be up to the query service to somehow process this event and store some data from

27
00:02:12,480 --> 00:02:12,870
it.

28
00:02:13,750 --> 00:02:17,720
I've got here the query service and the event that it needs to process.

29
00:02:18,040 --> 00:02:22,150
We might decide to create some kind of data structure like the one you see right here to store all these

30
00:02:22,150 --> 00:02:29,230
different events that are coming in so in this case we might have a collection or object keeping track

31
00:02:29,230 --> 00:02:30,680
of all of our different posts.

32
00:02:30,940 --> 00:02:36,390
We might store the ideas of every post that has been created its title and all the relevant comments.

33
00:02:36,490 --> 00:02:41,530
So anytime that we see this host created event come in we would take that idea right there.

34
00:02:42,520 --> 00:02:44,140
And enter in a brand new post.

35
00:02:44,200 --> 00:02:50,710
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

36
00:02:50,710 --> 00:02:55,810
associate with this post but probably just default this comments property right here to be an empty

37
00:02:55,810 --> 00:03:01,680
array for right now until we start to actually receive some comments then we can imagine that at some

38
00:03:01,680 --> 00:03:08,590
point in time in the future maybe someone creates a comment tied to that post does someone I'll make

39
00:03:08,590 --> 00:03:12,750
a post request for comment service and very similar to what we just went through.

40
00:03:12,820 --> 00:03:17,670
We're going to have our common service event and event that might look a little something like this.

41
00:03:17,880 --> 00:03:23,110
It might have a type of comment created and some data related or describing the comment that was just

42
00:03:23,110 --> 00:03:28,630
made that will go to our event bus and the event bus is going to take that thing and route it off to

43
00:03:28,630 --> 00:03:33,690
any service inside of our app that is interested in it now it's up to our query service once again to

44
00:03:33,690 --> 00:03:40,080
process this new different incoming event so we're back to our query service.

45
00:03:40,080 --> 00:03:42,580
We still have that same kind of data structure that we had before.

46
00:03:42,690 --> 00:03:46,600
And we've got the definition of some existing post inside there already.

47
00:03:46,800 --> 00:03:52,450
So we'll write out some code instead of our query Service to process this event it's going to take this

48
00:03:52,450 --> 00:03:54,130
comment that was just created.

49
00:03:54,340 --> 00:03:58,690
It's going to find the related post with this given post idea right here.

50
00:03:58,690 --> 00:04:01,930
In this case the post I.D. is A1 GP 5.

51
00:04:02,110 --> 00:04:03,850
There's the post right there.

52
00:04:03,940 --> 00:04:09,060
So our query service will take this comment and add it into some kind of comments array.

53
00:04:09,220 --> 00:04:19,870
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

54
00:04:19,870 --> 00:04:25,840
time someone can make a request directly to our query service and ask for all the different posts and

55
00:04:25,870 --> 00:04:31,120
all the related comments and our query service really has to do now is take this entire data structure

56
00:04:31,210 --> 00:04:37,560
and send it out and inside this thing we've got all the relevant posts all the relevant comments but

57
00:04:37,630 --> 00:04:42,910
again this is this kind of asynchronous communication style then this diagram I just want to make sure

58
00:04:42,910 --> 00:04:46,440
it's really clear rather than making a get request to our post service.

59
00:04:46,450 --> 00:04:51,010
Now to get a list of all the posts and whatnot would instead make a get request down to the query service

60
00:04:51,010 --> 00:04:52,020
instead.

61
00:04:52,060 --> 00:04:56,610
So that would require making some changes inside of our ReACT application OK.

62
00:04:56,640 --> 00:05:01,990
So at this point I want to go over some pros and cons of this approach and it turns out yeah the pros

63
00:05:01,990 --> 00:05:06,850
and cons are identical to what we discussed before this query service that we're imagining creating

64
00:05:07,030 --> 00:05:10,180
doesn't really have any direct dependencies on other services.

65
00:05:10,630 --> 00:05:15,670
Yes till you're going through I understand it does rely upon some incoming events that are being issued

66
00:05:15,730 --> 00:05:20,650
by those services but if those services go down for any reason if they stop functioning if they stop

67
00:05:20,650 --> 00:05:27,140
working the query service is still going to work as expected the query service is also going to be really

68
00:05:27,140 --> 00:05:32,300
really fast compared to that more synchronous style of communication the reason for this is that we're

69
00:05:32,300 --> 00:05:35,820
not making any requests between our different services anymore.

70
00:05:35,990 --> 00:05:39,760
If someone ever wants to get a list of all the different posts and comments associated with them as

71
00:05:39,770 --> 00:05:46,470
can be one very simple request the downsides here are identical to the downsides we've looked at previously

72
00:05:46,560 --> 00:05:48,870
we now have some data duplication.

73
00:05:48,870 --> 00:05:55,020
One thing to be clear about is that even in this asynchronous style approach if we have say a post requests

74
00:05:55,020 --> 00:06:00,690
come into the post service right here the Postal Service is still going to store a post it's still going

75
00:06:00,700 --> 00:06:05,430
to have its own idea of what a post is though still being stored here.

76
00:06:05,430 --> 00:06:10,470
But we're also storing what a post is or this some information about this post inside of our query service

77
00:06:10,470 --> 00:06:11,700
as well.

78
00:06:11,700 --> 00:06:16,330
So we now are now effectively duplicating data between these two services.

79
00:06:16,410 --> 00:06:21,000
It might sound really wasteful to duplicate this data but there are some really good reasons to persist

80
00:06:21,000 --> 00:06:23,020
data between these two services.

81
00:06:23,050 --> 00:06:29,220
These reasons are something I will discuss a little bit later on in the last issue here is well without

82
00:06:29,220 --> 00:06:31,580
a doubt way harder to understand.

83
00:06:31,590 --> 00:06:36,420
No doubt about it from an engineering standpoint this is a lot harder to implement because we need to

84
00:06:36,420 --> 00:06:41,370
be aware of all these different events that are floating around our application however when it comes

85
00:06:41,370 --> 00:06:47,910
down to the actual operational efficiency of this it's going to be incredibly fast no issues with dependencies

86
00:06:47,910 --> 00:06:48,690
on their services.

87
00:06:48,720 --> 00:06:55,660
So again if anything else goes down this service will continue to work now at this point.

88
00:06:55,730 --> 00:06:56,540
You might be thinking.

89
00:06:56,570 --> 00:06:58,060
All right Steven.

90
00:06:58,070 --> 00:06:59,240
Sure whatever.

91
00:06:59,240 --> 00:07:00,440
Maybe this is how it's done.

92
00:07:00,530 --> 00:07:02,020
You might have some really big questions.

93
00:07:02,050 --> 00:07:06,410
So I put together a quick diagram here where I think I've got some questions that you might have at

94
00:07:06,410 --> 00:07:09,370
this point in time and some possible answers to them.

95
00:07:09,410 --> 00:07:10,960
This video is going a little bit long however.

96
00:07:10,970 --> 00:07:14,570
So let's take a pause right here and we'll go over some of your concerns that you might have at this

97
00:07:14,570 --> 00:07:16,090
approach in just a moment.