1 00:00:00,930 --> 00:00:04,860 In this video we're gonna take a look at a couple of different ways of making sure the expiration service 2 00:00:04,860 --> 00:00:09,360 waits about the 15 months or so before emitting that expiration complete event. 3 00:00:09,360 --> 00:00:13,460 The first thing we want to do is really just kind of picture that service in isolation. 4 00:00:13,470 --> 00:00:19,650 The idea here is order created comes in and then we're gonna have some mechanism inside of here to await 5 00:00:19,650 --> 00:00:25,170 that 15 minutes or so and then eventually emit some event of expiration complete. 6 00:00:25,250 --> 00:00:30,600 Now I keep talking about waiting 15 minutes and all that stuff just as a very quick reminder if we think 7 00:00:30,600 --> 00:00:36,780 back to when we actually create an order and where we assign that timer if we go back to our order service 8 00:00:36,780 --> 00:00:41,400 take a look at routes and then new T S inside of here. 9 00:00:41,410 --> 00:00:46,930 You'll recall that our mechanism for actually tracking when the order expires is a timestamp. 10 00:00:46,990 --> 00:00:51,220 So that is the time at some points in the future when this order is going to expire. 11 00:00:51,310 --> 00:00:55,900 So when I talk about waiting 15 minutes or something like that it's really not so much waiting for 15 12 00:00:55,900 --> 00:01:02,440 minutes so much as it is waiting for this timestamp to go from being in the future into the past. 13 00:01:02,440 --> 00:01:07,120 In other words when it is this time indicated by this time stamp right here that's where we want to 14 00:01:07,120 --> 00:01:10,710 emit this expiration complete Yvette. 15 00:01:10,710 --> 00:01:14,820 Having said that as we're discussing the service I'm really just going to keep saying oh yeah we want 16 00:01:14,820 --> 00:01:16,190 to wait 15 minutes or so. 17 00:01:16,320 --> 00:01:19,250 There's not technically we are waiting 15 minutes inside the service. 18 00:01:19,260 --> 00:01:24,090 It is really technically at some future point time that is indicated inside of this event. 19 00:01:24,120 --> 00:01:27,860 We want to admit that event of expiration completes. 20 00:01:27,940 --> 00:01:32,010 So that little disclaimer out of the way what are the ways that we can actually implement this. 21 00:01:32,020 --> 00:01:35,340 Well the first one that we can take a look at really simple super basic. 22 00:01:35,560 --> 00:01:40,650 We could say this is totally an option but there is a big downside to it we could say that whenever 23 00:01:40,650 --> 00:01:46,560 we see this event come in we could just use something like set time out so we can have some set time 24 00:01:46,560 --> 00:01:49,380 out function we tell it to wait 15 minutes. 25 00:01:49,380 --> 00:01:53,730 Now that's not actually valid right there we cannot give a set time out a string of 15 minutes but you 26 00:01:53,730 --> 00:01:58,320 get the idea we could provide some number of milliseconds to wait and after that number of milliseconds 27 00:01:58,320 --> 00:02:01,960 we can have some code inside of here to publish the expiration complete event. 28 00:02:02,150 --> 00:02:06,210 And this definitely is an option but it's not super viable. 29 00:02:06,270 --> 00:02:10,470 The reason that it's not a great option is that set time out stores a timer in memory. 30 00:02:10,950 --> 00:02:17,250 So if our expiration service were to ever restart for any reason whatsoever then all the timers that 31 00:02:17,250 --> 00:02:22,260 we have running at that point time are going to be lost and we're going to completely forget about the 32 00:02:22,260 --> 00:02:27,480 fact that well we have to publish in the expiration complete event in some remaining amount of time 33 00:02:28,450 --> 00:02:34,390 so this will be super simple in nature but a very clear downside to it so it's another option. 34 00:02:34,420 --> 00:02:40,360 The second option we have available to us would be to just set up a listener for order created and every 35 00:02:40,360 --> 00:02:45,850 single time we see this event come in we could check to see if the expires at time inside that event 36 00:02:46,090 --> 00:02:47,150 is in the past. 37 00:02:47,440 --> 00:02:53,890 If it is in the past then we could emit the expiration complete event and if it's not the past if that 38 00:02:53,890 --> 00:02:59,320 expiration time is still at some point in the future we can just not ask the incoming message if we 39 00:02:59,320 --> 00:03:02,260 do not act this incoming event or number acknowledge it. 40 00:03:02,290 --> 00:03:06,940 That means that NATS is going to automatically rediscover this thing five seconds in the future. 41 00:03:07,200 --> 00:03:12,040 And so we could just rely upon that constant rediscovery and every single time we could just check the 42 00:03:12,040 --> 00:03:17,890 expires at time and whenever it's in the past we can say okay time to actually act this event finally 43 00:03:17,950 --> 00:03:23,230 and publish our own and this is also without a doubt a viable option. 44 00:03:23,230 --> 00:03:29,100 We could definitely put something like this together but there is a pretty big downside to this one 45 00:03:29,100 --> 00:03:34,470 way of tracking events that fail constantly inside of application is to track the number of times that 46 00:03:34,470 --> 00:03:35,970 they get re delivered. 47 00:03:35,970 --> 00:03:40,380 So in other words we might have other events that we are having trouble processing inside of our app 48 00:03:40,920 --> 00:03:45,720 and for logging purposes we might want to track how many times they get rediscovered and then maybe 49 00:03:45,720 --> 00:03:50,460 after we have tried to process them say five six seven eight nine 10 times we might then through some 50 00:03:50,460 --> 00:03:56,730 kind of critical alert to our engineers and say hey there's some event that we just plain can't process. 51 00:03:56,730 --> 00:04:02,160 And so if we are relying upon this kind of reading every mechanism for both logging purposes and for 52 00:04:02,160 --> 00:04:06,510 some core business logic life is going gonna get really confusing really quickly. 53 00:04:06,510 --> 00:04:12,130 So although this could be a viable option I'd say that Ed just doesn't quite feel right and it's gonna 54 00:04:12,150 --> 00:04:19,360 make some things complicated and the line that's option number two is going to option number three option 55 00:04:19,360 --> 00:04:21,810 number three this would be a fantastic option. 56 00:04:21,820 --> 00:04:26,030 Unfortunately it is not supported by Nat string server. 57 00:04:26,170 --> 00:04:28,630 So down here I've got in this diagram message broker. 58 00:04:28,630 --> 00:04:34,720 So this is to say some other implementation of a event plus let's really be really precise here with 59 00:04:34,720 --> 00:04:43,000 our naming this would be not Nats there are other event bus implementations that are going to support 60 00:04:43,000 --> 00:04:43,830 this kind of feature. 61 00:04:43,850 --> 00:04:45,690 Let's first talk about what the future is. 62 00:04:45,700 --> 00:04:50,380 So in this approach approach number three we could say that whenever we receive order it created will 63 00:04:50,380 --> 00:04:55,240 then receive that inside of expiration service and without any delay whatsoever like the instant we 64 00:04:55,240 --> 00:05:01,360 receive this event we could publish our own event of expiration comp. But we could attach to that event 65 00:05:01,390 --> 00:05:02,220 when we publish it. 66 00:05:02,230 --> 00:05:09,540 We could tell our event bus to not publish this thing for another 15 minutes so in this case we'd be 67 00:05:09,600 --> 00:05:14,370 relying upon our event bus to wait 15 minutes before actually sending out this event to the rest of 68 00:05:14,370 --> 00:05:14,810 the world. 69 00:05:16,120 --> 00:05:21,700 Now unfortunately Napster server just doesn't support this this idea here of some kind of delayed message 70 00:05:21,730 --> 00:05:27,550 is referred to as a scheduled message or a scheduled event so you will see other event plus implementations 71 00:05:27,550 --> 00:05:28,230 that support this. 72 00:05:28,240 --> 00:05:33,670 But again not support by Nat string server and this would be a pretty great little feature if we had 73 00:05:33,730 --> 00:05:38,530 ability to do this because if we had the ability to do this we wouldn't even need at the expiration 74 00:05:38,530 --> 00:05:48,650 service we could actually just have our order service itself published an event that says oh hey remind 75 00:05:48,650 --> 00:05:52,070 me in 15 minutes that I need to expire this order. 76 00:05:52,070 --> 00:05:57,020 So in this scenario if we had access to this kind of future well the order service could just say Hey 77 00:05:57,020 --> 00:06:00,110 remind me in 15 minutes to do this thing and we would be all set. 78 00:06:00,110 --> 00:06:04,340 Good to go but for the fifth time now not supported by Natsumi server. 79 00:06:04,340 --> 00:06:06,440 So not an option. 80 00:06:06,460 --> 00:06:06,700 All right. 81 00:06:06,710 --> 00:06:11,650 So that's option number three onto option before and as usual as you can guess this is what we're gonna 82 00:06:11,650 --> 00:06:18,670 do inside of our application so inside of our expiration service we're going to make use of a little 83 00:06:18,670 --> 00:06:25,420 library called Bull J.S. This is a javascript library that allows us to essentially setup Long Live 84 00:06:25,480 --> 00:06:29,320 timers of sorts or essentially give ourselves notifications. 85 00:06:29,320 --> 00:06:34,870 It's really a very general purpose framework for allowing us to store some amount of data do some processing 86 00:06:34,870 --> 00:06:41,040 on it and possibly have some scheduled aspect to it as well so inside of our expiration service we're 87 00:06:41,040 --> 00:06:46,290 going to use bolt J.S. and we're going to tell it remind us in 15 minutes to do some amount of work 88 00:06:47,250 --> 00:06:53,040 we're going to pass that command into bulges and Bill James is going to store this little reminder inside 89 00:06:53,040 --> 00:07:00,160 of a readies instance if you're not familiar is read as is essentially an in memory database is very 90 00:07:00,160 --> 00:07:05,050 commonly used for tasks exactly like this right here the inside of readies bull is going to store a 91 00:07:05,050 --> 00:07:11,170 list of jobs or things that are scheduled to be done at some point in time after those 15 minutes elapse 92 00:07:11,610 --> 00:07:16,900 bull J.S. is then going to get a little reminder from readies that it needs to do something and ball 93 00:07:16,900 --> 00:07:21,220 in turn is going to turn back around to us and say hey 15 minutes have elapsed it's time for you to 94 00:07:21,220 --> 00:07:23,530 do whatever it is you wanted to do. 95 00:07:23,620 --> 00:07:29,290 And so for us we're going to just publishing events of expiration complete note that's it. 96 00:07:29,290 --> 00:07:30,820 That's what we're going to be using inside of our app. 97 00:07:31,540 --> 00:07:36,430 So for our expiration service really what we're going to be doing is focusing ourselves on learning 98 00:07:36,430 --> 00:07:41,530 a little bit more about this bull J.S. library and about how to set up a copy of readies inside of our 99 00:07:41,530 --> 00:07:43,760 communities cluster as well which will be. 100 00:07:43,750 --> 00:07:47,490 Trust me super easy and straightforward so that's it. 101 00:07:47,500 --> 00:07:48,490 That's a We're gonna go with. 102 00:07:48,640 --> 00:07:52,960 And I hope that the explanation of those other three options were Andy as well. 103 00:07:52,960 --> 00:07:55,480 Let's get started on this expiration service in the next video.