1
00:00:01,170 --> 00:00:06,030
I think this little test with Nat streaming server and putting together this little test project has

2
00:00:06,030 --> 00:00:07,560
had some pretty good results.

3
00:00:07,650 --> 00:00:12,390
So we've now got this space listener base publisher we got the listing of all of our different subjects.

4
00:00:12,510 --> 00:00:16,860
We've seen how to create a event that described some message We're gonna send out and how to create

5
00:00:16,860 --> 00:00:20,390
the custom look publisher and listener as well.

6
00:00:20,400 --> 00:00:22,850
So at this point we're gonna start to wrap things up and move forward.

7
00:00:22,860 --> 00:00:26,690
But I do want to do a very quick summary and really touch on two items really quick.

8
00:00:26,790 --> 00:00:32,940
So first off thinking about how to test these things we think about testing the publishers the publishers

9
00:00:32,940 --> 00:00:36,850
themselves are actually rather similar to making a plain network request.

10
00:00:36,900 --> 00:00:41,760
In other words it's rather similar to using something like axioms we're essentially using this class

11
00:00:41,760 --> 00:00:45,060
to make a requesters with some information.

12
00:00:45,060 --> 00:00:47,880
There's not really going to be a lot of business logic inside these.

13
00:00:47,880 --> 00:00:51,920
And so we're not really going to focus a whole bunch on how to test them listeners.

14
00:00:51,930 --> 00:00:55,190
On the other hand are a totally different story.

15
00:00:55,290 --> 00:00:59,400
The listeners we put together are going to receive events and the assumption here is that we're going

16
00:00:59,400 --> 00:01:04,890
to do a lot of business logic or processing on these incoming events in that regard.

17
00:01:04,890 --> 00:01:10,200
These listeners are actually similar in nature to request handlers and we're definitely going to want

18
00:01:10,200 --> 00:01:14,700
to do a lot of testing around the listeners we put together and make sure that we handle everything

19
00:01:14,700 --> 00:01:16,770
inside them correctly.

20
00:01:16,770 --> 00:01:21,060
So we will be spending a lot of time to figure out how to write some tests effectively for a listener

21
00:01:22,190 --> 00:01:23,350
game.

22
00:01:23,360 --> 00:01:29,390
One other quick item at this point I just want to highlight that we have centralized a ton of information

23
00:01:29,390 --> 00:01:35,810
into our common module the common module is now going to be the primary source for where we define 11

24
00:01:35,840 --> 00:01:39,190
different event names or remember what they are called in the world of Nats.

25
00:01:39,200 --> 00:01:45,320
They are subjects inside of here we also have the exact definition of what all of our different events

26
00:01:45,350 --> 00:01:47,150
are going to consist of.

27
00:01:47,150 --> 00:01:51,670
So the subject for each of them and the data that these events are going to contain.

28
00:01:51,830 --> 00:01:55,880
We are not going to define any events whatsoever inside of our different services.

29
00:01:55,880 --> 00:02:01,970
Instead we are going to import them from this common module and this is going to absolutely positively

30
00:02:01,970 --> 00:02:08,210
ensure that all of our services are using the same event names and the data inside of them will always

31
00:02:08,210 --> 00:02:10,980
be consistent now.

32
00:02:10,980 --> 00:02:13,780
Quick side note kind of like a higher level note here.

33
00:02:13,860 --> 00:02:18,450
When I was first putting this course together I worked on this course for a extremely long time at this

34
00:02:18,450 --> 00:02:23,580
point a very long time and the vast majority that time was actually evaluating different options on

35
00:02:23,580 --> 00:02:25,680
how to put this common module together.

36
00:02:25,830 --> 00:02:29,880
And when I was really thinking about building this course and going through all that work I thought

37
00:02:29,880 --> 00:02:33,720
this section where we were talking about building out this customer then handling stuff in the common

38
00:02:33,720 --> 00:02:39,630
module was going to be like a huge deal and it ended up being just about 14 videos or so I'm kind of

39
00:02:39,630 --> 00:02:41,950
shocked at how things actually turned out.

40
00:02:41,970 --> 00:02:47,940
Anyways back on topic here the reason that's really relevant is that I really can not understate how

41
00:02:47,940 --> 00:02:55,740
important it is to put the definition of all these events and these event names into some common location.

42
00:02:55,740 --> 00:03:01,590
It is simply not feasible to only define these events inside of your services because as I've said several

43
00:03:01,590 --> 00:03:07,770
times you are going to make typos on event names and you are going to make typos on property names as

44
00:03:07,770 --> 00:03:08,320
well.

45
00:03:08,400 --> 00:03:13,830
It is guaranteed I 100 percent guarantee it if you try to define these things directly inside of your

46
00:03:13,830 --> 00:03:14,650
services.

47
00:03:14,820 --> 00:03:21,370
And that's why putting it all inside of some common module is so so helpful I almost wish that we hadn't

