Rocket, Rust Web Framework, v0.2: Managed State and More
31–40 of 62 posts
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#32I 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 unm…
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...
[1]: https://github.com/SergioBenitez/Rocket/blob/master/examples...
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#33I 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 unm…
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 data…
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#34Just 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 (screenshot: 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…
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
It does. Honestly, it's quite hard to contribute to at the moment. This is going to improve in the very near future; there's a PR in the queue that's the start of the ability to start making it easier. I hope to make it vastly so someday in the future. Always so much work to do...
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#35Earlier quoted context omitted.
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 clie…
Interesting. I only met FastCGI in PHP. All NodeJS apps I saw used HTTP. Is there any benefit of doing it that way? How does it work with WebSockets?
And I met FastCGI in Python, Perl, Ruby, and Erlang (though I haven't used the last one yet). Oh, and uWSGI can expose anything it runs through FastCGI.
My personal opinion is that web crowd (most of JavaScript programmers fall in here) just doesn't want to learn from anybody else.
> Is there any benefit of doing it that way?
Compared to running the tiny web application on 80/tcp? Sure: I can run more than one and I don't need root privileges for the application.
Compared to running the application behind a reverse proxy? Ditto: it's virtually impossible to get the setup wrong, so it's easier in the long run.
> How does it work with WebSockets?
No idea. I don't develop web applications.
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#36Earlier quoted context omitted.
Are reverse proxies always the way to go?
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 clie…
Edit: You can run multiple apps on separate ports, so that shouldn't be an issue.
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#37Earlier quoted context omitted.
Interesting. I only met FastCGI in PHP. All NodeJS apps I saw used HTTP. Is there any benefit of doing it that way? How does it work with WebSockets?
> I only met FastCGI in PHP. All NodeJS apps I saw used HTTP. And I met FastCGI in Python, Perl, Ruby, and Erlang (though I haven't used the last one yet). Oh, and uWSGI can expose anything it runs through FastCGI. My personal opinion is that web crowd (most of JavaScript programmers fall in here) just doesn't want to learn from anybody else. > Is there any benefit of doing it that way? Compared to running the tiny w…
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#38Just 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 (screenshot: 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…
A bit more summary of available methods/trait impls somewhere would be nice.
I'd appreciate a three scrollable pane setup, first pane similar to whats already there on the left, but always visible. Second pane type, usage, examples, methods, impls. Third pane in the middle, widest, actual information in long form. Inline examples of each method are incredibly helpful and the std library docs have quite a few of those but not always. Its sometimes hard to understand how to use a method or type or impl depending on its signature.
Panes should scroll+highlight currently viewed items in the actual doc (third) pane.
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#39Earlier quoted context omitted.
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 clie…
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.
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.
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#40I 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 unm…
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 data…