WEBVTT 00:00.110 --> 00:00.410 Okay. 00:00.440 --> 00:05.420 Our penultimate task before we finish this section is just to make a small adjustment to our code inside 00:05.420 --> 00:07.070 this API controller. 00:07.100 --> 00:12.320 Now we've got a couple of endpoints here and both of them making a call to our database. 00:12.320 --> 00:13.760 The two list method here. 00:13.760 --> 00:16.460 This is making a call to our database as is. 00:16.460 --> 00:17.510 The find method. 00:17.510 --> 00:20.420 Here is also making a call to our database. 00:20.420 --> 00:26.390 Now what we have at the moment is a very small amount of code, a very small database that our database 00:26.420 --> 00:31.940 is local on our developer machine, so it doesn't have to traverse a network to go and get the results. 00:31.940 --> 00:38.030 The query is too small to give our database server even a SQLite database server, any trouble at all. 00:38.030 --> 00:40.160 It's just going to be super, super fast. 00:40.280 --> 00:46.550 So when it comes to synchronous code, it's not going to make any difference or perceptible difference 00:46.550 --> 00:48.470 to ourselves as developers. 00:48.470 --> 00:53.600 But I'm going to ask you to make a little bit of a change to this code, because it's best practice 00:53.600 --> 00:56.960 to turn this into asynchronous code. 00:56.960 --> 01:00.260 And the reason for this is really one of scalability. 01:00.260 --> 01:05.900 Now, when we publish our application onto a web server and it will be a cloud provider, but let's 01:05.900 --> 01:11.740 imagine it was a web server, then a web server has a number of threads that it can use to deal with 01:11.740 --> 01:13.300 API requests. 01:13.420 --> 01:19.540 So if a request comes into our getproducts and it encounters some synchronous code, then that thread 01:19.570 --> 01:25.270 is blocked until that request has completed and it's returned the response to the client. 01:25.300 --> 01:33.100 Now let's say our web server has ten threads and we have 20 customers making requests to our API server. 01:33.100 --> 01:38.950 Then things are going to slow down and requests are going to get blocked or queued. 01:38.950 --> 01:44.620 Whilst our web server is dealing with this request, which is synchronous code going to our database 01:44.620 --> 01:45.400 server. 01:45.700 --> 01:51.700 A common analogy is to think of the restaurant situation where you go in and you encounter a waiter 01:51.700 --> 01:53.200 and you order some food. 01:53.200 --> 01:58.540 The waiter then takes your request to the chef, but typically that waiter would go about taking other 01:58.540 --> 02:00.850 orders from other customers in the restaurant. 02:00.850 --> 02:06.100 But if that waiter was synchronous, then he wouldn't take any other orders. 02:06.370 --> 02:13.480 He would take your request, your request for food to the chef, and then he would wait around and keep 02:13.480 --> 02:15.280 waiting until the food is prepared. 02:15.280 --> 02:20.190 And then he takes your order to yourself, and then he would go to another customer and repeat the same 02:20.190 --> 02:21.090 process. 02:21.090 --> 02:23.100 And that would be a synchronous waiter. 02:23.100 --> 02:26.880 If he was an asynchronous waiter, then he does his normal job. 02:26.880 --> 02:31.140 He takes your request for food, he takes the order to the chef, the chefs cooking the food whilst 02:31.140 --> 02:32.760 the waiter is taking over orders. 02:32.790 --> 02:35.460 The same principle is in effect here. 02:35.460 --> 02:39.420 So let's turn this code into asynchronous code. 02:39.420 --> 02:43.500 And that just means making a few small changes inside our controller here. 02:43.500 --> 02:45.810 So first of all we make this an async method. 02:45.810 --> 02:51.060 We do that by using the async keyword before the what we're returning. 02:51.060 --> 02:56.010 And instead of returning an action result of list of products, we're returning a task here. 02:56.010 --> 02:59.430 So we specify task and then we open angle brackets. 02:59.430 --> 03:02.100 And we put what we are returning inside there. 03:02.190 --> 03:09.330 And the idea is that our request gets delegated to a task that goes off and queries the database. 03:09.330 --> 03:16.020 And once the database has responded, then this is passed back to the original thread to return to the 03:16.020 --> 03:17.070 client. 03:17.100 --> 03:22.740 In the meantime, whilst this task is going on, that original thread can go about servicing other ever 03:22.740 --> 03:23.850 requests. 03:23.850 --> 03:26.640 So we delegate the request to a task. 03:26.640 --> 03:32.730 And then once we've got the async keyword and we're returning a task, we can then use the await keyword 03:32.730 --> 03:35.640 to say that we're waiting for this response to come back. 03:35.640 --> 03:41.190 And then we use the async version of two list which is two list async. 03:41.250 --> 03:44.010 And then we can do similar fully getproduct as well. 03:44.010 --> 03:54.750 We can specify that we want to use async task of action result, and then we can use the await keyword 03:54.750 --> 03:57.180 on the await context products. 03:57.180 --> 04:01.980 Find and specify find async instead. 04:02.010 --> 04:08.520 Now you're not going to notice any difference at all based on these code changes. 04:08.550 --> 04:12.960 It's super tiny and it's just going to be impossible to see. 04:12.990 --> 04:15.990 But what I'm trying to say is that this is best practice. 04:16.020 --> 04:20.550 Using async methods for database queries is very typical. 04:20.550 --> 04:25.710 And how you would normally approach this, regardless of how small a query is to the database, just 04:25.710 --> 04:29.040 to avoid the situation where a thread could be locked. 04:29.040 --> 04:32.720 Whilst this request is going to get the data from the database. 04:32.750 --> 04:38.210 It just allows our web server to be a little bit more scalable and can handle more requests than not 04:38.210 --> 04:40.010 using asynchronous code. 04:40.040 --> 04:45.980 So after we've made that change, let's take a look at the status of our logs and see if it needs a 04:45.980 --> 04:46.550 restart. 04:46.550 --> 04:52.220 Because dotnet watch and hot reload, there's many things that it will not hot reload. 04:52.220 --> 04:57.590 And something that we've done says, yeah that's not going to hot reload because it's asking us if we 04:57.590 --> 04:59.150 want to restart our app. 04:59.150 --> 05:04.220 I'm going to say yes to restart the app and make sure everything is okay. 05:04.220 --> 05:09.140 And once it has restarted, let's just go back to postman and make sure that we haven't broken anything 05:09.140 --> 05:15.770 and make sure we can still send our request and get our products back, just as we did before. 05:15.770 --> 05:20.150 And like I say, you won't see any difference performance wise from that change that we've made. 05:20.150 --> 05:26.060 But it is best practice to use asynchronous code, especially for things like database queries. 05:26.180 --> 05:29.210 So that's all the code that we're going to write in this section. 05:29.210 --> 05:35.390 And the next thing we need to do is we need to save our changes into source control just in case of 05:35.390 --> 05:36.080 disaster. 05:36.080 --> 05:38.900 And we'll take a look at doing that next.