
Rocket, Rust Web Framework, v0.2: Managed State and More - sbenitez
https://rocket.rs/news/2017-02-06-version-0.2/
======
eknkc
Just curious, I really want to like Rust but take a look at the State API
documentation for managed state feature:
[https://api.rocket.rs/rocket/struct.State.html](https://api.rocket.rs/rocket/struct.State.html)
(screenshot: [http://c.ekin.io/3c2q112x1p0y](http://c.ekin.io/3c2q112x1p0y))

Is this readable to Rust people? I mean, can you look at this and say, "ah ok,
I'm gonna call this and that then I'll have the state" directly?

I'm lost but I have zero Rust knowledge so this is a sincere question, does
this mess make sense when you get into it?

~~~
IshKebab
It _is_ readable, but you are right it is terribly formatted with a lot of
not-very-important information in huge fonts.

I think rustdoc needs quite a lot of work in general. For example it doesn't
even give a list of methods at the start of each type's page. Want to know
which methods you can call on a `String`? Enjoy scrolling...

[https://doc.rust-lang.org/std/string/struct.String.html](https://doc.rust-
lang.org/std/string/struct.String.html)

~~~
vvanders
The +/\- button will do that for you. It's one of the first things I do once I
read the top example.

~~~
steveklabnik
We've discussed flipping the defaults; it was decided before I started writing
so many docs and examples. Very different today!

~~~
riquito
Maybe you could add a responsive right bar with the list of methods, visible
when the screen is large enough. My 24'' monitor has 30% wasted space right
now.

~~~
steveklabnik
Yes, something like this would be very useful too.

------
oregontechninja
I've been using the framework to practice rust and it's really pleasant. I
would compare this to "flask" from Python. I've got an experimental static
site cms (for my clients eventually) where the administration back end is a
dynamic library so I can update the back-end without stopping the serving of
the website to the public. Really fun learning experiment and crazy fast
server overall. For now, I still use Go, but Rust's meta features are so much
more advanced that I'm working on switching.

------
Daishiman
I have to say, the end user API for Rocket is pretty nice.

But _damn_ , there's a _lot_ of compiler magic in order to simplify the
request and response signatures.

It would be great to see more documentation on how to deal with naked
Request/Response objects that can be constructed by hand. I'd love to use
Rocket to develop some API on top of it, but that means I want more access to
the underlying objects below.

------
moosingin3space
I'm very excited about this. I've been looking for a good open-source
statically-typed web stack for a long time, and the Rust community delivered.

Now, when this works on stable, it'll be awesome!

------
juancampa
I'm curious what's the difference between Managed State and good old
Dependency Injection. Is it just a naming difference? In that case, why?
People already know what DI is.

~~~
yawgmoth
While I could see that this implementation of Managed State is an example of
DI, the opposite is not true.

------
danaliv
I tried to build a simple Rust "hello world" \+ database web app the other day
( _edit:_ not with Rocket) and after four hours I had nothing to show for it.
I had a simple static app in just a few minutes, but I could not for the life
of me figure out how to maintain state like a database connection pool and
make it available to request handlers in any sane and maintainable way. (There
are ways to do it insanely and unmaintainably for sure.) Has anyone else had
this experience?

~~~
sbenitez
Thanks for trying out Rocket! There are a couple of examples in Rocket's
repository that illustrate how to use Rocket with a database. The more
complete of the two is the todo example [0]. This uses Diesel as its ORM
alongside managed state to maintain a pool of database connections. The second
example of the two uses raw SQLite without a connection pool [1]. It's meant
to be a bare bones illustration of using a database with Rocket.

Managed state is a feature specifically designed to help with this kind of
thing. That being said, I still think Rocket can do more to abstract away
database connections. I'm tracking improvements on this front in GitHub issue
#167 [2].

[0]:
[https://github.com/SergioBenitez/Rocket/tree/master/examples...](https://github.com/SergioBenitez/Rocket/tree/master/examples/todo)

[1]:
[https://github.com/SergioBenitez/Rocket/blob/master/examples...](https://github.com/SergioBenitez/Rocket/blob/master/examples/raw_sqlite)

[2]:
[https://github.com/SergioBenitez/Rocket/issues/167](https://github.com/SergioBenitez/Rocket/issues/167)

~~~
danaliv
Thanks so much for the helpful reply! I should've noted that I haven't
actually tried Rocket. :) It was a couple other frameworks that I'd played
with, all of which seemed to go _shrug, not our concern_ when the question of
managed state came up. I'll give Rocket a try and see if I have better luck.

------
azdle
If there's anyone here with experience using both Rocket and Iron, would you
be willing to share your thoughts on the differences between them?

I've got an API server started in Iron, but I have to say the claims of
productivity and less code overhead that Rocket is proclaiming seem pretty
nice right about now.

------
mattrb
Does Rocket have subdomain support? I didn't see it in the documentation.

------
fanyer
Seems good. I'll taste it

------
rshm
Still without ssl. Nice to see lots of stars and forks.

~~~
nilved
SSL is really not the responsibility of the web framework.

~~~
k__
Are reverse proxies always the way to go?

~~~
dozzie
No. Usually web application would be exposed through FastCGI or similar
protocol.

Insisting that either your tiny web application that can do next to nothing is
the thing that owns 80/tcp (and/or 443/tcp) or runs behind a HTTP proxy is
stupid. Proxying HTTP requests _properly_ is harder than it sounds, which is
surprising every now and then and thus is easy to screw up (what happens to
_Host:_ header? who is the TCP client? is it HTTP or HTTPs?), and your tiny
web application, as I've called it, is not the only thing I want to host on
the machine.

~~~
RussianCow
Practically every company I've worked with uses an HTTP reverse proxy. When
you use something like nginx, it's really not hard at all to get right.
Support for HTTP is more widespread than support for FastCGI these days,
especially with more obscure tech stacks.

Edit: You can run multiple apps on separate ports, so that shouldn't be an
issue.

~~~
dozzie
> Practically every company I've worked with uses an HTTP reverse proxy.

Well, there are people who can say the same about Node.js or RoR. Not that it
makes a majority.

> When you use something like nginx, it's really not hard at all to get right.

It's not a matter of nginx. It's a matter of what assumptions are hardcoded in
the application.

> Edit: You can run multiple apps on separate ports, so that shouldn't be an
> issue.

Of course it is an issue. Such a deployment looks terrible at best.

~~~
RussianCow
> It's not a matter of nginx. It's a matter of what assumptions are hardcoded
> in the application.

You haven't actually given any good examples for what makes HTTP reverse
proxying bad. Things like dealing with the Host header are two-minute fixes
that you only have to deal with once, but they really shouldn't even be issues
in the first place. HTTP is well supported, well understood, easy to
implement, and easy to scale. On the flip side, you might waste a lot of time
trying to get your tech stack working with FastCGI if there isn't already
existing support, and you don't benefit from any HTTP support you already
have.

> Such a deployment looks terrible at best.

Again, "looks terrible" is not a valid argument against it.

~~~
dozzie
> You haven't actually given any good examples for what makes HTTP reverse
> proxying bad.

Try running anything that generates absolute URLs in its HTML. And then try to
make it running under two different domains, for example. A clear cookie/URL
disaster, and it's all for web protocols from 2002, without talking about HSTS
or CORS yet.

> Things like dealing with the Host header are two-minute fixes that you only
> have to deal with once,

For _every f &ckin' application_.

> but they really shouldn't even be issues in the first place.

They shouldn't be, I agree, in that sense that it should be impossible to get
it wrong. With HTTP you don't have this and you need to deploy workarounds.

> On the flip side, you might waste a lot of time trying to get your tech
> stack working with FastCGI if there isn't already existing support,

Node.js _may_ be the only offender here (I didn't bother to check). Virtually
everything else that is used for web applications supports FastCGI.

> and you don't benefit from any HTTP support you already have.

Like what? What exactly is the benefit of running HTTP between frontend HTTP
server and application's backend? Because the trouble with passing information
about the request is a clear downside.

>> Such a deployment looks terrible at best.

> Again, "looks terrible" is not a valid argument against it.

Oh, quite the contrary. Inelegant systems or deployments usually give a death
by a thousand cuts. Too many exceptions and rules and guesses to work with
them.

Just as we can judge the elegance of source code, we can judge the elegance of
deployments.

~~~
e12e
> What exactly is the benefit of running HTTP between frontend HTTP server and
> application's backend?

For some applications (those that fit within the constraints of REST - and,
no, that's not all Web "apps") - you can sometimes get easy caching by
dropping something like varnish somewhere between the user and the app.

------
onmobiletemp
Keep it up sergio!

