1. 45

I know this is nearly identical to my previous post, but this version is intended for submission to How I Start.

  1.  

  2. 5

    Thanks for the dockerfile here. I just started playing with Rocket earlier today after having finished up the Rust book. I felt like Rocket might be a good first “real” project framework. Getting something static is easy enough, but I still think I have more reading to do regarding lifetimes.

    1. 4

      Thanks for the dockerfile here.

      Unfortunately until cargo supports downloading crates only that Dockerfile is highly inefficient. That is for any code change it will have to download all crates over and over (thus not utilizing docker cache).

      Depending on your model you may also want to avoid using nightly (that this Dockerfile uses).

      Rocket, sadly, doesn’t support async functions yet.

      1. 7

        Nix to the rescue :). I use a combination of crate2nix which uses buildRustCrate to realize each crate in its own Nix store path plus dockerTools.buildLayeredImage to build a Docker image from a Nix derivation.

        Most builds Docker image builds only take 1-2 seconds that way.

        1. 2

          Thanks for the links. Any recommendations outside of warp that are worth looking at?

          1. 2

            Rocket, sadly, doesn’t support async functions yet

            It’s not that sad because async Rust is generally a poor engineering decision unless you’re building a load balancer.

            1. 3

              Quoting from your linked comment:

              Only good for load balancers that don’t do any CPU work anyway, which is exactly what the company behind tokio does. async-std got hijacked by ferrous to try to sell more Rust trainings, because it introduces so many hazards that you need to be educated to avoid.

              I’m not building a load balancer but indeed a service that is mostly I/O bound as it accesses other services. Informing about trade-offs of async is okay but bringing claims that it’s designed by ferrous to “sell more Rust trainings” is not really a technical argument.

        2. 3

          Very nice. I’m just starting to play with rust and found it helpful to see such detailed steps. As I’m playing with little toy projects, I’m tempted to turn it into a cookiecutter template to speed up my own experimentation. It seems like a good candidate for that.

          1. 2

            Please feel free to!

            1. 1

              I took a swing at it, and got far enough that I consider it useful. Take a look here if you’re interested.

              (Also, I sent you detailed feedback on the post via PM. If you didn’t get it or would find it easier to process via email, keybase chat, irc, etc., Let me know.)

              The upshot is that starting a new little web service based on your post is now

              cookiecutter https://git.sr.ht/~tuxpup/cookiecutter-rust-rocket-okapi
              #[... answer a few questions, most of which should have sensible defaults ...]
              cd host-info-service #or whatever you named your project
              cargo run
              

              Thanks again for posting this!

          2. 2

            I found a problem with many OpenAPI implementations is that they have issues implementing the specification. Not to blame the maintainers, of course, I have tried and only was able to implement a parser for a small portion of the spec before giving up. Since you mention using okapi as part of your new project setup, I was wondering if you had any problems after getting into some more complicated behaviors of APIs? i.e:

            • Query params
            • Headers
            • Schema objects (i.e nested json objects)
            • Form data

            etc

            1. 1

              What made you write about Rocket over the other Rust web frameworks?

              1. 4

                I personally find Rocket easier to use.

                1. 1

                  Thanks!

              2. 1

                ISTM that using macros to do something as normal as defining routes and handlers in an HTTP library is a sign that something is… off in the design. Like, I always understood macros as a feature-of-last-resort in most languages (c.f. e.g. Lisps) because of the way they subvert typical language constructs and our ability to mentally model programs. Is that not the case, or not accepted wisdom, in Rust?

                1. 5

                  Is that not the case, or not accepted wisdom, in Rust?

                  I think the macros being used in examples like this are mostly a gimmick. They make for nice hello worlds and can make for pretty concise code for simple web servers. They are also familiar to anyone who has built simple web servers in Python (using, say, bottle or Flask). Except in Python, you do it with “decorators.”

                  Like any language feature, folks will abuse it. Macros do have some very compelling use cases and they are used well there. The one that comes to mind is automatic serialization. Does something as “normal” as serialization using macros mean there is a design flaw somewhere? What about something as “normal” as serialization needing runtime reflection in languages like Go? In both cases, serialization without macros (or runtime reflection) is super annoying.

                  I’d say macro abuse in the Rust ecosystem is no better or worse than, say, reflection abuse in the Go ecosystem, if that makes sense.

                  1. 1

                    That makes things clearer, thank you. I guess that makes this a little like http.HandleFunc(”/route”, handler), all the way down to the implicit global http.DefaultServiceMux?

                    1. 2

                      That’s my understanding, yes.