In our current version of the API, each HTTP request is blocking, as happened with Django and Flask. Thus, whenever the Tornado HTTP server receives an HTTP request, it doesn't start working on any other HTTP request in the incoming queue until the server sends the response for the first HTTP request it received. The methods we coded in the request handlers are working with a synchronous execution and they don't take advantage of the non-blocking features included in Tornado when combined with asynchronous executions.

In order to set the brightness level for both the blue and white LEDs, we have to make two HTTP PATCH requests. We will make them to understand how our current version of the API processes two incoming requests.

Open two Cygwin terminals in Windows or two Terminals in macOS or Linux, and write the following command in the first one. We will compose and send an HTTP request to set the brightness level for the blue LED to 255. Write the line in the first window, but don't press Enter yet, as we will try to launch two commands at almost the same time in two windows:

http PATCH :8888/leds/1 brightness_level=255

The following is the equivalent curl command:

curl -iX PATCH -H "Content-Type: application/json" -d
   '{"brightness_level":255}' :8888/leds/1

Now, go to the second window and write the following command. We will compose and send an HTTP request to set the brightness level for the white LED to 255. Write the line in the second window, but don't press Enter yet, as we will try to launch two commands at almost the same time in two windows:

http PATCH :8888/leds/2 brightness_level=255

The following is the equivalent curl command:

curl -iX PATCH -H "Content-Type: application/json" -d
   '{"brightness_level":255}' :8888/leds/2

Now, go to the first window, press Enter . Then, go to the second window and quickly press Enter. You will see the following line in the window that is running the Tornado HTTP server:

I've started setting the Blue LED's brightness level

Then, you will see the following lines that show the results of executing the print statements that describe when the code finished and then started setting the brightness level for the LEDs:

I've finished setting the Blue LED's brightness level
I've started setting the White LED's brightness level
I've finished setting the White LED's brightness level

It was necessary to wait for the request that changed the brightness level for the blue LED to finish before the server could process the HTTP that changes the brightness level for the white LED. The following screenshot shows three windows on Windows. The window on the left-hand side is running the Tornado HTTP server and displays the messages printed in the methods that process the HTTP requests. The window at the upper-right corner is running the http command to generate the HTTP request that changes the brightness level for the blue LED. The window at the lower-right corner is running the http command to generate the HTTP request that changes the brightness level for the white LED. It is a good idea to use a similar configuration to check the output while we compose and send the HTTP requests and how the synchronous execution is working on the current version of the API:

As each operation takes some time and blocks the possibility to process other incoming HTTP requests, we will create a new version of this API that will use asynchronous execution, and we will understand the advantages of Tornado's non-blocking features. This way, it will be possible to change the brightness level for the white LED while the other request is to change the brightness level for the blue LED. Tornado will be able to start processing requests while the I/O operations with the drone take some time to complete.