How I Start: Rust

Most versions don't mean much on their face -- every project has a different definition and way of versioning (usually undefined and fairly arbitrary, or based on client feature requirement and need-to-deploy).

But 1.0 is special -- pretty much everyone agrees on its meaning: it's ready for others to use it, and I'm willing to stand by it.

Sub-1.0 is also special, and generally agreed upon -- no one should consider this production-ready, and I'm not ready to defend it.

I mean, they could be, theoretically, but generally authors try to make the number a good reflection of the project's status.

> Actix-web is in 2.0.

What's the situation with use of unsafe now?

Although toxicity that was shown by the community was obviously uncalled for, I was very put off by the original author's stance on the issue and am wary of using it in production.

Note: there's a PR in for stabilisation for the requisite macro feature, and it looks like it's going to be merged soon.

I like node for really fast productivity, at the cost of a little potential stability... not the absolute best performance, but usually good enough.

Up from there would imho be Go or C#, mostly because they're faster than node, but still very accessible, and really good support around them for web services. Certain workloads are still not great. I think Java is probably okay, I just personally don't care for it, apparently it's gotten better than when I last used it regularly over a decade ago.

Rust is when you want balls out absolute performance in a language with newer, higher level features and constructs. The unsafe escape hatch is really there if/when you need it, but should not be the norm. The final executable size on rust is also impressive and will work very well in some constrained environments, or when you need better execution performance and more control than the others provide (outside of C/C++, D and a couple others).

I've only built a couple smaller web apps with rust so far, but the output size is impressive. Being able to build to a bare container or with busybox if some in-container scripting is needed has been a great experience so far.

Servlets have supported asynchronous IO for quite a while now.

Then there is the .NET stack as well.

For distributed computing I hardly see a reason to pick Rust over Java or .NET eco-system.

If we would be speaking about something like real time audio engine, then Rust would probably be the tool I would pick.

I don't understand either. I mean, it is fun and all, but for a serious project, why bother?

No, I'm not sure why the gruvbox theme I use has that for code examples. Here's what my coding view looks like: https://i.imgur.com/oWFlmgB.png

I'm used to doing stuff with WebAssembly, that is beyond the reach of `cargo run` most of the time.

I didn't know that! I've recently switched over to NixOS as my daily driver. I'll see what I can do to fix that for the future.

Thanks, I had the same issue - and only figured it out because this comment came up in Google results for the error message.

Macros are powerful, but they should be used sparingly because they often have outsize effects on compilation times and degrading error message quality. I personally give myself a "macro budget" where macro-based solutions are prioritized based on benefit to a particular project.

With great power comes great responsibility.

Based on my experience with macros, across several languages with support for them, macros are beautiful until you need to debug them under time pressure on a critical customer issue on a code base that you never seen before.

