Minor nitpick:<p>> Immutability (const) by default<p>The author clearly knows this, but others may not, so: immutability and "const" aren't the same thing. Const typically prevents name rebinding (as the type system permits). Immutability is the presumption that the whole data structure can't be mutated by default (though there are usually ways to mutate cheaply--without bulk copying, that is--provided by most immutable data APIs).<p>Const works like this:<p><pre><code> not_const int[] foo = [123, 456]
const int[] bar = [456,789]
foo = [1,2,3] // no problem; rebinding is allowed if it meets the 'int' type constraint.
bar = [1,2,3] // compile error!
</code></pre>
Immutability, <i>as typically defined</i> (there's a bit of a semantic debate here sometimes) prevents changes to the contents of complex data structures:<p><pre><code> mut int[] foo = [123, 456]
not_mut int[] bar = [456,789]
foo[0] = 789 // no problem; mutation is allowed so long as it's with valid types.
bar[0] = 123 // compile error!
</code></pre>
Edit: missed a space.
<i>With microservice, I mean an application that speaks HTTP, accepts requests, speaks to a database, returns a response (possibly serving HTML), packaged up in a Docker container and ready to be dropped somewhere in the cloud.</i><p>Huh? That's a CRUD app. A "microservice" is a service which is a component of a larger service. Usually a service run by the same organization. Many microservices don't speak HTTP; they use Google protocol buffers or something similarly efficient. Serving a Facebook page involves about a hundred microservices, and they don't talk HTTP to each other.
I'm waiting for the service to be a bit more consistent to blog about it, but we've started with a friend to write a webservice in rocket and it's been a total pleasure<p>It may be useful to some people, as we've most of the feature you find in a "real life" service<p><pre><code> * database connection
* schema creation
* json handling
* pagination
* some endpoints are non-json
* support for CORS
* automated isolation test (i.e we test the service as a blackbox)
* generation of a minimal bin-only docker image that with travis-ci
* self-contained dev environment (vagrant up and you're good to go)
</code></pre>
<a href="https://github.com/allan-simon/sentence-aligner-rust" rel="nofollow">https://github.com/allan-simon/sentence-aligner-rust</a>
Strikes me as having quite a big cognitive overhead.
I wouldn't try using this in unless being cornered by performance considerations or wanting a pure rust software architecture.
I made a very simple web service with Rocket (see <a href="https://github.com/MrBuddyCasino/alexa-auth" rel="nofollow">https://github.com/MrBuddyCasino/alexa-auth</a>), which is better but still - I‘d go for Kotlin or Go instead if performance requirements allow it.
I haver been looking at Rust as a replacement for a c microserver I made,<p>I have a thing that listens as root and serves as a user dictated by their id.<p>so it's<p><pre><code> as root:
on connect fork:
forked process:
read request to determine ID
drop privileges to UID and GID of ID
process request
</code></pre>
Because of the root component I want it to do as little as possible while being root, which c is good for. but it's also probably riddled with holes, only some of which I am aware.
Shouldn't RUST_LOG use "microservice_rs" instead of "microservice"? the "_rs" is a crate name.<p>Another thing, in a make_post_response stub function I think it's better to use StatusCode::NotImplemented instead of NotFound (when trying this code I thought the match did not work correctly as everything returned NotFound).
Diesel is a synchronous library, so the post's database functions make a blocking call and then return a future which, of course, doesn't make them asynchronous. They'd still block the event loop.<p>You could fix this by passing a `&futures_cpupool::CpuPool` into your database functions and wrapping the post's function bodies in `pool.spawn_fn(|| { ... })` so that they execute on a different thread and return a future of their result.<p>To have a global IO pool that you pass into fns, you can store it in the Service struct:<p><pre><code> struct Microservice { io_pool: CpuPool }
</code></pre>
Now you can access it in your service's handler (the call() fn) with `self.io_pool`.