Initial thoughts on migration from tide to trillium

[prabirshrestha]

I finished porting rblog a simple filesystem blog engine written in tide to trillium and is now live at https://blog.prabir.me and wanted to provide my initial thoughts. While rblog is simple I tried to use as much feature as possible to get the overall experience where applicable. For bugs discovered, I have already submitted separate issues but rather than creating n number of feature requests writing in one (thanks for fixing it already).

• Similar to tide, concepts in trillium is very easy to grok
• (conn) -> Conn as handler is a very powerful concept. No need to think if it is a middleware or routes or util function. Just create a handler and it is reusable by default. Can't wait for the community to provide more of these.
• I think in statuscode -> headers -> body, so when template engines modifies the status code to 200 by default due to ok() I need to reorder. This will be difficult to catch even during PRs and I was most likely just lucky that I caught it as I was debugging the network traffic and verifying. In this 404 case I had to call with_status in the end.

pub async fn not_found(conn: Conn) -> Conn {
    conn.render_html(|o| templates::notfound(o))
        .with_status(Status::NotFound)
}

• ConnId. My general thought is to never trust the user data. I have always had ClientRequestId and ServerRequestId. This ways if someone is using a tool and spamming or reruns the fiddler requests, we still get the same client request id but new server request id. This would be very useful for debugging.
• No Conn Ext to send file. Add support for sending a file #112. (filesystem in general could be interesting, since there could be lot of asks such as uploading file, moving file, deleting file and so on. I'll try to update async-vfs to support more runtimes and change the apis so it can align to trillium better).
• HOST needs to be set to 0.0.0.0 for Docker to accept incoming requests. A comment in docs would help?
• Love the trillium.rs website. I always had it open and was looking at code samples. I preferred it over the rust docs. As a new comer to the library this was very useful and thanks for taking the time. I would personally love to have more documented. For example I had to look at source code for ConnId usage.
• StaticFiles should include ETag, If-None-Match headers.
• Miss the Result<> as described in Better documentation/discussion for error handling #31 but slowly started to get used to conn_try and conn_wrap. Axum seems to have IntoResponse() which was an interesting concept.
• Compression handler. I think this should be a high priority. I always complain about how slow the web is turning as we age 😃 .
• Missing redirect helpers. I think this is common enough that it should be part of the core.

return conn
            .with_status(Status::PermanentRedirect)
            .with_header(KnownHeaderName::Location, "/blah")
            .halt();

• Being new to rust, I was struggling with getting state compile correctly when using it. Had to use to_owned(). It would be good to have a dedicated documentation page on State.

let state = conn.state::<AppState>().unwrap().to_owned();

• I like that KnownHeaderName is exposed. I don't know why most fwks don't expose it. Prevents lot of simple spelling mistakes. If possible I would also prefer some other well known values so that I stop searching online what they are but could be controversial too.
• Love the fact that HOST, PORT just works without me doing anything. I have always found it waste of time configuring this in every webapp I write. With trillium, I can just focus on the actual webapp logic.
• keep forgetting halt(). Need to get used to this. 😃

.halt()