1 00:00:01,080 --> 00:00:04,460 At this point there are two ways we can move forward on our order service. 2 00:00:04,470 --> 00:00:09,570 We can either start to take a look at how we're going to publish some events around orders and listen 3 00:00:09,600 --> 00:00:12,220 or subscribe to events coming in as well. 4 00:00:12,300 --> 00:00:16,880 The other direction we can move is to focus first on all of our different root handlers. 5 00:00:16,920 --> 00:00:21,030 We're going to first implement these root handlers and then we're going to come back to all the event 6 00:00:21,030 --> 00:00:22,220 related stuff. 7 00:00:22,230 --> 00:00:26,970 The reason for that is that we still have not really done a deep dive on how we designed different events 8 00:00:27,210 --> 00:00:32,370 how we communicate them across different services and how we effectively think about the flows of a 9 00:00:32,370 --> 00:00:34,740 event through our application. 10 00:00:34,770 --> 00:00:38,970 So I really want to put together all these different handlers first and once we have all that completed 11 00:00:39,150 --> 00:00:44,040 will then have to really complete services the ticket service and the order service that needs have 12 00:00:44,070 --> 00:00:47,880 a really solid exchange of data through the eventing system. 13 00:00:47,880 --> 00:00:51,720 So at that point we can have a really deep dive and understand how to get these things to work together 14 00:00:51,720 --> 00:00:53,290 effectively. 15 00:00:53,310 --> 00:00:58,170 Having said that we still have this comment inside of our new root handler and I would definitely not 16 00:00:58,170 --> 00:01:02,310 want to forget that we need to come back here and eventually publish an event. 17 00:01:02,410 --> 00:01:06,780 So as a kind of reminder for that I'm going to go back over to the test file that we were just working 18 00:01:06,780 --> 00:01:12,750 on and at the very bottom I'm going to add in a new test right here and I'm going to market as a test 19 00:01:12,990 --> 00:01:15,930 that we need to come back and write so I can write out. 20 00:01:15,930 --> 00:01:26,750 It's got to do emits an order related event if I now see this file with that dot to do on there and 21 00:01:26,750 --> 00:01:31,690 go back over to my terminal you'll notice that that test is now showing up with this little special 22 00:01:31,690 --> 00:01:35,350 purple font and we are also being told there's one to do. 23 00:01:35,350 --> 00:01:40,690 So this is just to remind us that we need to come back to the new root handler and add in that root 24 00:01:40,780 --> 00:01:44,010 or extremely order created event. 25 00:01:44,390 --> 00:01:45,830 So that looks good. 26 00:01:45,920 --> 00:01:47,870 So we will come back to all the event related stuff. 27 00:01:47,900 --> 00:01:52,610 Once these root handlers are put together the next round handler we're gonna put it together is the 28 00:01:52,610 --> 00:01:55,820 index root handler so with this index right. 29 00:01:55,820 --> 00:02:00,860 HANDLER We want to find all the different orders related to the user who is making the request and just 30 00:02:00,860 --> 00:02:01,450 return them. 31 00:02:01,460 --> 00:02:02,720 That is pretty much it. 32 00:02:02,750 --> 00:02:06,970 So let's give this a shot to get started inside my roots directory. 33 00:02:06,970 --> 00:02:09,510 I'm gonna find the index t s file. 34 00:02:09,740 --> 00:02:11,560 We've already got some stuff inside of here. 35 00:02:11,620 --> 00:02:16,370 All we really have to do is add in a couple of different imports wire up middleware to add an add in 36 00:02:16,370 --> 00:02:21,230 some code to fetch all the related orders and send them back this right handler handlers can be pretty 37 00:02:21,230 --> 00:02:24,800 simple in nature so let's just get to it right away. 38 00:02:24,800 --> 00:02:29,150 The first thing we want to do here is to make sure that a user is logged in if they want to access this 39 00:02:29,150 --> 00:02:30,250 right handler. 40 00:02:30,290 --> 00:02:35,770 Orders are tied to very specific users and we only want a user to see the orders that they have created. 41 00:02:35,780 --> 00:02:41,090 So it definitely makes sense to say that you should only be able to access this handler if you are authenticated. 42 00:02:41,090 --> 00:02:49,450 So that mind at the very top we'll get started by importing require off from our common library and 43 00:02:49,460 --> 00:02:51,480 then add that as a middleware. 44 00:02:51,500 --> 00:02:52,010 Like so 45 00:02:56,140 --> 00:03:00,150 then if we get inside the body of this request handler we're definitely going to want to run some kind 46 00:03:00,150 --> 00:03:05,970 of query over our order collection and find all the different orders that belong to this user to run 47 00:03:05,970 --> 00:03:06,510 that query. 48 00:03:06,510 --> 00:03:11,100 We're definitely going to have to import our order model at the top of the file so I will import order 49 00:03:11,820 --> 00:03:16,250 from up one directory models order 50 00:03:19,220 --> 00:03:28,980 then inside of here right above the rest sent let's do a orders and we'll run our query so to run the 51 00:03:28,980 --> 00:03:31,040 query we're going to write out order find. 52 00:03:31,200 --> 00:03:36,350 And then inside of an object we're gonna put in the criteria of what orders we want to search for. 53 00:03:36,390 --> 00:03:41,130 You'll recall that all of our different orders store a user I.D. property and that user I.D. is the 54 00:03:41,130 --> 00:03:48,970 idea of the user who owns this order so we're going to do a query and try to find all the orders where 55 00:03:48,970 --> 00:03:53,260 the user I.D. is equal to the idea of the user who just made our request. 56 00:03:53,260 --> 00:03:58,770 And remember we are setting all that current user stuff and making sure that is available on the request 57 00:03:58,800 --> 00:04:01,190 to do the require auth and the current user middleware. 58 00:04:01,480 --> 00:04:11,050 So we should be able to do recurrent user exclamation dot i.e. that will get us all our orders. 59 00:04:11,050 --> 00:04:15,460 Now for each of the orders that we fetch we probably want to also include the ticket that the order 60 00:04:15,460 --> 00:04:16,300 is for. 61 00:04:16,300 --> 00:04:20,830 So in other words we should probably make sure we somehow fetch the ticket and get its title in its 62 00:04:20,830 --> 00:04:24,160 price and so on and send those back along with it. 63 00:04:24,160 --> 00:04:27,710 We're gonna do so using that populate system in mongoose. 64 00:04:27,730 --> 00:04:32,860 You recall that we took a look at how to fetch a particular order and also simultaneously load up the 65 00:04:32,890 --> 00:04:34,530 ticket associated with them. 66 00:04:34,660 --> 00:04:39,760 All we have to do is chain onto the end of this query a dot populate ticket that's it 67 00:04:43,130 --> 00:04:47,320 so once we get that list of orders pretty simple we'll just send it back. 68 00:04:47,320 --> 00:04:54,210 So resort sent and I'll send back the orders and I should be at. 69 00:04:54,330 --> 00:04:55,630 All right so let's say this. 70 00:04:55,650 --> 00:05:00,540 Once again we probably need to make sure that we write out a test to make sure that this works as expected. 71 00:05:00,540 --> 00:05:04,830 Again we don't have any code inside of our project right now around creating a ticket. 72 00:05:04,920 --> 00:05:10,070 So the only way that we can really simulate or test this stuff is through a automated test. 73 00:05:10,200 --> 00:05:15,000 So we're going to write out a test to create maybe one or two orders and assign tickets to both them 74 00:05:15,450 --> 00:05:19,470 and then make a request and just make sure that we get the list of orders tied to this user and the 75 00:05:19,470 --> 00:05:21,290 associated tickets. 76 00:05:21,420 --> 00:05:23,340 So let's put that test together in just a moment.