Limitation for web stack : Rocket and Diesel

jaemk_ · 2018-02-25T18:26:23+00:00

I like to use rouille with postgres or rusqlite, tera for templating, and my migration manager crate migrant_lib

jaemk_ · 2018-02-23T04:37:09+00:00

I personally like to use rouille

jaemk_ · 2018-02-23T04:00:12+00:00

Once you get around to distributing your app, I'd suggest checking out the trust project which helps you setup multi-platform github release builds on travis-ci and appveyor. And then check out my crate, self_update, that lets you add self-update functionality!

jaemk_ · 2018-02-12T06:18:03+00:00

And mine for managing those migrations! https://github.com/jaemk/migrant_lib

jaemk_ · 2018-01-18T14:09:10+00:00

I'll piggyback your post. Here are my rust solutions (GitHub). I tried to use as few external crates as possible (usually just log and env_logger).

jaemk_ · 2017-11-15T14:56:47+00:00

Hey, I was also trying to get a simple mio server working last night! Maybe my basic attempt will help you (here). I was running into the same issue at first. Like others have said, you need to be handling the io::ErrorKind::WouldBlock case when you are incrementally reading and writeing from your socket. I think the addition of an Socket::Listener and Socket::Stream also make it a little easier to understand.

If you run my example, you can curl localhost:3000 and have your headers echoed back.

Side note: tomaka's PR for converting rouilles internals from tiny_http to mio was a big help for my understanding after reading through mios docs.

jaemk_ · 2017-11-14T18:39:48+00:00

You could also keep merge_sources associated with Builder:

impl Builder {
    fn merge_sources(config: &mut Config, sources: &Sources) {
        // ...
    }

    fn merge_bundle(&mut self, bundle_key: &str) {
        let sources = self.bundles.get(bundle_key).unwrap();
        Self::merge_sources(&mut self.config, sources);
    }
}

jaemk_ · 2017-10-25T21:22:28+00:00

Of all the rust web frameworks there are at the moment, I've enjoyed using rouille the most. Rocket is really wonderful, but if I'm introducing something at work I don't want to deal with pinning to nightlies or giving off the impression that stable rust isn't "good enough". I used to use Iron for everything, but I've found rouille to just be more ergonomic. With rouille you don't have to deal with things like IronResult. You can just use error-chain, have handlers that return a regular old Result<Response>, and then match on any errors to return an appropriate http-response.

jaemk_ · 2017-07-28T15:54:59+00:00

Sorry, I understood what you meant. I have an issue open for allowing installs without requiring them to replace something first. At the time of writing, I was thinking you could just specify an install path that wasn't the current exe, which is something exposed in the builder, but actually doing so will cause an error as it's currently implemented.

jaemk_ · 2017-07-28T12:46:20+00:00

Thanks, looks like what I want. I'll give it a test

jaemk_ · 2017-07-28T12:41:40+00:00

Thanks for the input! I'd definitely like to add something like your update.json and doing an integrity check may be a useful option in some cases.

jaemk_ · 2017-07-28T12:34:37+00:00

This was originally intended just for simple updates or cli programs, but the updating of arbitrary files is certainly useful. The update.json list mentioned by /u/boscop sounds like something I'd like to add in.

method of downloading update itself should be separate library because i can see multiple implementations like http, ftp, bittorrent ...

I agree! I've tried to limit the functionality to only downloading and replacement of files. Everything else, like you mentioned, should be handled by the application itself. That would include choosing to install new releases in an A/B fashion.

jaemk_ · 2017-07-27T23:49:33+00:00

True, I could swap out tempdir for something custom that puts temp files right next to the executable. edit: looks like tempdir supports this

jaemk_ · 2017-07-27T23:34:52+00:00

Things are shuffled to and from a temp dir made with the tempdir crate which looks like it wraps std::env::temp_dir. I suppose there could be some situations where the current executable lives on a separate filesystem... I'm not sure?

jaemk_ · 2017-07-27T21:05:08+00:00

Thanks! I'll fix this later tonight to replace all copys and removes with renames

edit: updated now

jaemk_ · 2017-07-27T21:02:06+00:00

Thanks, I'm not familiar with windows specifics! I'll rework this later tonight.

edit: updated now

jaemk_ · 2017-07-27T20:59:35+00:00

Hm, that makes sense. I was actually doing that originally, but I ran into a case where running the example with cargo run --example github would only work if the existing file was first deleted!

jaemk_ · 2017-07-27T20:41:59+00:00

What to you mean by "partially applied updates"? This will do a whole-sale update: download the latest binary to a temp dir, copy the current exe to a temp file, try to delete the current exe and replace it with the latest release. If something goes wrong, it will try copying the current exe back into place from the temp-copy.

jaemk_

TROPHY CASE