1 00:00:01,350 --> 00:00:05,060 We've now got Napster and server up and running inside of our Cuban 80s cluster. 2 00:00:05,160 --> 00:00:09,600 In this video I want to give you a quick overview on how Napster and server differs from that custom 3 00:00:09,600 --> 00:00:12,330 event bus we had put together back in our first application. 4 00:00:12,330 --> 00:00:15,690 We're going to focus on some high level items and then immediately after that we're going to start to 5 00:00:15,690 --> 00:00:21,390 work on a very small little stand alone project to get a better idea of how we interact with that streaming 6 00:00:21,390 --> 00:00:23,770 server and some of its different properties. 7 00:00:23,790 --> 00:00:25,670 So let's get to it. 8 00:00:25,840 --> 00:00:29,140 We're going to take a look at a couple of different diagrams in every one of these diagrams. 9 00:00:29,140 --> 00:00:32,900 I'm going to show you something that our custom event bus we had previously built did. 10 00:00:33,040 --> 00:00:36,800 And then we'll compare that to how that streaming server behaves. 11 00:00:36,820 --> 00:00:41,920 The first thing I want to think about is how we communicated events between different things with that 12 00:00:41,920 --> 00:00:44,450 custom event bus we had previously built. 13 00:00:44,470 --> 00:00:49,420 So with the custom event bus we might have had some service that would build up and events and then 14 00:00:49,420 --> 00:00:56,190 we use axes to make a post request directly over to that customer event bus the customer event bus was 15 00:00:56,190 --> 00:01:01,980 running a copy of Express so it listens for incoming post requests it would receive that event and then 16 00:01:01,980 --> 00:01:06,440 internally take the event and make its own post request using axioms. 17 00:01:06,740 --> 00:01:11,880 Out to some other service inside of application and those other services were running their own copies 18 00:01:11,880 --> 00:01:18,710 of express that would listen for incoming events so this was a very simplistic approach where we basically 19 00:01:18,710 --> 00:01:24,610 relied upon the libraries of axles and express that was pretty much it now that we are using that streaming 20 00:01:24,610 --> 00:01:24,970 server. 21 00:01:24,970 --> 00:01:30,100 However we're not going to be using express or axles to share events around our application. 22 00:01:30,100 --> 00:01:35,140 Instead we are going to use a client's library that is specifically designed to work with that streaming 23 00:01:35,140 --> 00:01:40,340 server the client library that we're going to use is called node that's streaming. 24 00:01:40,360 --> 00:01:42,970 Let's take a look at the documentation for it on NPM. 25 00:01:42,970 --> 00:01:49,890 Right now I'm going to open up a new browser tab and navigate to NPM J.S. dot com once here. 26 00:01:49,930 --> 00:01:52,180 I will look up node that's streaming 27 00:01:56,010 --> 00:01:57,700 here's the documentation for it. 28 00:01:57,690 --> 00:02:02,090 Now there's a lot of stuff in here that is just chock full of information. 29 00:02:02,100 --> 00:02:06,780 There's a lot of stuff going on inside of here and unfortunately whereas a lot of libraries out there 30 00:02:06,780 --> 00:02:10,890 you can kind of just skim over it and say oh yeah I know what's going on and then reference it in the 31 00:02:10,890 --> 00:02:13,710 future anytime some specific problem comes up. 32 00:02:13,710 --> 00:02:18,990 Unfortunately with this library and that streaming server it is kind of important to understand the 33 00:02:18,990 --> 00:02:22,570 internals or how this stuff is really working from the get go. 34 00:02:22,620 --> 00:02:27,780 So that's why we're going to do a little stand alone project to work just with Nat string server by 35 00:02:27,780 --> 00:02:31,890 itself and not worry about any services or communities or anything like that. 36 00:02:32,070 --> 00:02:36,570 We're going to have this little standalone project just we can understand these very important internal 37 00:02:36,630 --> 00:02:42,620 mechanics they're going to be critical for us to use to properly communicate data throughout our application. 38 00:02:42,620 --> 00:02:45,340 The one thing I do want to point out around is documentation right away. 39 00:02:45,380 --> 00:02:49,790 If you take a look at the basic usage section you'll notice that to work with this library we've got 40 00:02:49,790 --> 00:02:56,250 a very event based kind of architecture so in other words if you're familiar with event emitter in no 41 00:02:56,270 --> 00:03:01,890 J.S. or any other kind of eventing library where we emit events and listen to them in plain javascript 42 00:03:01,890 --> 00:03:04,600 code that is really how this library works. 43 00:03:04,650 --> 00:03:10,650 So we're going to create some objects we're going to setup event listeners and we're going to emit events 44 00:03:10,770 --> 00:03:15,920 as well and all works with a very heavily callback based kind of infrastructure. 45 00:03:15,920 --> 00:03:20,000 So unfortunately we are going to be relying quite a bit on callbacks with this library as opposed to 46 00:03:20,000 --> 00:03:24,590 using async await or anything like that. 47 00:03:24,590 --> 00:03:24,860 All right. 48 00:03:24,860 --> 00:03:26,040 Back over to our diagram. 49 00:03:26,120 --> 00:03:30,770 So we're going to do it like I said be using no net streaming to create events send them over to that 50 00:03:30,770 --> 00:03:35,240 streaming server and then that streaming server is going to send those out to our different services 51 00:03:35,780 --> 00:03:37,370 which will be listening for events. 52 00:03:37,370 --> 00:03:42,740 Also using the known that streaming library we're not going have access or express dedicated solely 53 00:03:42,740 --> 00:03:44,930 to handling events or anything like that. 54 00:03:44,990 --> 00:03:49,760 We will of course still use axes or express for normal HDTV requests and so on. 55 00:03:49,760 --> 00:03:54,260 I just mean to say that for all the event related stuff we're going to be using Node Nats streaming 56 00:03:56,040 --> 00:03:56,470 OK. 57 00:03:56,470 --> 00:03:57,380 Second thing here. 58 00:03:57,790 --> 00:04:05,270 So with our custom event plus anytime we emitted an event that event was sent over to every single service. 59 00:04:05,320 --> 00:04:12,650 So for example if we had our ticket service emit an event of ticket update event we received it on our 60 00:04:12,650 --> 00:04:17,780 customer event bus and we sent a copy of it off to our order service and whatever other service. 61 00:04:17,780 --> 00:04:20,850 Now of course we didn't actually have these services in our first application. 62 00:04:20,900 --> 00:04:25,620 I just mean to say if we had used this custom event bus in our current app this is how it would work. 63 00:04:25,730 --> 00:04:29,960 So we would receive an event and throw it off to every different service technically even the service 64 00:04:29,960 --> 00:04:35,000 that had sent it to the event plus the technically an event or the same event went directly back to 65 00:04:35,000 --> 00:04:40,960 the ticket service which was not super useful as your guests no doubt streaming is me very different 66 00:04:40,960 --> 00:04:48,670 in nature that streaming is going to requires to subscribe to specific channels so a channel overall 67 00:04:48,700 --> 00:04:51,350 is gonna use the term topic somewhat interchangeably. 68 00:04:51,350 --> 00:04:56,960 These are essentially types of events or channels of events that we're going to be listening to specifically 69 00:04:57,080 --> 00:04:59,460 inside of our different services. 70 00:04:59,480 --> 00:05:04,370 So for example on that streaming server we will create a collection of different topics or channels 71 00:05:04,580 --> 00:05:10,740 we're gonna use that term pretty interchangeably then whenever we want to emit some kind of event we'll 72 00:05:10,740 --> 00:05:15,720 create it inside of one service we'll reach out to the node in that streaming library and we will tell 73 00:05:15,720 --> 00:05:22,140 it publish this event to the ticket call an updated channel so that event will be emitted out of our 74 00:05:22,140 --> 00:05:28,680 ticket service it will go over to this channel on no net streaming and then the event will be sent along 75 00:05:28,920 --> 00:05:33,230 to only the services that are listening on that very specific channel. 76 00:05:33,240 --> 00:05:38,730 So for example if our order service is listening for events on ticket colon updated then it will receive 77 00:05:38,730 --> 00:05:40,200 a copy of this event. 78 00:05:40,310 --> 00:05:44,700 What if some other service such as say payment service was not listening to that channel it would not 79 00:05:44,700 --> 00:05:45,520 receive it. 80 00:05:45,770 --> 00:05:48,420 So no longer does one event get sent everywhere. 81 00:05:48,450 --> 00:05:55,090 Instead we have to specifically say you are the different topics or channels that we care about these 82 00:05:55,090 --> 00:05:57,600 are the different topics or channels that are going to exist. 83 00:05:57,820 --> 00:06:02,620 And we have to specifically subscribe to them inside of our different services to actually receive those 84 00:06:02,620 --> 00:06:05,300 events. 85 00:06:05,360 --> 00:06:07,180 All right onto the next diagram. 86 00:06:07,250 --> 00:06:12,680 So next thing back with our customer event plus we have put together a memory store of sorts to store 87 00:06:12,710 --> 00:06:15,030 all the different events that were ever emitted. 88 00:06:15,040 --> 00:06:19,760 So for example if we had our ticket service emit an event again of ticket updated we would store that 89 00:06:19,790 --> 00:06:23,900 inside of a in memory array. 90 00:06:23,940 --> 00:06:26,640 It would of course also be emitted to all of our different services. 91 00:06:26,730 --> 00:06:29,310 But we held onto a copy of it as well. 92 00:06:29,310 --> 00:06:34,590 This feature right here was absolutely critical so we could handle temporary downtime of any given service. 93 00:06:34,590 --> 00:06:39,720 If some service went offline for some a very brief period of time it could then come back online and 94 00:06:39,720 --> 00:06:43,440 ask for a list of all the different events that had ever been emitted. 95 00:06:43,440 --> 00:06:47,940 And so we can make sure that some service was down for some period could come back online and fetch 96 00:06:47,970 --> 00:06:52,930 or retrieve all the data or events at administering that period. 97 00:06:52,940 --> 00:06:56,570 This is also fantastic for any time we needed to add in a new service. 98 00:06:56,600 --> 00:07:01,580 So for example if we decided to create a new service and add it into our application maybe in this case 99 00:07:01,580 --> 00:07:06,050 we call it payment service the payment service could then reach out to the event boss and say hey give 100 00:07:06,050 --> 00:07:11,930 me a listing of all the different events that have ever been emitted so we could then take our big list 101 00:07:11,930 --> 00:07:17,420 of events send them all down and then the payment service or whatever new service this is would then 102 00:07:17,420 --> 00:07:23,650 be magically and suddenly up to date with all the relevant data inside of our app so this idea of storing 103 00:07:23,650 --> 00:07:30,040 memory or storing events somehow was really critical for handling outages or handling any new service 104 00:07:30,050 --> 00:07:31,520 we pulled up as well. 105 00:07:33,210 --> 00:07:40,080 Now streaming server has a very similar idea but it's way more complex and robust so with that streaming 106 00:07:40,080 --> 00:07:45,420 server it's going to store all the different events to get emitted in memory by default. 107 00:07:45,420 --> 00:07:50,400 However we can also customize it to store these events inside of flat files stored on a hard drive or 108 00:07:50,400 --> 00:07:54,330 even inside of a database like my sequel or post grass. 109 00:07:54,450 --> 00:08:01,570 So again for example ticket service could be met and events over to it that streaming server it'll be 110 00:08:01,570 --> 00:08:08,310 stored inside of memory and simultaneously a copy of that event will be sent out to all the relevant 111 00:08:08,310 --> 00:08:09,600 services. 112 00:08:09,720 --> 00:08:15,120 If we then at some point time bring a payment service or some newbie service online it can reach out 113 00:08:15,130 --> 00:08:21,570 to that streaming server ask for a copy of all the different events and that streaming server will respond 114 00:08:22,080 --> 00:08:27,610 with all the relevant events that it has missed out on so the same thing is true. 115 00:08:27,700 --> 00:08:32,910 If we decide to store all these events on a flat file my single database or post press as well. 116 00:08:33,570 --> 00:08:35,790 So I'm not going to go through drawing out the entire diagram. 117 00:08:35,790 --> 00:08:41,990 I think you get the idea here if we met you met an event over time that streaming server we can configure 118 00:08:41,990 --> 00:08:42,780 it so choose. 119 00:08:42,920 --> 00:08:45,860 These events get stored inside of some file or database. 120 00:08:46,310 --> 00:08:51,380 So now if our Napster in separate server ever goes off line or has to be restarted of course it loses 121 00:08:51,380 --> 00:08:52,860 everything stored in memory. 122 00:08:53,060 --> 00:08:56,060 What if we stored those events inside of a file or a database. 123 00:08:56,180 --> 00:09:00,800 Then after the streaming server comes back line it could connect to that database or that file. 124 00:09:00,800 --> 00:09:06,600 Take a look at it and say oh OK here's all the different events that have ever been emitted. 125 00:09:06,780 --> 00:09:07,590 So that is it. 126 00:09:07,590 --> 00:09:13,410 Those are some very high level notes on some critical differences between our event bus and that streaming 127 00:09:13,410 --> 00:09:14,060 server. 128 00:09:14,140 --> 00:09:19,170 The big ticket items here are that we're going to use this custom little client library called no net 129 00:09:19,170 --> 00:09:21,460 streaming to communicate. 130 00:09:21,570 --> 00:09:26,550 Next up with Nat streaming we have to create these things that are called topics or where else can use 131 00:09:26,550 --> 00:09:32,130 the term channels for them and then our services have to split it specifically subscribe to events from 132 00:09:32,130 --> 00:09:39,000 these specific channels and then finally very similar to our custom event plus we can have that streaming 133 00:09:39,000 --> 00:09:46,610 server store all these events in memory or alternately stored them inside of a file or database as well. 134 00:09:46,770 --> 00:09:49,430 That's what we understand Sony's very core differences. 135 00:09:49,430 --> 00:09:52,320 We're gonna take a pause right here and then start writing some code in the next video.