# Slash Lambda Fields addGraphQLResolver missing args

**URL:** <https://discuss.dgraph.io/t/slash-lambda-fields-addgraphqlresolver-missing-args/12302>\
**Category:** GraphQL\
**Tags:** kind:enhancement, status:accepted, ticket:created, lambda\
**Created:** [January 14, 2021, 7:24pm UTC](https://discuss.dgraph.io/t/slash-lambda-fields-addgraphqlresolver-missing-args/12302 "2021-01-14T19:24:23Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![amaster507](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/amaster507/32/4123_2.png) [@amaster507](https://discuss.dgraph.io/u/amaster507)\
**Post date:** [January 14, 2021, 7:24pm UTC](https://discuss.dgraph.io/t/slash-lambda-fields-addgraphqlresolver-missing-args/12302/1 "2021-01-14T19:24:24Z")

</div>

# Overview

Starting to think more with what all we can do with the power of Lambda!! 🥳 Wohoo!! Ummm… ☹ maybe.

Concept: With lambda Field resolver we can do just about anything we want inside a javascript resolver when that field is called and return whatever type we define in our schema. one of the available arguments from the props in the resolving function is `args`. So in theory, we can pass `args` from a query to a resolving lambda script. Let’s try it… _Nope, Doesn’t Work._

I expect that either the `args` would equal the input from the field or the input from the root query. What I found is that `args` is an empty object `{}` no matter how I try to pass `args`.

I believe I am seeing 2 issues (args not passed, JWT not passed). This topic is only for the first issue of no args. I will open another based on this for JWT not being passed.

# Steps to Reproduce:

## Schema:

```auto
type Contact {
  id: ID
  name: String
  fromAPI: String
  syncAPI(input: String): String @lambda
}

```

## Lambda:

```auto
async function syncAPI(props) {
  return JSON.stringify(props)
}

self.addGraphQLResolvers({
  "Contact.syncAPI": syncAPI
})

```

## Add a User

```auto
mutation {
  addContact(input: [{
    name: "Foo"
  }]) {
    numUids
    contact {
      id
      name
      fromAPI
    }
  }
}

```

results:

```auto
{
  "data": {
    "addContact": {
      "numUids": 1,
      "contact": [
        {
          "id": "0x4",
          "name": "Foo",
          "fromAPI": null
        }
      ]
    }
  },
  "extensions": {
    "touched_uids": 7,
    "tracing": {
      "version": 1,
      "startTime": "2021-01-14T18:57:36.504098158Z",
      "endTime": "2021-01-14T18:57:36.509134348Z",
      "duration": 5036194,
      "execution": {
        "resolvers": [
          {
            "path": [
              "addContact"
            ],
            "parentType": "Mutation",
            "fieldName": "addContact",
            "returnType": "AddContactPayload",
            "startOffset": 115110,
            "duration": 4894812,
            "dgraph": [
              {
                "label": "mutation",
                "startOffset": 176368,
                "duration": 2436394
              },
              {
                "label": "query",
                "startOffset": 3641973,
                "duration": 1339675
              }
            ]
          }
        ]
      }
    }
  }
}

```

## Query for Contacts

```auto
query {
  queryContact(first: 10) {
    id
    name
    fromAPI
    syncAPI(input: "bar")
  }
}

```

results

```auto
{
  "data": {
    "queryContact": [
      {
        "id": "0x4",
        "name": "Foo",
        "fromAPI": null,
        "syncAPI": "{\"isTrusted\":false,\"parents\":[{\"id\":\"0x4\",\"name\":\"Foo\"}],\"args\":{},\"dql\":{},\"parent\":{\"id\":\"0x4\",\"name\":\"Foo\"}}"
      }
    ]
  },
  "extensions": {
    "touched_uids": 3,
    "tracing": {
      "version": 1,
      "startTime": "2021-01-14T19:10:03.827410948Z",
      "endTime": "2021-01-14T19:10:03.845784571Z",
      "duration": 18373658,
      "execution": {
        "resolvers": [
          {
            "path": [
              "queryContact"
            ],
            "parentType": "Query",
            "fieldName": "queryContact",
            "returnType": "[Contact]",
            "startOffset": 89797,
            "duration": 18237001,
            "dgraph": [
              {
                "label": "query",
                "startOffset": 179257,
                "duration": 1563767
              }
            ]
          }
        ]
      }
    }
  }
}

```

Here is this: @pbassham

---

<div class="post-metadata">

**Author:** ![amaster507](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/amaster507/32/4123_2.png) [@amaster507](https://discuss.dgraph.io/u/amaster507)\
**Post date:** [January 14, 2021, 8:28pm UTC](https://discuss.dgraph.io/t/slash-lambda-fields-addgraphqlresolver-missing-args/12302/2 "2021-01-14T20:28:16Z")

</div>

To update, after moving this to a Lambda Mutation, the `args` for the parent mutation do come through. But we also need `args` from a Lambda Field resolver.

---

<div class="post-metadata">

**Author:** ![amaster507](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/amaster507/32/4123_2.png) [@amaster507](https://discuss.dgraph.io/u/amaster507)\
**Post date:** [January 22, 2021, 7:39pm UTC](https://discuss.dgraph.io/t/slash-lambda-fields-addgraphqlresolver-missing-args/12302/3 "2021-01-22T19:39:24Z")

</div>

> [@Overview - Graphql](http://discuss.hypermode.com/t/overview-graphql/11951/2):
>
> Is it possible to recieve args in myType? It doesnt seem to be working for me. The Example given doesnt have it But what I would like to do is: type MyType { ... customField(args:String) String @lambda } So that I can query like: queryMyType { customField(args: $args) }

> [@Overview - Graphql](http://discuss.hypermode.com/t/overview-graphql/11951/3):
>
> No, `args` work for `@custom/@lambda` query/mutation at present.
> 
> `@custom/@lambda` fields in types get only `parents`.

This is a feature request now instead of a bug, I just assumed this was already implemented from previous discussions around passing arguments into pre/post “hooks” for which lambda was developed.

> [@Implement custom JS resolvers in GraphQL](http://discuss.hypermode.com/t/implement-custom-js-resolvers-in-graphql/9361/30):
>
> A simple Javascript will look like this:
> 
> ```auto
> async getVirtualName({parent, graphql, args}) {
> const [arg1, arg2] = args;
> const data1 = await fetch(`https://external-data.com/some-data/${parent.id}`);
> const data2 = await graphql(`query { foo { bar } }`);
> return {...data1, ...data2 }
> }
> 
> self.addEventListener("Query.getFullName", event => event.respondWith(getFullName(event)))
> self.addEventListener("Mutation.updateName", event => event.respondWith(getFullName(event)))
> self.addEventListener("User.virtualName", event => event.respondWith(getVirtualName(event)))
> 
> ```
> 
> Alternatively, we can provide a function to get rid of the boiler plate at the end, but typescript will complain a bit
> 
> ```auto
> self.addGraphQLResolvers({
> "Query.getFullName": getFullName,
> "Mutation.updateName": updateName,
> "User.virtualName": virtualName,
> })
> 
> ```

---

<div class="post-metadata">

**Author:** ![gja](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/gja/32/2654_2.png) [@gja](https://discuss.dgraph.io/u/gja)\
**Post date:** [January 25, 2021, 12:41pm UTC](https://discuss.dgraph.io/t/slash-lambda-fields-addgraphqlresolver-missing-args/12302/4 "2021-01-25T12:41:01Z")

</div>

> [@amaster507](#):
>
> To update, after moving this to a Lambda Mutation, the `args` for the parent mutation do come through. But we also need `args` from a Lambda Field resolver.

@abhimanyusinghgaur. Interesting. Is there a reason we don’t pass args to fields? This feels like something we’ve missed. Do you think this would be a quick fix?

---

<div class="post-metadata">

**Author:** ![abhimanyusinghgaur](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/abhimanyusinghgaur/32/2980_2.png) [@abhimanyusinghgaur](https://discuss.dgraph.io/u/abhimanyusinghgaur)\
**Post date:** [January 25, 2021, 12:44pm UTC](https://discuss.dgraph.io/t/slash-lambda-fields-addgraphqlresolver-missing-args/12302/5 "2021-01-25T12:44:14Z")

</div>

Actually, GraphQL doesn’t yet support accepting args for custom fields, and so they are not passed.  
Args for any non-query/mutation field ATM are only auto-generated, and can’t be defined by user.

But, this is a useful scenario, and we will be looking into supporting it sometime soon.

---

<div class="post-metadata">

**Author:** ![pbassham](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/pbassham/32/3672_2.png) [@pbassham](https://discuss.dgraph.io/u/pbassham)\
**Post date:** [January 25, 2021, 3:21pm UTC](https://discuss.dgraph.io/t/slash-lambda-fields-addgraphqlresolver-missing-args/12302/6 "2021-01-25T15:21:12Z")

</div>

I’m glad to hear that there will be some work to support this.

After some initial excitement of some real magic I thought we could achieve, I tried to build something useful this past week, but I have found it pretty limiting to not be able to pass `args`. Its like writing functions with no parameters.

Instead of @lambda fields being this magically flexible field, it limits it to being pretty much a single function field, and any variable requires a duplicate field to handle that slightly different scenario.

Some simple things I was attempting:

- prevent inadvertant calls to an expensive API (by requiring args before it ran)
- limit fields fetched through variables (each data piece in said API has a cost, so be able to limit which fields were fetched dependent on variables)

- String manipulation with various methods through a lambda.
- Trim a string to a variable length
- Change a string case to a variable case
- Use a database stored template string to and process replace with variables.
- Use a client provided template string and process replace with database fields.
- Do complex math operations dependent on variables using the field value.
- Format date fields per user’s supplied variable using a field from the database.
- Use fields as database side logic (e.g. Is my supplied variable in the range for a certain field: boolean)

This list could go on for so many different use cases that this is just the starting point. This truly allows an almost endless flexibility to a lambda resolver which helps to reduce the lambda resolver script size because now fewer resolvers can do more things instead of needing a dozen or more resolvers for just a few cases and each resolver then needs to map to its own field, which not only clutters the lambda resolver, but now also the GraphQL schema.

---

<div class="post-metadata">

**Author:** ![amaster507](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/amaster507/32/4123_2.png) [@amaster507](https://discuss.dgraph.io/u/amaster507)\
**Post date:** [January 25, 2021, 3:26pm UTC](https://discuss.dgraph.io/t/slash-lambda-fields-addgraphqlresolver-missing-args/12302/7 "2021-01-25T15:26:30Z")

</div>

> [@pbassham](#):
>
> Its like writing functions with no parameters.

Yes exactly! No developer would want to use a language where he could not pass arguments into functions and had to write a new function for every specific use case.

---

<div class="post-metadata">

**Author:** ![jdgamble555](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/jdgamble555/32/7503_2.png) [@jdgamble555](https://discuss.dgraph.io/u/jdgamble555)\
**Post date:** [April 3, 2021, 12:57am UTC](https://discuss.dgraph.io/t/slash-lambda-fields-addgraphqlresolver-missing-args/12302/9 "2021-04-03T00:57:58Z")

</div>

Just thought I would add, as far as typescript, you need to do this:

```auto
async function customFunction({ args, dql, authHeader }: any) {
...
...
(self as any).addGraphQLResolvers({
  "Mutation.customFunction": customFunction
});

```

Of course it really depends on your rules enabled in tsconfig…

J

---

<div class="post-metadata">

**Author:** ![jerber](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/jerber/32/8920_2.png) [@jerber](https://discuss.dgraph.io/u/jerber)\
**Post date:** [October 4, 2021, 7:44pm UTC](https://discuss.dgraph.io/t/slash-lambda-fields-addgraphqlresolver-missing-args/12302/10 "2021-10-04T19:44:24Z")

</div>

Agreed, without this feature we have to use a server between Dgraph and our client.

---

<div class="post-metadata">

**Author:** ![LeapingFrog](https://avatars.discourse-cdn.com/v4/letter/l/91b2a8/32.png) [@LeapingFrog](https://discuss.dgraph.io/u/LeapingFrog)\
**Post date:** [May 28, 2022, 9:41am UTC](https://discuss.dgraph.io/t/slash-lambda-fields-addgraphqlresolver-missing-args/12302/11 "2022-05-28T09:41:57Z")

</div>

This would be great.

I just started trying Dgraph out and immediately bumped into this issue.