Book Image

Rust Web Programming - Second Edition

By : Maxwell Flitton
Book Image

Rust Web Programming - Second Edition

By: Maxwell Flitton

Overview of this book

Are safety and high performance a big concern for you while developing web applications? With this practical Rust book, you’ll discover how you can implement Rust on the web to achieve the desired performance and security as you learn techniques and tooling to build fully operational web apps. In this second edition, you’ll get hands-on with implementing emerging Rust web frameworks, including Actix, Rocket, and Hyper. It also features HTTPS configuration on AWS when deploying a web application and introduces you to Terraform for automating the building of web infrastructure on AWS. What’s more, this edition also covers advanced async topics. Built on the Tokio async runtime, this explores TCP and framing, implementing async systems with the actor framework, and queuing tasks on Redis to be consumed by a number of worker nodes. Finally, you’ll go over best practices for packaging Rust servers in distroless Rust Docker images with database drivers, so your servers are a total size of 50Mb each. By the end of this book, you’ll have confidence in your skills to build robust, functional, and scalable web applications from scratch.
Table of Contents (27 chapters)
Free Chapter
1
Part 1:Getting Started with Rust Web Development
4
Part 2:Processing Data and Managing Displays
8
Part 3:Data Persistence
12
Part 4:Testing and Deployment
16
Part 5:Making Our Projects Flexible
19
Part 6:Exploring Protocol Programming and Async Concepts with Low-Level Network Applications

Working with workers

When it comes to defining workers, we can augment the Tokio runtime macro with the following code:

#[tokio::main(flavor = "multi_thread", worker_threads = 4)]
async fn main() {
    ...
}

Here, we can see that we state that the runtime is multithreaded, and we have four worker threads. Workers are essentially processes that run in constant loops. Each worker consumes tasks through a channel, putting them in a queue. The worker then works through the tasks, executing them in the order received. If a worker has finished all the tasks, it will search other queues belonging to other workers, stealing tasks if they are available, as seen here:

Figure 14.1 – Worker event loops (Work stealing runtime. By Carl Lerche – License MIT: https://tokio.rs/blog/2019-10-scheduler#the-next-generation-tokio-scheduler)

Figure 14.1 – Worker event loops (Work stealing runtime. By Carl Lerche – License MIT: https://tokio.rs/blog/2019-10-scheduler#the-next-generation-tokio-scheduler)

Now that we know we can alter the number of workers, we can test how the number of worker...