1 00:00:01,420 --> 00:00:01,670 All right. 2 00:00:01,690 --> 00:00:03,900 Let's go ahead and build out our two events. 3 00:00:03,910 --> 00:00:10,330 So again we care about order created and order canceled to get started inside my events directory in 4 00:00:10,330 --> 00:00:11,080 the common module. 5 00:00:11,080 --> 00:00:14,140 I'm gonna find that subjects t s file inside subjects. 6 00:00:14,150 --> 00:00:18,880 We got that you know that it's listing out all the different possible subject names or essentially event 7 00:00:18,880 --> 00:00:19,650 names. 8 00:00:19,900 --> 00:00:24,810 So we're gonna add in an event name or a subject of order created an order canceled. 9 00:00:25,150 --> 00:00:29,790 Well put inside of your order read it is order a colon created 10 00:00:32,760 --> 00:00:39,860 and order canceled is order colon canceled. 11 00:00:39,870 --> 00:00:42,030 Good start after that. 12 00:00:42,040 --> 00:00:47,850 I'm going to create two files inside this event's directory one of the order created events. 13 00:00:47,910 --> 00:00:55,140 Yes I accidentally put a s on the very end there I can make sure I just fix that we will also create 14 00:00:55,260 --> 00:00:58,030 order canceled event. 15 00:00:58,080 --> 00:01:03,520 Yes just so you know the word canceled very easy to misspell. 16 00:01:03,640 --> 00:01:09,250 So you've now written out the word canceled three times right here right here and inside of that file 17 00:01:09,250 --> 00:01:10,770 that we just created as well. 18 00:01:10,810 --> 00:01:16,780 I beg you please triple check the spelling of the word canceled in all three locations if you misspelled 19 00:01:16,810 --> 00:01:19,420 canceled anywhere it's going to cause problems down the line. 20 00:01:19,450 --> 00:01:21,410 Without a doubt. 21 00:01:21,460 --> 00:01:21,680 All right. 22 00:01:21,730 --> 00:01:23,970 So now we'll go back over to order created events. 23 00:01:23,980 --> 00:01:27,270 We're gonna start to put together this event definition at the very top. 24 00:01:27,280 --> 00:01:36,500 We will import these subject seen them from subjects will then export a new interface called order created 25 00:01:36,590 --> 00:01:45,980 event then inside of here we're going to list out the subject which is subject start order created and 26 00:01:45,980 --> 00:01:50,540 then some data that is going to describe the order that was just made and we could certainly throw all 27 00:01:50,540 --> 00:01:53,860 the data from the order inside of here but let's go back and take a look at that PDA. 28 00:01:53,870 --> 00:01:57,950 That describes the purpose of this event so that we can really understand what information we should 29 00:01:57,950 --> 00:02:00,140 include inside. 30 00:02:00,160 --> 00:02:05,330 All right so remember order created is going to go off two tickets payments and expiration. 31 00:02:05,500 --> 00:02:09,070 Each of these different services need to know some very particular information about the order that 32 00:02:09,070 --> 00:02:14,680 was just made to the ticket service for example needs to know the idea of a ticket that was just reserved 33 00:02:15,000 --> 00:02:20,200 that the ticket service can lock down that ticket and prevent any further editing the payment service 34 00:02:20,200 --> 00:02:26,590 on the other hand needs to know the user I.D. of whoever does create this order so that it can understand 35 00:02:26,620 --> 00:02:28,990 who it should expect to receive a payment from. 36 00:02:28,990 --> 00:02:32,110 It also needs to know the cost or the price of the ticket. 37 00:02:32,260 --> 00:02:38,050 And then finally the expiration service needs to know the expires at time of the order. 38 00:02:38,050 --> 00:02:46,190 So in total we really care about the ticket I.D. we care about the user I.D. and the ticket price and 39 00:02:46,190 --> 00:02:48,720 then we care about the expires at time. 40 00:02:48,770 --> 00:02:54,140 And technically this thing also cares about the order idea as well so that when that 15 minutes expires 41 00:02:54,140 --> 00:03:00,020 or passes the expiration can service can emit an event and say hey the order with I.D. so and so should 42 00:03:00,020 --> 00:03:01,890 now be marked as expired. 43 00:03:02,120 --> 00:03:06,560 The only thing that all these services don't really care about when it comes to order is the status 44 00:03:06,560 --> 00:03:12,290 of the order none those different services care about the status whatsoever and in fact even the name 45 00:03:12,320 --> 00:03:19,270 of this event implies that its status should be order Cary or that the created status. 46 00:03:19,290 --> 00:03:22,800 Now having said that even though none of our services really care about the status I'm still going to 47 00:03:22,800 --> 00:03:27,510 include it anyways with the event because who knows maybe at some point in time in the future some other 48 00:03:27,510 --> 00:03:31,740 service is going to come online and it's going to care about the default status of this order or something 49 00:03:31,740 --> 00:03:32,190 like that. 50 00:03:32,670 --> 00:03:32,880 OK. 51 00:03:32,910 --> 00:03:38,100 So anyways for data right here we're gonna say that we're going to include the I.D. as a string the 52 00:03:38,390 --> 00:03:42,090 status which is going to be wanted the order status in some options. 53 00:03:42,090 --> 00:03:49,610 So we'll have to import our order status enum at the top as a quick reminder. 54 00:03:49,610 --> 00:03:53,420 We've got that types directory inside there's the order status in them and that describes all the different 55 00:03:53,420 --> 00:03:58,340 value statuses that an order can have then the user I.D.. 56 00:03:58,340 --> 00:04:03,120 So this is the person who created the order we care about. 57 00:04:03,120 --> 00:04:10,450 Expires at and remember saved on the order or the order model it is a date. 58 00:04:10,460 --> 00:04:15,620 That is how we are storing expires at inside of our database it is a date object but we are describing 59 00:04:15,620 --> 00:04:18,780 something right here that's going to be converted into Jason. 60 00:04:18,880 --> 00:04:24,050 So rather than saying that this order created event is going to have it expires at property that is 61 00:04:24,050 --> 00:04:28,490 going to be a date object instead I'm going to say that it is a string because we're definitely going 62 00:04:28,490 --> 00:04:32,680 to want to convert that data object into Jason or into a string manually. 63 00:04:32,750 --> 00:04:35,480 So we can control how the time zone gets set. 64 00:04:35,480 --> 00:04:39,210 Long story short for right now we're going to say that expires that is going to be a string. 65 00:04:39,260 --> 00:04:45,540 And when we actually go and make use this you'll see why then finally we're going to also include information 66 00:04:45,540 --> 00:04:47,380 about the ticket on here as well. 67 00:04:47,390 --> 00:04:51,450 Going to embed it inside of an object so I'll say that this thing is going to have an idea that is a 68 00:04:51,450 --> 00:05:00,070 string and a price that is a number and that should be it for now. 69 00:05:00,070 --> 00:05:06,560 All right let's now go over and take care of order canceled so here's Order cancelled events at the 70 00:05:06,560 --> 00:05:07,070 very top. 71 00:05:08,750 --> 00:05:20,190 I will get my status first is not status but subjects from subjects file will then export an interface 72 00:05:20,250 --> 00:05:27,030 of order canceled event will say that this thing is gonna have a subject of subject stored order canceled 73 00:05:27,530 --> 00:05:29,800 and then in this case what data do we care about. 74 00:05:30,330 --> 00:05:34,290 Well let's go take a look once again at that diagram and see what actually cares about order canceled 75 00:05:36,270 --> 00:05:37,520 so order canceled. 76 00:05:37,540 --> 00:05:41,860 We want that to go over to the ticket service and that means that the ticket service is going to need 77 00:05:41,860 --> 00:05:44,750 to be told exactly what ticket idea. 78 00:05:44,770 --> 00:05:49,410 We just need or we need to actually on reserve. 79 00:05:49,430 --> 00:05:54,200 In addition this thing is going to go to the payment service and tell it that it should stop to or should 80 00:05:54,200 --> 00:06:00,010 not expect to receive any payment or anything like that the payment service for this particular event 81 00:06:00,100 --> 00:06:03,520 doesn't really need to know about the price or the cost of the ticket. 82 00:06:03,520 --> 00:06:11,210 It really just needs to be told hey do not expect any payments for order I.D. so and so so in total 83 00:06:11,220 --> 00:06:17,680 I think that the only data that we need to include here is the I.D. of the order itself and the idea 84 00:06:17,690 --> 00:06:23,860 of the ticket that we are trying to unreserved with the ticket service so we could say ticket tickets 85 00:06:24,020 --> 00:06:28,150 must be an I.D. is going to be a string. 86 00:06:28,190 --> 00:06:32,870 Now once again we could definitely throw in a ton more information describing the order without a doubt. 87 00:06:32,870 --> 00:06:39,620 We can include the user I.D. we can include the ticket price when this thing expires and so on but we 88 00:06:39,620 --> 00:06:44,470 don't really have any need to share that information with any other service inside of rap right now. 89 00:06:44,710 --> 00:06:48,900 This is kind of the point at which you need to make a decision on your own for your own personal app. 90 00:06:49,010 --> 00:06:54,230 When you create an event do you want to just by default assume you're going to share the maximum amount 91 00:06:54,230 --> 00:06:57,440 of information possible or do you just want to share the minimum. 92 00:06:57,440 --> 00:07:01,400 In this case we're sharing the minimum amount of information to describe the order. 93 00:07:01,400 --> 00:07:06,700 That was just cancelled because we know exactly what services are going to try to use this event that 94 00:07:06,820 --> 00:07:11,770 about site about this approach or the downside is that we are not really future proofing ourselves. 95 00:07:11,810 --> 00:07:16,970 There might be some point in time in the future where maybe the payment service does need to know the 96 00:07:16,970 --> 00:07:21,790 price of the ticket that was embedded with this order if that happened. 97 00:07:21,850 --> 00:07:26,020 If it turns out that the payment service does need to know that price well we would have to come back 98 00:07:26,020 --> 00:07:28,240 to this order created event interface. 99 00:07:28,240 --> 00:07:35,790 Just add on that tiny little price property and then republish this entire library so it's really up 100 00:07:35,790 --> 00:07:36,170 to you. 101 00:07:36,180 --> 00:07:40,560 Do you want to future proof your stuff and include as much info as possible or do you want to trim every 102 00:07:40,560 --> 00:07:42,900 event down to just the bare minimum. 103 00:07:42,900 --> 00:07:46,640 So again we're going to go with bare minimum in this case yet. 104 00:07:46,690 --> 00:07:51,190 Let's say this now the last thing we're going to do go back to our index not TSA file inside our SRT 105 00:07:51,190 --> 00:07:51,820 directory. 106 00:07:51,850 --> 00:07:55,870 We're gonna make sure that we export both the events we just created that year. 107 00:07:55,900 --> 00:08:03,780 Yes at the bottom will add on export star from events and then order canceled event then another one 108 00:08:03,780 --> 00:08:04,800 for events. 109 00:08:04,800 --> 00:08:13,670 Order read it event then save this and then finally we're going to update this module or republish the 110 00:08:13,670 --> 00:08:17,610 module and an update the module inside of our order service. 111 00:08:17,690 --> 00:08:26,040 So back at our terminal I will change into my command module I'll do an NPM run pub to republish this 112 00:08:27,430 --> 00:08:29,500 it looks like I'm on version 16 right now. 113 00:08:30,670 --> 00:08:33,280 You are probably on a way less version at this point. 114 00:08:33,310 --> 00:08:38,800 As I said I sometimes rerecord videos I can't really use version numbers and that's why I'm a little 115 00:08:38,800 --> 00:08:40,200 bit higher than you are most likely. 116 00:08:40,840 --> 00:08:48,100 So now that I've published this thing as version 16 I'm going to go back over to my orders service and 117 00:08:48,130 --> 00:08:51,950 inside of orders we'll do an NPM update. 118 00:08:53,200 --> 00:08:56,010 And then whatever your common module name is. 119 00:08:56,020 --> 00:09:00,460 So mine is SGI tickets coming and again yours is probably something very different 120 00:09:04,220 --> 00:09:08,090 and after that runs I'm just gonna make sure that I see the 1 6 right there. 121 00:09:08,090 --> 00:09:10,400 Yep looks good All right. 122 00:09:10,420 --> 00:09:11,230 That's it. 123 00:09:11,230 --> 00:09:12,430 Let's take a quick pause right here. 124 00:09:12,440 --> 00:09:17,410 When come back the next video we're going to make sure that we eventually emit these events or publish 125 00:09:17,410 --> 00:09:18,780 them from within our code. 126 00:09:19,180 --> 00:09:22,420 Whenever someone cancels in order or creates an order.