1. 8

  2. 3

    I feel like this is a design document for a framework that doesn’t exist. I appreciate the post because there is a vacuum for convention-based, full-stack Rust web frameworks. I appreciate the post because I’ll refer to it in the short term. But it’s likely to bit-rot like other curations. To me, the next step would be a package or project at least full of wrappers. To me, the next step would be to create packages that represent the sections and put them together in a meta-package called nails. To me, this is a typical doc -> script -> program progression. More than that, if I wrote nails-auth as middleware, I’d have something to target. Right now, my integration test for nails-auth would be to follow this guide and write nails-auth against the result of these steps I guess?

    Here are three random packages from the post:

    cargo add dioxus@0.2

    Unless the author is planning on updating this blog post, this dioxus version will bit-rot

    Axum has support for Handlers

    Right now. This page is not authoritative for Axum. Could be in the future, could not be.

    validator = { version = “0”, features = [“derive”] }

    So the work in updating this blog post is making sure axum, validator and dioxus work together. Managing this matrix. If you have it documented then you could implement it. Flask is a framework that is flexible and simple but at some scale you have to assemble many pieces and find out if they work or not. There is definitely an “or not” in Flask and this is a trade-off of Flask solving some but not all problems likely to be encountered. Eventually someone created a meta-framework to put all the good Flask ideas together as a suggested happy Flask path. This is what Rails is.

    And that’s if the package selections don’t change. As technology changed, Rails swapped packages out as major version bumps over time (coffeescript, webpacker), sometimes changing not just implementation but direction. This process took a lot of work (more than I know) over many years. I think this is why there are so few frameworks like this.

    I’m not trying to FUD. I kicked around Go’s Buffalo because I wanted to believe that a systems language could scale up the abstraction levels. If this idea worked, I think it would attract and infuse new devs into Rust. The results would be visible as projects being completed, ideas being published and companies not only betting on a stack but executing on it. It would be observable and the first time (afaik) that somethings scaled from kernel modules to full-stack web.

    1. 1

      This is a starter template based on a real-world startups usage.

      The first few sections are solid. I spent some time last weekend sending in some fixes. The sections towards the end need a bit of work. I need to submit my idea for the form section to make it more interactive.

      Anyways, I found this was much more approachable than other walk-troughs.

      1. 1

        This has a pretty solid start. I especially liked the database crate, which allows you to just write your migrations and queries in pure SQL and get the boilerplate generated for that. I’ve been using SeaORM previously, and not having to work “around” the ORM builder can be really refreshing.

        I do have to say that their choice of server side rendering via macro based component creation feels like a bad move. You generally don’t want macros for something like this. Macros for something that can get pretty big will end up with long compile times, while coming with a worse error story than normal rustc errors. I would use something like Tera instead.