Interface implementation based on trait about async-graphql

[phated]

Excited to see this! Please let me know if I can help in any way

[sunli829]

I tried it and it worked.

Here is the new interface definition.

#[Interface]
trait Node: Send + Sync {
    async fn id(&self) -> i32;
}

struct MyObj;

#[Implement]
impl Node for MyObj {
    async fn id(&self) -> i32 {
       10
    }
}

#[Object]
impl MyObj {
    async fn value(&self) -> i32 {
        20
    }
}

struct Query;

#[Object]
impl Query {
    async fn my_obj(&self) -> NodeInterface<MyObj> {
         // !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
         // NodeInterface is generated automatically, which may cause the auto-completion of the ide to fail.
         MyObj.into()
    }
}

The following is a query that can be executed correctly.

{
    id
    ... on Node {
         id1: id
    }
    ... on MyObj {
         value 
    }
}

[sunli829]

Trait object are the only way to solve this problem, but I don't have a computer right now, so I'll think about it later.

[phated]

Wow! This looks great!!!!!

[sunli829]

I couldn't implement such a feature because lose the type information if converted to a trait object.😭

#[Object]
impl Query {
    async fn my_obj(&self) -> Vec<NodeInterface<???>> {
         vec![MyObjA.into(), MyObjB.into()]
    }
}

[nicolaiunrein]

I suppose NodeInterface is a struct?
I don’t think this compiles but wouldn’t that be the correct signature?

#[Object]
impl Query {
    async fn my_obj(&self) -> Vec<NodeInterface<dyn Node>> {
         vec![MyObjA.into(), MyObjB.into()]
    }
}

[sunli829]

I need to think again about whether this generic parameter is really necessary.

[phated]

And we are unable able to do this?

struct Query;

#[Object]
impl Query {
    async fn my_obj(&self) -> impl Node  {
         MyObj{}
    }
}

https://doc.rust-lang.org/edition-guide/rust-2018/trait-system/impl-trait-for-returning-complex-types-with-ease.html

[sunli829]

No, this is just type MyObj, which is missing the interface information, so need a wrapper.

[nicolaiunrein]

Correct me if I’m wrong but I think under the hood impl Query gets converted to a trait? and returning impl Trait is not supported on trait methods.

But what about utilising the flatten attribute inside the generated Interface somehow to inline existing fields?

[phated]

No, this is just type MyObj, which is missing the interface information, so need a wrapper.

If you impl Node for MyObj, why would it not fulfill the trait implementation type signature?

[sunli829]

Cannot use a trait object, which is a run-time type, and generate Schema requires static type.
So let's go back to #38, is it worth sacrificing a little type safety for more flexible interface definitions?

[sunli829]

The generic list should solve all the problems. I'm still thinking about it.

[sunli829]

This is impossible, so I'm going to close it right now.

[sunli829]

I think #38 is the best solution, removing many of the limitations of function forwarding and making it easy to use. Panic at startup is acceptable.

[phated]

I discussed this at my presentation and everyone wanted static type checking. It takes a long time to start up the server to see that you made a mistake.

[sunli829]

Let's keep the original design the same.😂

[sunli829]

I'll try again.