The best way to learn rust depends on your learning style, the Book (https://doc.rust-lang.org/book/index.html) is fantastic even as a reference. To learn rocket I'd start with the official tutorial here: https://rocket.rs/v0.4/guide/getting-started/#getting-starte...

It might sound canned, but the rust community generally has fantastic documentation and the few edge cases you'll hit are generally well-known in the github issues with well-known causes. My advice would be that if you feel like the compiler is giving you too much grief, take a break for a day or two and then come back to it, you might find that what was giving you trouble isn't so bad anymore. The compiler is very helpful with error messages but because of the litany of information that it gives you it can become a bit of a brain overload, especially if you hit a particularly nasty diesel type error (compile time SQL is no joke!)

It's also good to know in advance that the rust standard lib is great, but fairly bare bones if you want things like JSON support. Check out https://www.arewewebyet.org/ for the tools that can help you out!

EDIT: The only other thing that I just thought of is that authz/authn doesn't have a good story in rust just yet, so I'd rely on an external service of some kind to handle that for you unless you want to do basic signed session cookies.

Not the parent, so I can't speak for them, but my experience is that it's pretty likely that you'll eventually run into situations where you really want to store something different in the DB than what you send out from your API.

For example, you may want to keep some fields internal and not expose them to users, or you may want to normalize your DB schema so some fields are stored in a linked table, or maybe you had something as timestamp+duration, and need to keep the same external API for compatibility, but also want to refactor it internally into two timestamps.

Sure! Let's start with two baseline diesel structs:

    #[derive(Serialize, Deserialize, Identifiable, Queryable)]
    #[serde(rename_all = "camelCase")]
    struct User {
        pub id: Uuid,
        pub username: String,
        pub created_at: DateTime<Utc>,
        pub updated_at: DateTime<Utc>,
    }


    #[derive(Serialize, Deserialize, Identifiable, Queryable, Associations)]
    #[belongs_to(User)]
    #[serde(rename_all = "camelCase")]
    struct Business {
        pub id: Uuid,
        pub name: String,
        pub user_id
    }

And their respective endpoints:

    #[get("/users)]
    fn user_index(connection: &PgConnection) -> Result<Json<Vec<User>>, Status> {
        // Going to pretend like we have some helper methods to help us out here
        User::read_all().get_results::<User>(&*connection).map_err(|_| Status::Unavailable)?
    }

    #[get("/companies")]
    fn company_index(connection: &PgConnection) -> Result<Json<Vec<User>>, Status> {
        // Going to pretend like we have some helper methods to help us out here
        Company::read_all().get_results::<Company>(&*connection).map_err(|_| Status::Unavailable)?
    }

This is all well and good until maybe you have a UserPreferences model, which may or may not need its own route. Unlike other languages, you can't easily add attributes to structs. So if you made the choice to embed your UserPreferences into your User api response, you'd have to either: craft a json object from the json! macro, or alter all of your models anyways to introduce the new structure. Now your project/response structure would be:

    #[derive(Serialize, Deserialize)]
    struct UserApiResponse {
        id: Uuid,
        username: String.

        preferences: Option<UserPreferencesApiResponse>,
        company_id: Option<Uuid>
    }

    impl From<User> for UserApiResponse {
        fn from(user: User) -> Self {
            Self {
                id: user.id,
                username: user.username,
                preferences: None,
                company_id: None,
            }
        }
    }

    impl UserApiResponse {
        pub fn with_preferences<P: Into<UserApiPreferences>>(&mut self, preferences: P) {
            self.preferences = Some(preferences.into());
        }

        pub fn with_company<C: Into<CompanyApiResponse>>(&mut self, company: C) {
            self.company_id = company.id;
        }
    }

    #[get("/users)]
    fn user_index(connection: &PgConnection) -> Result<Json<Vec<User>>, Status> {
        let preferences = Preferences::read_all().get_results(&*connection).map_err(|_| Status::Unavailable)?;

        User::read_all().get_results::<User>(&*connection).map(|user| {
            let mut user: UserApiResponse = user.into();
            user.with_preferences(preferences.first().unwrap());
        }).map_err(|_| Status::Unavailable)?
    }

The code doesn't work out of the box but I hope that it conveys the idea that I'm trying to get across. This is sort of the same idea as Marshmallow in python or ActiveModelSerializers for Rails, but the problem is more pointed in rust because at least in python/ruby you can just shove on values as you need them (debatable if this is a good thing). The other thing that we've gained is consistency. Any change to an underlying serialization model is automatically reflected in any endpoint that may utilize it (also debatable if this is a good thing).

To really drive the point home, consider what would need to happen if we serialized out the database models directly from a REST standpoint. The steps would be:

    1. Fetch the user
    2. Fetch the preferences by filtering on user id (requires a query parameter)
    3. Fetch the company by filtering on user id (requires a query parameter)

In this new approach, we cut only one response, but if we were using GraphQL/JsonAPI we can cut this down even more.

If we stuck with our base schema we'd be locked into always modifying our database schema models, which IMO ties too much to the data access layer, or having separate fetches per request which is non ideal for a 250ms response time per request. In this world, we can go a step further without ever altering our DB models, which allows us to reason about them in a more dumb/CRUD way.

So the answer to both of those things is that I basically hammered out a bit of code that looks sort of like what I have but it's exactly. It should have been a 503 error instead.

In reality, the main thought is that the map_err in the controller should take some error and match against it for a known set of Error enums to translate to an enum that we want to get back out to the user.

> Also, I take it this code returns a body of { status: ..., message: ... } with a status of HTTP 500? So the enum variant "Unavailable" is just for programming syntax and unwraps around the Json<T> inner body when it's called by Rocket?

Yep! Exactly. It's a bit wonky but I thought it would be helpful to show off, especially in a world where JSON bodies with a shape of { status: "error" ... } are so common. In reality you can shove whatever you want in there and use serde to flatten the result. Off the top of my head, you could in theory do something like

    pub struct UserApiErrorMessage {
        status: String,
        message: String,
        #[serde(flatten)]
        _meta: HashMap<...>
    }

Where _meta holds some additional information you might want to dump to the user. In practice, I'm using this error enum approach to construct JSONAPI responses with appropriate status codes and the appropriate structure.

> Finally, I see you are making your diesel calls inside the controller.

So what I've found is that generally you actually don't want to embed your diesel get_result(s) calls inside your impls for your struct, since you're loading the entire set up into memory at once and you lose the ability to cut down. I've leveraged the `into_boxed` method of the query builder pretty heavily to allow for building up queries on the fly, which allows me to abstract the common bits into the impl. Code shows better than words so here we go:

    struct User { .. }

    type WithUsername<'a> = Eq<users::username, String>;

    impl User {
        pub fn read_all<'a>() -> BoxedQuery<'a, Pg> {
            users::table.order(users::created_at).into_boxed()
        }
 
        fn with_username(username: &String) -> WithUsername {
            users::username.eq(username)
        }
    }


    // In some method somewhere. Note: I don't know that this actually works out of the box because I didn't compile it
    User::read_all().filter(User::with_username(&username)).paginate(1).per_page(25).get_results::<User>()?

So I've cooked up a sort-of ORM for this, but I've abstracted away that underlying schema.rs file that's a huge part of diesel, since I think (but haven't proven) that leaking that file out into the rest of the codebase makes things tougher in the long run.

