Rust 1.39.0 and Async/Await about canduma

[shirshak55]

std::future has been merged to actix-web

https://twitter.com/fafhrd91/status/1197481330277306369

[s-ted]

You may want to look at my attempt on this : https://github.com/s-ted/canduma-async

As I also made a few core conception changes (mostly on routing, argument passing and error management) I did not send a PR.

But all the functionalities of canduma have been migrated as async/await (i.e actix-web v2).

[s-ted]

Hi there ! I didn't think this would bring such an enthusiasm 😊
I made the #19 PR, trying to explain my coding standard / decision in it as comments.

Feel free to question my decisions in the PR ;)

As for the authentication stuff in REST instead of graphql, I personaly see graphql as a good way to make "business" actions and see "business entities", but I feel authentication is more of a non-business stuff, which should be kept as a REST service, allowing non-graphql potential services (i.e. other REST services) to use it in addition to graphql.
Basically, I think that if your frontend / API consumer is graphql mature, it should be a easy for it to make the REST authentication, the opposite being not so true.

[shirshak55]

@clifinger I think we should not use tokio and use async std. At least people who knows std library can easily use async std.

[shirshak55]

@clifinger I am waiting for ecosystem to be abit stable so lets start once that is done.

[shirshak55]

@espnicholas
hmm the problem is actix don't support async await yet?

[clifinger]

@espnicholas I will keep this issue open ... I just want to write the tests first and find a better way to deal with databases. About now we should implement block to deal with Diesel sync req. I really don't know what to do/what to choose because the challenge with Canduma is to be "a framework on top of actix" with some generators (canduma console).

[espnicholas]

@shirshak55

Yeah, this is more to track against since eventually the majority of projects and crates will make a shift towards the newer syntax.

@clifinger

• Database and Diesel - Yeah that makes sense, i'll take sometime to think about it a bit.
• Actix - Agree that is the right approach. For the project overall, I know it is seen a micro-architecture for authentication but is there a desire to become more of an opinionated framework on-top of actix?

[espnicholas]

Adding actix/actix-net#45 as a reference since this is apart of the move within Actix to async/await. I believe this work is being primarily tracked within the ticket #45 and the branch https://github.com/actix/actix-net/tree/std-future.

[shirshak55]

@espnicholas I don't think async await will be released anytime soon in actix .

[clifinger]

Hello @espnicholas and @shirshak55,

At first I read about https://github.com/rust-db/barrel to have migrations, https://docs.rs/postgres-types/0.1.0-alpha.1/postgres_types/ and https://docs.rs/tokio-postgres/0.5.0-alpha.1/tokio_postgres . What do you think about using this stack? I think it can be a good help for them since they are in alpha to have return of exp and maybe some PR from us.

@espnicholas about your question : Yes, I dream about a framework on-top of actix to easily make micro-services. I even want to tests our framework by deploying it on kubernetes (google).

[clifinger]

@shirshak55 so the question is "can we adapt it" to use std?

[espnicholas]

@shirshak55 Yep, and looks like the examples on actix-web have been updated to async. https://github.com/actix/actix-web/blob/master/examples/basic.rs

[shirshak55]

@s-ted looks cool :)

By the way shouldn't login logout and me should be done over graphql?

ik current implementation don't do it tho.

[clifinger]

@s-ted good job ! can you do a PR ?
@shirshak55 I think it's better to separate the "security" from data exposing as he did, what do you think?

[clifinger]

BTW @s-ted
I contacted you on linked-in for private reason, because I am from Grenoble, France :)

[shirshak55]

@clifinger I think it's better to separate the "security" from data exposing as he did? Hmm can u please elaborate I don't think there is any security issue as we can use middleware from graphql context.?

[clifinger]

@shirshak55 I don't speak about security but more about architecture, especially for micro-services.
Ex. Should we really call an API for the session in the web-app?

If you consume data from another "security" API in your GraphQl, how to send back the session?

But no best choice, both can be used, I just prefer separate authentication from authorization and keep the API working with authorization part only as authentication can handle multiple req/res not always related to the API.

[shirshak55]

@clifinger I am not getting it . Is there any difference between using graphql over rest api? Its same right as session token is going to be stored in redis?

By the way are we using authorization here? I think we are only doing authentication right?

Thanks.

[clifinger]

@shirshak55 once again, there are no good or bad solutions in my opinion. Just that GraphQL does not support reverse proxy in general. Sorry for the confusing session and session cookies! Also, I do not call a simple request for authentication an API rest. For authorizations, this is a feature to come. Fell free to PR :P

[clifinger]

Thank you so much @s-ted ... Merci beaucoup !