Kai Ren

@mrtnzlml nice, so we'll have it with the next spec release!

@jmpunkt @zhenwenc @Victor-Savu I was thinking about this issue too for quite a while, and here is something to share... I've thought about the following design: ```rust #[derive(GraphQLObject)] // bool...

@jmpunkt > To get this clear, we would implement similar functionality (as in inventory) for our registry? Such that we can use the declarative macros for our registry? No. `inventory`...

@jmpunkt I've read the discussion and I'm a bit more convinced to allow resolvers without `&self`. Things like > Therefore, introducing a `&self` makes it clear that the function requires...

@zhenwenc > if I understand correctly, we can generate a dummy struct for each field (eg: __juniper_Obj_fullName), similar to the markers This can be a struct too, but I see...

@allancalix we're not against this, go ahead! Regarding the solution, I don't see reasons to move the validation into a separate crate. But making a nice public API for using...

@morganmsrn > I would like a solution where the solution mentioned in the book work with a generic result type Well that just won't work because of GraphQL type system...

> Your use case seems to be dealing with a synchronous database connection? You can't use those anyway in a async environment, since you are not supposed to block a...

> The only benefit would be allowing multiple requests to make progress on the same thread That's exactly the point. > but I don't think that makes sense any sense...

> The error message indicates that it is actually your resolver that relies on something that is !Send. Yes. Our DB interaction layer provides `!Send` interface as uses a lot...