As to your point about the controller, I'd advise against it but hacked something together for the comment. In my project, I actually call out to simple services (think shitty service oriented architecture) that query the database and return a Result. What's interesting (or not) here is that my services actually call the `Into::into` of the database model, so my controller never even sees that they exist. Again, some code:

    // Actually in some other file
    mod service {
        mod users {
            pub fn get_user_page(conn: &PgConnection) -> Result<Vec<UserApiResponse>> {
                let users = User:read_all().paginate(1).per_page(25).get_results::<User>()?;
                users.iter().map(Into::into).collect::<Vec<_>>()
            }
        }
    }

    #[get("/users")]
    fn index(connection: &PgConnection) -> Result<Json<Vec<UserApiResponse>>> {
        service::users::get_user_page(&*connection).map(Json).map_err(...)
    }

But now we come to what I think is the most pertinent question: why does this exist? Testing. Spinning up a DB in CI is quite easy but since rust runs all testing in parallel (yay fearless concurrency!), we can get into trouble when we delete some records from the database but we haven't set up our tests to handle that. I ran into some really stupid problems I caused for myself in assuming that somehow it would be like rspec. If you can basically abstract away the database access part into a dumb hashmap, you get a store per test that won't experience much contention (at least that's the hope). I'm still working on that last bit so my thoughts on it are far and away from complete.

EDIT: Final note on diesel: there is no into_boxed for inserts and into_boxed for updates is dark magic that I can never get working correctly, so I'd avoid being too clever with these and focus on Select/Delete instead