1 00:00:01,220 --> 00:00:05,840 We were just able to get some air messages inside a postman which means we're now doing some validation 2 00:00:05,840 --> 00:00:07,580 of the incoming request. 3 00:00:07,580 --> 00:00:12,540 Now this definitely all seems good but it also opens the door to a really interesting topic. 4 00:00:12,550 --> 00:00:16,550 They're actually going to spend a lot of time on in this application and this is a topic that we have 5 00:00:16,550 --> 00:00:20,420 not brushed upon or even discussed even remotely in the course so far. 6 00:00:20,420 --> 00:00:22,130 Kind of an interesting thing overall. 7 00:00:22,160 --> 00:00:24,700 So let me show you a quick diagram or two. 8 00:00:24,770 --> 00:00:25,050 All right. 9 00:00:25,070 --> 00:00:29,990 So here's what's going on inside of application right now or at least will be very shortly. 10 00:00:29,990 --> 00:00:33,460 Right now we are making a request from postman not a react application. 11 00:00:33,470 --> 00:00:39,120 Well let's just imagine for a second that we do build out that racked up so we will have our ReACT app 12 00:00:39,120 --> 00:00:40,410 running inside our browser. 13 00:00:40,410 --> 00:00:45,880 A user at some point time is going to attempt to sign up for an account and maybe they enter in an invalid 14 00:00:45,880 --> 00:00:51,040 e-mail or they enter an invalid password whatever it is some kind of invalid data that's going to be 15 00:00:51,040 --> 00:00:56,890 sent to our service or off service of course is currently working with express an actual validation 16 00:00:56,890 --> 00:01:03,660 is being done with Express validator so because we are sending in some invalid data we get back a response 17 00:01:03,780 --> 00:01:05,830 that has this kind of structure right here. 18 00:01:05,880 --> 00:01:11,560 This is abbreviated but it's more or less the structure of what we just got back inside of our response. 19 00:01:11,580 --> 00:01:19,260 So it's an array of objects each object has a value in as G short for message RAM and location. 20 00:01:19,260 --> 00:01:23,580 If we had multiple properties that were invalid it would all be listed out inside of separate objects 21 00:01:23,610 --> 00:01:24,810 inside this array. 22 00:01:24,870 --> 00:01:28,390 And so you can see that's kind of the structure of the response we just got back. 23 00:01:28,740 --> 00:01:34,410 Now really important note here we are only getting this structure of response. 24 00:01:34,410 --> 00:01:41,280 In other words an array of objects with a message property a param and those other two because we are 25 00:01:41,280 --> 00:01:47,490 using express validator the structure of response you see right here is not necessarily standard. 26 00:01:47,490 --> 00:01:52,440 We're not following a standard express validator is not following a standard there's not some standard 27 00:01:52,440 --> 00:01:57,090 out there were some documents out there online that says oh yeah this is how you need to send back some 28 00:01:57,090 --> 00:02:02,960 list of validation errors instead someone who put together express validator said like the actual author 29 00:02:02,980 --> 00:02:04,920 that library they sat down said you know what. 30 00:02:04,920 --> 00:02:09,100 I think that this is a response that kind of makes sense to describe what just went wrong. 31 00:02:09,120 --> 00:02:16,700 But this validation now the reason that is relevant is that we are in a micros services architecture 32 00:02:17,480 --> 00:02:22,370 and remember at some point time we're going to have to start to introduce many other services into our 33 00:02:22,370 --> 00:02:27,370 application so we might have an order service and a payment service as well. 34 00:02:27,380 --> 00:02:31,790 The other thing that's really relevant is that these other services could be built using completely 35 00:02:31,790 --> 00:02:34,480 different languages and frameworks. 36 00:02:34,610 --> 00:02:39,410 So we are going to of course build everything inside of our app with express and express validator. 37 00:02:39,450 --> 00:02:43,580 Well we could very easily imagine that if we were working on some professional project the order service 38 00:02:43,580 --> 00:02:49,130 might be using some Ruby on Rails API and the payment service might be using Java spring so totally 39 00:02:49,130 --> 00:02:52,160 different languages really different frameworks. 40 00:02:52,220 --> 00:02:57,770 Chances are you know I don't know this off the top of my head but chances are that if we ever have our 41 00:02:57,770 --> 00:03:04,760 ReACT application submit some invalid data to a ruby on rails at the ruby on rails app is probably gonna 42 00:03:04,760 --> 00:03:10,730 give back some response that looks very different than the one that we just got back from Express validator 43 00:03:11,620 --> 00:03:17,390 and same thing with Java spring as well if we submit some invalid data and Java spring does some validation 44 00:03:17,420 --> 00:03:21,830 on that incoming request it might send back a response that looks even more different than the Ruby 45 00:03:21,830 --> 00:03:23,480 on Rails one. 46 00:03:23,660 --> 00:03:27,860 So what trying to say here is that in the micro services environment where we're going to have multiple 47 00:03:27,860 --> 00:03:32,750 different languages multiple different frameworks running on all these different services whenever we 48 00:03:32,750 --> 00:03:38,480 submit some invalid data to these different services we're going to get back a response that might have 49 00:03:38,510 --> 00:03:43,290 a very different looking structure now quick question for you. 50 00:03:43,520 --> 00:03:45,410 Is that a problem. 51 00:03:45,530 --> 00:03:47,210 Is that an issue. 52 00:03:47,210 --> 00:03:52,490 Well I'm going to say it is a tremendous issue I'm going to say that is a huge problem. 53 00:03:52,490 --> 00:03:58,610 Here's why we are assuming that all these very different response structures are going to be going back 54 00:03:58,610 --> 00:04:00,990 to the same exact react application. 55 00:04:01,230 --> 00:04:06,800 So inside of our ReACT app we're going to have to encode the knowledge of how to work with these different 56 00:04:06,800 --> 00:04:12,680 kinds of responses the react app is going to have to know that if it is making a request to the off 57 00:04:12,740 --> 00:04:19,040 service it should respect a URL should expect a response that looks like this right here or in array 58 00:04:19,040 --> 00:04:25,010 of objects but those exact properties the react app will also have to know that if it is making a request 59 00:04:25,010 --> 00:04:29,120 of the order service it should expect a response that looks like that. 60 00:04:29,120 --> 00:04:33,950 And same thing with this payment service down here as well so the engineers who are in charge of this 61 00:04:33,950 --> 00:04:39,600 front end application are going to have to have a very in-depth knowledge of exactly what kind of air 62 00:04:39,600 --> 00:04:45,050 structure they're going to get back from each of these very particular services. 63 00:04:45,100 --> 00:04:49,330 And as you can guess that's not really a responsibility that we want to throw on the engineers. 64 00:04:49,340 --> 00:04:55,250 We're building our ReACT application so as we start to build out all these different services we need 65 00:04:55,250 --> 00:05:03,010 to make absolutely sure that every single one is going to send back a identical looking structure anytime 66 00:05:03,050 --> 00:05:05,480 there is some error that occurs. 67 00:05:05,480 --> 00:05:11,810 So we want to make sure that our ReACT app only has knowledge of how to pass exactly one kind of a response. 68 00:05:11,810 --> 00:05:17,780 It should always be maybe an array of objects or just a simple object we can use any structure for this 69 00:05:17,810 --> 00:05:19,000 a response that we want. 70 00:05:19,100 --> 00:05:24,670 We just need to make sure that it is 100 percent consistent between all of our different services again. 71 00:05:24,680 --> 00:05:30,320 So these react engineers don't have to understand that oh I'm making a request to my art service I should 72 00:05:30,320 --> 00:05:34,830 expect some kind of a response it looks like that versus something totally different. 73 00:05:34,850 --> 00:05:39,320 So as I mentioned at the start of this video we're actually spend a lot of time in this course to make 74 00:05:39,320 --> 00:05:41,830 sure that we've got extremely consistent error structures. 75 00:05:41,840 --> 00:05:47,540 Any time we make a request to any of our different services this will be a lot easier than it sounds. 76 00:05:47,630 --> 00:05:51,920 Mostly because remember we're going to end up creating that shared library that has a lot of code that 77 00:05:51,920 --> 00:05:55,820 we're gonna share between all of our different services and that's how we're gonna make this approach 78 00:05:55,820 --> 00:05:59,480 of handling errors rather easy and straightforward okay. 79 00:05:59,520 --> 00:06:04,310 So with all that in mind because we're here we're going to start doing some further work on our validation 80 00:06:04,370 --> 00:06:06,110 and the response in just a moment.