Continue resolving fields returned from @lamdba queries

Does Dgraph continue resolving fields on types returned from Lamdba queries?

If I have a simple schema:

type Author {
    name: String!
    posts: [Post] @hasInverse(field: author)
}

type Post {
    title: String!
    content: String!
    author: Author
}

Query {
    mySpecialAuthorQuery(...): [Author] @lambda
}

When I implement mySpecialAuthorQuery as a resolver, can I return a list of uids of Authors and have Dgraph look up the right fields, including nested child fields, to match the shape of field selection provided by the caller?

I saw this post: Returning dgraph types from lambda resolvers but there’s no clear conclusion as to whether this is possible now, being worked on, or on the roadmap.

@rcbevans try not to use the doc category. If you have questions always use Issues instead.

When you click ‘ask a question’ on the doc page, it brings you to discuss.dgraph with the documentation filter applied, such that when you click new topic it defaults to the documentation category. If you don’t want people to use that category, then I suggest you change the behavior of “ask a question” (which is how I created these lambda auth/related questions).

You can do whatever you want inside the lambda. Once you have the information you want to return, simply return it. I can’t speak for Dgraph automatically looking up uids, but you should be able to look them up in the lambda and return the values you want (provided you have matching types).

You can’t have more than one of the same type if you have more than one custom query (as it would be the same value), but I don’t see any other issues.

I assume you want it to return properly to update your cache correctly in urql or graphql.

J

Clearly; but that isn’t what I’m asking. If I want my lamdba to resolve the fields requested as a response, I need to write my own nested resolver within the lamdba which I don’t want to have to do when Dgraph is already capable of doing that.

Whether I’m writing a query or mutation lamdba, I am trying to do something specific otherwise not possible from the generated GraphQL, if I also have to implement my own recursive resolvers within every lambda then the value of lamdbas fast tends to zero vs using Dgraph as a traditional database using DQL from my backend, implementing the client facing GraphQL there.