Building the Rust Web App — Finishing Up

What I learned after using Rocket

Garrett Udstrand
Better Programming

--

Photo by Federico Bottos on Unsplash

This is the sixth and final part of a multi-part series about writing web apps. For this series, we will write the web app in Rust, and I’ll explain how to write it yourself.

If you’d rather not write out the code yourself, however, I have made a repository with all the code written throughout this series here. I made a commit to the repository at the end of each part of the series. In the previous part, we dealt with the fact our app can’t handle multiple users. In this part, we clean up the code from the previous five parts and discuss what you could do to improve this app and what you can read or do to improve your web development skills.

Clean Up

I’m not going to do anything crazy for this, but we should split our code into multiple files. While we could do something fancy for our code splitting, or we could go into greater depth with something like Clean Architecture, our project isn’t really complex enough to warrant that. Our current main.rs has just become so long that it's hard to read. First, create a file called lib.rs in src with the following code:

Then, make a file called render_routes.rs in src with the following code:

Then, create a file called task_routes.rs in src and include the following code:

Next, create a file called user_routes.rs in src with the following code:

Finally, go to main.rs and change it to look like the following:

Again, if you have trouble understanding the whole mod business, or how Rust splits code into multiple files, I suggest this chapter from the Rust book.

With that, our code is a bit cleaner. Instead of all of our code being in one large file, it’s split among multiple files with hopefully self-explanatory names. A different organization may be required if this was going to become some large or sophisticated project, but the organization used here is pretty good for our toy example.

Final Thoughts on Rocket

This was quite the journey to implement a basic todo app. If I had just stuck to not using the ORM, this probably would've been easier. Something like Sea ORM is useful when you have a lot of tables and data, but it's not really worth it for something as small as this.

I would've had a much easier time just sticking with the database driver and writing out the queries myself. Over-engineering a solution can often make the solution harder to use and leave the people left with your work very annoyed.

Overall, Rocket worked pretty wonderfully, even though I had a few pain points when getting the ORM to work. It really is simple to set up a server using it, and its extensibility allows you to go wild with how you use that server.

I think it is annoying that they don’t have some basic components to use to get started with authentication and force you to write out a lot of the authentication boilerplate other frameworks would generally help you avoid. Something like Laravel does a much better job at turning authentication into less of a hassle and pain.

I’m not sure if forwarding the request guards was the right move for re-directing a user to login if they weren’t authenticated. I couldn’t find any way to just redirect if the guard failed, so I ended up having to repeat the same small snippet over and over again to redirect to the login for every single route that had to be authenticated.

I guess the advantage is that the logic for routing is explicit, so I could change that to be something fancier in the future if I wanted. But it would be nice if I could define some default redirection if a request guard fails and have written forwards overwrite that, but I guess that may be hard to implement. And, again, it’s not exactly clear which design decision is better.

Being forced to write the redirect for each route means that any given route can have a custom redirect, so customizing, modifying, or extending our current redirect logic is much easier. However, it could be called a violation of DRY, and others would tell you YAGNI if you gave them that sort of argument.

Would I use it for an actual web application? Maybe, but it does seem like the code I ended up with was far more verbose than, say, a Laravel project. I feel like I could’ve implemented this basic CRUD example in Laravel ten times over in the time it took me to do it in Rocket.

However, after using Rust for this tutorial, I’ve fallen in love with it. Sorting out errors and writing in it has been a blast, but I’m not sure if Rocket is a good choice of framework if you are trying to produce an app in a reasonable amount of time. Maybe I’m slow, and it is a great choice. I’m not entirely decided yet.

Where to Go From Here

Now that you have a good idea of all the building blocks of web development, it may be a good idea to start developing your own web apps. As you run into problems, you’ll probably Google them, and you can start to fill out the gaps in knowledge I left here.

If you want to learn even more about web development even quicker, use another web framework like Laravel or Spring. Seeing slightly different interpretations of these concepts and other useful features can teach you even more about the web development space.

However, maybe you are just trying to bolster your development skills. In that case, there are plenty of books that can help you strengthen your code writing skills in general. I recommend Clean Code, Task-Centered User Interface Design, Code Complete, Second Edition, and The Mythical Man Month.

Finally, I would be chastised if I didn’t at least mention Design Patterns: Elements of Reusable Object-Oriented Software. I’m not sure if design patterns are all they’re cracked up to be, but being aware of them will make you better at communicating with your fellow developers. You shouldn’t follow any of these books’ advice dogmatically, and you don’t have to read all of these books cover-to-cover, but they can give you some useful ideas on how you should think of code and what “good code” looks like. They are especially useful for beginning developers.

If you want books that provide more concrete information that could help you improve, I suggest Effective Rust and Effective Java. Of course, neither are the final say on what good code looks like, but they give you a lot of ideas for improving your code in either language.

There are many other materials out there, so if you are not interested in any of the resources I’ve offered here, do some Googling and find your own technical resources that you think look promising. As long as you commit to yourself to becoming a better developer and take sincere and honest steps towards bettering yourself, you will become a good developer in no time.

Well, that’s all. I hope I taught you something in this mess of 21,000 words. Believe it or not, there are still a lot of concepts in web development that I didn’t even touch on here. There’s a large sea of knowledge when it comes to building web apps, but hopefully, I’ve given you enough information so that you can at least start building your own web apps.

Good luck, and thank you for reading!

Resources

--

--