48
00:03:21,370 --> 00:03:26,890
put the coming module together from the get go so we could have experienced the pain of having to guess

49
00:03:26,890 --> 00:03:32,050
these property names and have to go look them up back and forth and all that pain I think would have

50
00:03:32,050 --> 00:03:36,350
given us a lot more appreciation for defining the events inside of here.

51
00:03:36,370 --> 00:03:38,970
Now I do want to say there is a downside to this approach.

52
00:03:39,040 --> 00:03:43,930
We are writing typescript code putting these event definitions inside of a typescript module.

53
00:03:44,140 --> 00:03:48,790
So naturally this whole approach right now is only going to work if all of our different services are

54
00:03:48,790 --> 00:03:50,080
written with typescript.

55
00:03:50,530 --> 00:03:53,500
If we have some other service using Java or something like that.

56
00:03:53,590 --> 00:03:58,810
Well this shared definition of what an event is is not going to be quite so useful.

57
00:03:59,230 --> 00:04:04,960
If you do expect to have services with other languages being used inside them and you don't expect to

58
00:04:04,960 --> 00:04:10,830
be able to use some kind of common module all written typescript there are a couple of options.

59
00:04:10,900 --> 00:04:16,330
So if you want to have a common definition of all the events the information inside them and shirt inside

60
00:04:16,330 --> 00:04:22,540
of some kind of Polygon architecture you can take a look at some other alternatives such as gate Jason

61
00:04:22,540 --> 00:04:28,690
schema Jason schema allows you to define Jason structures the different properties you'll have the different

62
00:04:28,870 --> 00:04:31,610
values they'll have and some validation around those properties.

63
00:04:31,780 --> 00:04:34,770
And this can be done in a cross language way.

64
00:04:34,810 --> 00:04:40,120
In other words lot of languages have support for Jason schema so you can write your Jason schema inside

65
00:04:40,120 --> 00:04:41,840
of some kind of a common repository.

66
00:04:41,920 --> 00:04:46,230
So maybe I get hub repo or some like that so you can easily work with it between different languages

67
00:04:47,050 --> 00:04:51,220
and then each year different services can pull in those Jason schema files and use them to validate

68
00:04:51,250 --> 00:04:57,890
events that they're trying to publish another alternative is print above wrote above is a way of serialized

69
00:04:57,890 --> 00:05:04,460
information not unlike Jason but it compacts information to much more compact formats heard above can

70
00:05:04,460 --> 00:05:09,390
be used to define the structures also has cross language support.

71
00:05:09,410 --> 00:05:11,750
Finally there's also something else called Apache arrow.

72
00:05:11,750 --> 00:05:16,640
This is really themed around Java in particular but there is support for a variety of different languages

73
00:05:16,670 --> 00:05:17,180
as well.

74
00:05:17,240 --> 00:05:21,140
It's just not as strong as the Java focus side.

75
00:05:21,140 --> 00:05:27,200
So again if you do expect to have some multi language services inside of your application rather than

76
00:05:27,200 --> 00:05:31,700
doing a common module with TypeScript and putting the event definitions in there you might take a look

77
00:05:31,700 --> 00:05:38,990
at these approaches just you know I did originally kind of try to design this application using Chase

78
00:05:38,990 --> 00:05:39,780
on schema.

79
00:05:39,780 --> 00:05:42,120
I also did a version of it with proto buff as well.

80
00:05:42,150 --> 00:05:46,680
Neither of them were anywhere near as usable as the typescript implementation.

81
00:05:46,670 --> 00:05:47,880
We ended up with.

82
00:05:47,880 --> 00:05:52,950
So I showed you the type curve solution because I really did believe it was a very good way of handling

83
00:05:52,950 --> 00:05:57,720
this and avoided a lot of headaches so we would have ran into if we tried to make use of Jason schema

84
00:05:57,750 --> 00:05:58,650
or protocol.

85
00:05:58,830 --> 00:06:00,780
So just throwing that out there.

86
00:06:00,940 --> 00:06:01,240
All right.

87
00:06:01,270 --> 00:06:03,760
So enough this pause right here.

88
00:06:03,760 --> 00:06:07,930
Last thing we're going to do we're gonna take a lot of logic out of this little test project.

89
00:06:07,930 --> 00:06:09,900
We're going to relocate it to our common module.

90
00:06:09,940 --> 00:06:15,670
We're then going to rebuild it republish it and then update the common module inside our ticket service.

91
00:06:15,670 --> 00:06:17,650
We're then going to go backwards to the tickets world.

92
00:06:17,650 --> 00:06:22,970
We're going to make sure that we start to publish events whenever a ticket is updated or created.

93
00:06:22,970 --> 00:06:24,590
So still a little bit of work to do.

94
00:06:24,610 --> 00:06:26,050
Let's get started in the next video.