Build a larger example app about tide HOT 18 CLOSED

https://realworld.io/ is a nice "standard" example app that might be nice to try implement. It looks like the backend is API only, so doesn't demonstrate real templating though. Maybe could be in addition to a more "self contained" example app.

I'd be interested in having a go.

from tide.

Some things to demonstrate:

• Accessing a database, perhaps using Diesel
• Using real templating
• Authentication
• Session management

Some typical example apps people like to see:

• A todo list app
• A blog, complete with comments

from tide.

I've made a super rough start https://github.com/colinbankier/realworld-tide
It ain't pretty and it doesn't do much yet, just a skeleton to hook up diesel with tide to get going. TBC.

from tide.

@DeltaManiac - yep, I saw a couple of rust attempts - one with Rocket too. I'm using them as hints to get a first step up and running :).

from tide.

Although going very slowly due to other commitments etc, the "realworld" api example (https://github.com/colinbankier/realworld-tide) is slowly moving forward. Although very incomplete and rough around the edges, it's hopefully at a point where it has some interesting things and where others could help improve / extend it further if they so wished.
Things it aims to do so far:

• Async queries with diesel. Diesel doesn't directly support async, but we can still build an async application around it using tokio_threadpool::blocking. The db module provides a Repo abstraction to encapsulate this.
• Parallel database tests. Tests use isolated test transactions so database tests can be run in parallel.
• HTTP level integration tests for the web layer. The test_helpers module provides a TestServer to easily simulate http requests for tests.
• Separate domain logic from web logic. The conduit module contains domain logic and the web module has logic for dealing with http stuff and json request/response formats.

Happy to get any suggestions, issues, PRs, etc.

from tide.

@colinbankier looking very cool!

from tide.

from tide.

is there a benefit to using the diesel pool as an async function?

@petejodo - I assume you mean using diesel "as normal" without using tokio_threadpool::blocking?
The issue is that the db call will block the tokio reactor from handling other requests on that thread, severely limiting the ability to handle concurrent requests. Wrapping this in blocking allows tokio to not block the reactor.

from tide.

@colinbankier That sounds fantastic -- please do! Feel free to reach out on this issue or the #wg-net-web channel on Discord for questions/discussion as well.

from tide.

Well there is already a Rust implementation with Hyper+Diesel
@colinbankier this could help us out too :)

from tide.

@colinbankier It seems that this example is using synchronous database requests. I think this will need to be changed (either to an async database client, or to use a thread pool). Otherwise it completely defeats the point of using futures and tokio for async request handling.

Sorry my comment can't be more constructive, but this is exactly the thing I've struggled to implement in Rust web apps, so I'm afraid I can't suggest a concrete path forwards.

from tide.

Thanks @nicoburns - never fear, handling this better is in the plan :) It's part of the "it ain't pretty yet" qualification. I don't expect it to be a particularly useful example yet...but wanted to share the starting point as a placeholder.

My current plan is to use a thread pool, as I don't believe diesel supports actual async clients yet. If this is not true, please let me know.

from tide.

@colinbankier is there a benefit to using the diesel pool as an async function? I have it working without doing that so I just want to make sure I'm not missing anything. I know it's blocking, but I figure it's within the async endpoint fn so it doesn't matter if it's blocking for that call but I don't actually know

from tide.

separately, a couple of comments about what I've run into in my own playground:

• had to implement my own Json type which implements Extract in order to map deserialization errors to a normalized error response. This way the caller gets some feedback about why the call failed rather than just a BadRequest.
• still playing with it but have been running into trouble trying to come up with a nice way to do normalized responses e.g. jsonapi/something like this:

{
    "data": {
        "id": 123,
        "type": "user",
        "attributes": { },
        "relationships": { }
    }
}

from tide.

Ohh I see where my confusion was, thinking that the async endpoint was it's own thread, d'oh. Yeah that makes total sense, thanks!

from tide.

While Colin seems to be making good progress with commits as recent as last month, I'd also like to give this a go. I think two beefier examples can't hurt, and I am new to Tide so at worst case this will be a great learning exercise for me.

I am coming from a Java world (since JDK 1.1.4), so when I saw a need for a beefier example I thought of the Java Pet Store. My thought is to create a Rust Cattle Ranch, different from the Pet Store but with similar demonstrated capabilities.

Skeleton Github repository is up, at https://github.com/BillBarnhill/RustCattleRanch.

from tide.

@BillBarnhill You may want to check out the other example apps at https://github.com/http-rs/tide#example-applications

from tide.

Given we have several example apps now I think we can close this.

from tide.