Introducing PrrrStack

This is the first part in a two-part introductory series to PRRR Stack (Postgres, Rust, Rocket, React) application. You’re probably wondering whether yet another stack is necessary, and the answer is of course not. Skepticism towards any one-technology-fits-all approach to web development is healthy. I learned web development with MEANstack and had no idea why I was using each piece. The same is probably true for many of the previous generation who started with LAMP. Technologies have their place and purpose, and learning a stack can be a good introduction to new things, but other than that, they’re just marketing (and I think I came up with a pretty good name to market).

Why use PRRR Stack then?

I guess the standard intro to new frameworks these days is a To Do list or a Tour of Heros. Well, since this is PrrrStack, we’ll do a Tour of Cats with lovely things like the cats’ names, bios, pictures, and their kill counts.

Let’s go ahead and add our dependencies to our Cargo.toml

Let’s also create the different files we’ll need in our /src directory, which should look like this:

Now that we’ve got that set up, well go ahead and build out a basic Rocket application and test it.

Here’s what our main.rs looks like:

A little on what it’s doing. First, we’re letting Rust know we want to use plugins. We’re then pulling in the external Rocket library. Next, we’re creating a function rocket that returns an instance of rocket::Rocket. Inside that function, we’re mounting our routes. Our only route at the moment is the get route defined by the Rocket macro below. Here, we see just one way that Rocket makes declaring (and protecting) routes easy. Finally, we’re calling the launch method on the returned instance of our rocket in our main function. Now all we have to do is type cargo run in the command line to compile and run our application. We should get something like this:

and if we check out locahost:8000 we should see “Hello!”. Gotta love those emojis!

Next, we’ll be setting up our database pool, building our models, and connecting our app to Postgres.

First, we’ll import the external modules we need into db.rs

Next, we’ll create a new type of Pool that implements a Postgres connection

And create a function that returns a Pool.

First, we’re creating another public structure DbConn. Next, we implement FromRequest which basically matches against our application’s state. If there is a pool, we’ll return a successful connection; if not, we’ll return a failure. Notice the 'a and 'r? Those are Rust lifetimes, which are a whole ‘nother can of worms we won’t open here, but the short of it is that they help keep things in memory as long as we need them.

Before I forget about it, let’s go ahead and create our .env file too, which only needs our database’s URL

followed by our up migration

and after that, we can go ahead and run them with diesel migration run. Now, our database should be ready with Diesel having done the work for us.

But how do we connect the database to our app? First, we create our schema. The Diesel docs say this in done for us, but it’s easy enough to do on our own.

After that, we create a model for our database in models.rs

Notice we have have two structs here. The Cat struct is for retrieving data from the database, while the NewCat (notice it’s lacking an ID) is for inserting a new cat into the database. While we’re here, lets go ahead and add the CRUD methods we’ll be building into our RestAPI.

I feel like these are pretty self-explanatory, so I won’t go into too much detail. A few things to note:

We’re almost there. The next step is to set up an endpoint for each of the methods we just created in routes.rs

Rocket’s macros make it clear and easy to use. We name the type, the URL, and format and data are optional. We’re also able to parse our ID from the URL by using <id>. Since DbConn implements FromRequest, each route verifies that our database connection is still open. Rust’s type system also validates our incoming JSON requests against our Cat and NewCat structs. Only when the API request is validated does it execute the corresponding methods we’ve attached to our models.

Now that the routes are working, all we have to do is connect our routes and database to our Rocket application in our main.rs.

Our rocket() function has grown quite a bit. We’re now declaring our database pool at the top of it an connecting our application to it with .manage(pool). We’ve also allowed for Cross-Origin Resource Sharing and configured it for our soon-to-be frontend and connected it to our application with .attach(options). Rocket, as it is now, is better set up for server-side rendering, but it is still pretty straightforward for building an API.

Our RestAPI appears to be working (it compiles at least), but let’s break Postman out for a few tests. Try posting a new cat tolocalhost:8000/api/cats:

Looks good so far, but lil’ Dingle Poo got out and had a blast at the bird feeder so we ought to update that kill count with a PUT request:

Neat. Play around, add more cats, and try out the methods. Be sure to check out Part 2 next week where we build our React frontend.

Related posts:

Affiliate marketing is a marketing arrangement in which a company or person markets goods and services in various ways. The affiliate receives a commission for each sale or leads that they generate…

Effective marketing is crucial in reaching the right audience and driving growth. However, with the ever-expanding landscape of marketing tasks, it can become overwhelming for entrepreneurs and small…

Now consumers search for meaning when dealing with brands more than ever before. This is a consequence of the large number of brands competing on almost every niche and the constant sum of…