1 00:00:01,180 --> 00:00:05,560 With both the custom event bus we put together and Nat streaming that we're using now. 2 00:00:05,590 --> 00:00:09,790 One thing that was really critical was to make sure that we could handle a service going offline for 3 00:00:09,790 --> 00:00:12,490 some period of time while the service is offline. 4 00:00:12,490 --> 00:00:15,540 We're not going to be able to process any events that are being emitted. 5 00:00:15,640 --> 00:00:19,390 So when this thing might come back online we need to make sure that we can somehow give it a list of 6 00:00:19,480 --> 00:00:23,260 all the events it has missed through and figure out how to do that with Nat streaming. 7 00:00:23,260 --> 00:00:27,760 In this video we're going to first take a look at a kind of naive way of doing this and then eventually 8 00:00:27,760 --> 00:00:33,400 how we can combine a couple of different options together to come up with a ideal solution whenever 9 00:00:33,400 --> 00:00:35,760 we emit or publish an event in that streaming. 10 00:00:35,840 --> 00:00:38,670 It's gonna be stored internally inside of this channel. 11 00:00:38,890 --> 00:00:44,440 So we might emit something like account deposits 70 NASA's going to try to deliver that to our service 12 00:00:44,650 --> 00:00:51,360 and simultaneously store a copy of that event as well we might then also emit this deposit of 40 dollars 13 00:00:51,630 --> 00:00:57,910 that will be emitted to the account service and simultaneously save to that history so all these events 14 00:00:57,910 --> 00:01:02,890 we ever emit and save a channel will be automatically saved when we then create a subscription at some 15 00:01:02,890 --> 00:01:08,920 point in time the future we can customize the subscription and tell it to somehow grab or get this list 16 00:01:08,920 --> 00:01:11,920 of events that have been emitted at some point in the past. 17 00:01:11,970 --> 00:01:16,630 So let's take a look at exactly how we do that and to get started going to first go back over my terminal 18 00:01:16,990 --> 00:01:20,020 and I'm going to close down the second copy of the listener. 19 00:01:20,210 --> 00:01:21,890 Things worked just a little bit differently. 20 00:01:21,910 --> 00:01:27,370 If we are running these options with a q group so I'm going to remove the Q Group very temporarily as 21 00:01:27,370 --> 00:01:32,630 we take a look at how we can re deliver these events that we missed in the past so I'll make sure that 22 00:01:32,630 --> 00:01:34,270 I only have one listener running. 23 00:01:34,270 --> 00:01:35,920 I'll then go over to my editor. 24 00:01:36,260 --> 00:01:41,120 I'm going to find that argument we put in B side of here of order service Q Group and delete it. 25 00:01:41,170 --> 00:01:48,820 Right now OK so now to somehow tell Nat so we want to re deliver or get some messages that have already 26 00:01:48,820 --> 00:01:50,000 been delivered in the past. 27 00:01:50,110 --> 00:01:55,870 We're going to add in another subscription option to this list of options to first get started by doing 28 00:01:55,900 --> 00:02:01,370 a command click on subscription options that will take me into the type definition file and I scheduled 29 00:02:01,390 --> 00:02:06,550 to scroll down just a little bit and see an interface right here of subscription options. 30 00:02:06,550 --> 00:02:10,990 If you do not see that interface then you can go back to where we just command click to and do a command 31 00:02:10,990 --> 00:02:17,180 click on the interface right here of subscription options so this has the listing of all the different 32 00:02:17,210 --> 00:02:21,800 option methods that are available to us we can scroll down a little bit and we're going to see that 33 00:02:21,800 --> 00:02:29,990 there are some options like set start at sequence set start time that start with last received and set 34 00:02:29,990 --> 00:02:31,440 deliver all available. 35 00:02:31,490 --> 00:02:37,010 So these are some different methods so we can call to customize which events we get replayed or reset 36 00:02:37,160 --> 00:02:43,040 that have been emitted in the past possibly while this service was offline let's try out set deliver 37 00:02:43,070 --> 00:02:44,300 all available. 38 00:02:44,300 --> 00:02:49,910 So if we add in this option to our subscription object that whenever our subscription gets created NATS 39 00:02:49,910 --> 00:02:55,550 is going to try to send over all the events that we missed while or before the subscription was ever 40 00:02:55,550 --> 00:02:58,650 created or while it's been down. 41 00:02:58,690 --> 00:03:05,670 So back inside my listener file I'm going to find the options object and I'm going to chain on after 42 00:03:05,670 --> 00:03:11,970 doing a little bit of cleanup here just to make this more legible set deliver all available like so 43 00:03:13,700 --> 00:03:18,980 and then going to save this look back over and will see that the still a running listener right here 44 00:03:19,220 --> 00:03:24,230 has restarted and has been sent all of the different events that we have emitted over time. 45 00:03:24,230 --> 00:03:30,560 If I tried to restart this with an R S when this subscription is recreated again on this next startup 46 00:03:30,800 --> 00:03:35,150 it gets sent all the events again and so I can restart as many times as I want and every single time 47 00:03:35,210 --> 00:03:38,070 I get emitted the big list of events. 48 00:03:38,220 --> 00:03:43,220 So clearly this is kind of handy for making sure that if a service ever goes down we can somehow get 49 00:03:43,220 --> 00:03:46,120 a list of all the events that have been emitted in the past. 50 00:03:46,130 --> 00:03:52,520 The only downside here is well every single time we start up a new listener because maybe we are restarting 51 00:03:52,520 --> 00:03:57,890 our service or maybe we are scaling it up or whatever it is we are going to be reading livered our big 52 00:03:57,890 --> 00:04:03,440 list of events after we've been running our application for possibly weeks months or years. 53 00:04:03,440 --> 00:04:08,930 There might be thousands or hundreds of thousands or even millions of different events saved up so it's 54 00:04:08,930 --> 00:04:14,540 not super feasible in the long term to just say that with every subscription give me all the different 55 00:04:14,540 --> 00:04:16,850 events that have ever been emitted. 56 00:04:16,850 --> 00:04:20,570 It could work but it's not super feasible. 57 00:04:20,570 --> 00:04:25,160 So we usually do not use this set deliver all available option by itself. 58 00:04:25,190 --> 00:04:29,870 Instead we're going to use this option along with one other option that's going to give us some more 59 00:04:29,870 --> 00:04:31,430 desirable behavior. 60 00:04:31,430 --> 00:04:32,410 Let's take a pause right here. 61 00:04:32,420 --> 00:04:34,680 We'll take a look at that other option in the next video.