sbstjn / appsync-resolvers

AWS AppSync Resolvers for GraphQL using AWS Lambda functions in Go.
https://sbstjn.com/serverless-graphql-with-appsync-and-lambda.html
MIT License
42 stars 13 forks source link

Nested type fields with arguments don't seem to work #9

Open acburdine opened 5 years ago

acburdine commented 5 years ago

Ran into this case with a graphql schema I'm currently working on and have racked my brain for a bit to think up a good solution. Thought I'd post an issue here to see if there's any ideas on how to solve this problem without creating a custom fork 😄

Say you have this GraphQL schema (not the schema I'm using, but it's enough to show the problem):

type Query {
  users: [User]
}

type User {
  id ID!
  name String!
  role(company: ID!): String!
}

type Role {
  id: ID!
  name: String!
}

The users field on the Query type returns a list of User types. However, the User type also has a role field that can take a company arg. Currently, the role field cannot be mapped to a lambda function using this library, which is due to (as best I can tell) these lines: https://github.com/sbstjn/appsync-resolvers/blob/master/invocation.go#L15-L25 . The payload function appears to only return either the Source field or the Arguments field exclusively, meaning that the role resolver wouldn't be able to access the company arg at all.

I could solve this by making a more custom appsync resolver, i.e.

{
  "version" : "2017-02-28",
  "operation": "Invoke",
  "payload": {
    "resolve": "query.users.role",
    "context": {
      "source": null,
      "arguments": $utils.toJson($context)
    }
  }
}

and then making my event structure parse out those properties, i.e.

type User struct {
  ID   string `json:"id"`
  Name string `json:"name"`
}

type roleArgs struct {
  Company string `json:"company"`
}

type event struct {
  Source    User     `json:"source"`
  Arguments roleArgs `json:"arguments"`
}

However, this does seem a bit more complicated than it needs to be, and I was wondering if there's a better way to solve combining the source & arguments together. I'm totally willing to work on implementing whatever solution is decided on (if any) 😄

matzhouse commented 5 years ago

Yeah I've just run into this!

I think it should always pass the arguments otherwise the above example of field arguments will never work and it's a pretty nice thing to be able to use. @sbstjn any thoughts?