Okay.
Our penultimate task before we finish this section is just to make a small adjustment to our code inside
this API controller.
Now we've got a couple of endpoints here and both of them making a call to our database.
The two list method here.
This is making a call to our database as is.
The find method.
Here is also making a call to our database.
Now what we have at the moment is a very small amount of code, a very small database that our database
is local on our developer machine, so it doesn't have to traverse a network to go and get the results.
The query is too small to give our database server even a SQLite database server, any trouble at all.
It's just going to be super, super fast.
So when it comes to synchronous code, it's not going to make any difference or perceptible difference
to ourselves as developers.
But I'm going to ask you to make a little bit of a change to this code, because it's best practice
to turn this into asynchronous code.
And the reason for this is really one of scalability.
Now, when we publish our application onto a web server and it will be a cloud provider, but let's
imagine it was a web server, then a web server has a number of threads that it can use to deal with
API requests.
So if a request comes into our getproducts and it encounters some synchronous code, then that thread
is blocked until that request has completed and it's returned the response to the client.
Now let's say our web server has ten threads and we have 20 customers making requests to our API server.
Then things are going to slow down and requests are going to get blocked or queued.
Whilst our web server is dealing with this request, which is synchronous code going to our database
server.
A common analogy is to think of the restaurant situation where you go in and you encounter a waiter
and you order some food.
The waiter then takes your request to the chef, but typically that waiter would go about taking other
orders from other customers in the restaurant.
But if that waiter was synchronous, then he wouldn't take any other orders.
He would take your request, your request for food to the chef, and then he would wait around and keep
waiting until the food is prepared.
And then he takes your order to yourself, and then he would go to another customer and repeat the same
process.
And that would be a synchronous waiter.
If he was an asynchronous waiter, then he does his normal job.
He takes your request for food, he takes the order to the chef, the chefs cooking the food whilst
the waiter is taking over orders.
The same principle is in effect here.
So let's turn this code into asynchronous code.
And that just means making a few small changes inside our controller here.
So first of all we make this an async method.
We do that by using the async keyword before the what we're returning.
And instead of returning an action result of list of products, we're returning a task here.
So we specify task and then we open angle brackets.
And we put what we are returning inside there.
And the idea is that our request gets delegated to a task that goes off and queries the database.
And once the database has responded, then this is passed back to the original thread to return to the
client.
In the meantime, whilst this task is going on, that original thread can go about servicing other ever
requests.
So we delegate the request to a task.
And then once we've got the async keyword and we're returning a task, we can then use the await keyword
to say that we're waiting for this response to come back.
And then we use the async version of two list which is two list async.
And then we can do similar fully getproduct as well.
We can specify that we want to use async task of action result, and then we can use the await keyword
on the await context products.
Find and specify find async instead.
Now you're not going to notice any difference at all based on these code changes.
It's super tiny and it's just going to be impossible to see.
But what I'm trying to say is that this is best practice.
Using async methods for database queries is very typical.
And how you would normally approach this, regardless of how small a query is to the database, just
to avoid the situation where a thread could be locked.
Whilst this request is going to get the data from the database.
It just allows our web server to be a little bit more scalable and can handle more requests than not
using asynchronous code.
So after we've made that change, let's take a look at the status of our logs and see if it needs a
restart.
Because dotnet watch and hot reload, there's many things that it will not hot reload.
And something that we've done says, yeah that's not going to hot reload because it's asking us if we
want to restart our app.
I'm going to say yes to restart the app and make sure everything is okay.
And once it has restarted, let's just go back to postman and make sure that we haven't broken anything
and make sure we can still send our request and get our products back, just as we did before.
And like I say, you won't see any difference performance wise from that change that we've made.
But it is best practice to use asynchronous code, especially for things like database queries.
So that's all the code that we're going to write in this section.
And the next thing we need to do is we need to save our changes into source control just in case of
disaster.
And we'll take a look at doing that next.