# Pass Client Variables through Directive to Lambda

**URL:** <https://discuss.dgraph.io/t/pass-client-variables-through-directive-to-lambda/11224>\
**Category:** GraphQL\
**Tags:** kind:feature\
**Created:** [October 30, 2020, 5:16pm UTC](https://discuss.dgraph.io/t/pass-client-variables-through-directive-to-lambda/11224 "2020-10-30T17:16:18Z")\
**Posts on this page:** 3\
**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:** [October 30, 2020, 5:16pm UTC](https://discuss.dgraph.io/t/pass-client-variables-through-directive-to-lambda/11224/1 "2020-10-30T17:16:18Z")

</div>

Continuing the discussion from [Dgraph October Community Call](http://discuss.hypermode.com/t/dgraph-october-community-call/11030/15):

First of all, THANK YOU for the upcoming `@lambda` in 20.11 I am really excited for this!!

Not trying to be negative at all, but want to ask for a feature request extension on this knowing it isn’t even released yet. 😬

There is so much power in directives to hold imperative data from a client perspective. GraphQL has given the example of an `@upper` directive that could be used similar to how `@lambda` is used to convert a string to upper case within the resolver.

Dgraph took this to the next level by really making a full javascript hook that is linked to a field by adding the lambda directive and the appropriate js function in the lambda script. This is awesome! What it is lacking though is flexibility.

If I want to create a string manipulation field one for lower case and one for upper case, I would need to write two separate predicates and assign both the lambda directive, then write two separate functions to handle each one. This would look something like:

```graphql
type Item {
  id: ID
  title: String!
  titleLC: String! @lambda
  titleUP: String! @lambda
}

```

```js
addGraphQLREsolvers({
  "Item.titleLC": ({ parent: { title } }) => title.toLowerCase()
  "Item.titleUC": ({ parent: { title } }) => title.toUpperCase()
})

```

While this works, it causes stress points:

- A new predicate for every type of text transformation I want.
- A new function for every predicate with the lambda directive.

What I propose is:

1. Allow a client directive to pass variables
2. Allow the lambda schema directive to map to a function.

# Allow a client directive to pass variables

> Note: This looks to be started already in the codebase as the 4th param in getBodyForLambda

Extending the schema to allow for a `@variables` directive that can be applied on any field that also accepts the `@lambda` directive. This variables directive would accept parameters:

`@variables(func: "toUpperCase", field: "title")`  
`@variables(func: "toLowerCase", field: "text")`

In the [graphql/resolver.go:894](https://github.com/dgraph-io/dgraph/blob/2d993721ada2a90a92c707d516e8247055c81583/graphql/resolve/resolver.go#L894) script, forward these parameters as the 4th param when calling getBodyForLambda

Extend the [`GraphQLEvent`](https://github.com/dgraph-io/dgraph-lambda/blob/e6bf26ab6c34a05b5dae3db4cddda83ff33778e0/slash-graphql-lambda-types/types.d.ts#L21) type to accept `args: any | null`

Then I could write [this is untested]:

```auto
type Item {
  id: ID
  title: String!
  text: String
  transform: String @lambda
}

```

```auto
addGraphQLResolvers({
  "Item.transform": ({ parent, variables: { func = null, field = null } = { } }) => func ? parent?.[field]?.[func]?.() : null
})

```

# Allow the lambda schema directive to map to a function.

Currently the resolver for the lambda directive is linked directly to the `Type.predicate`. This makes reusing the same resolver one step more difficult:

```auto
type Item {
  id: ID
  title: String!
  text: String
  transform: String @lambda
}
type Second {
  id: ID
  title: String!
  text: String
  transform: String @lambda
}

```

```auto
const transform = ({ parent, variables: { func = null, field = null } = { } }) => func ? parent?.[field]?.[func]?.() : null
addGraphQLResolvers({
  "Item.transform": transform,
  "Second.transform": transform
})

```

This stress point here is needing to update the lambda script for any predicate later on that wants to use the same already created resolver.

What I propose is allowing the lambda directive to be parameterized accepting a single param which points to the resolver.

The default mapped resolver should be the [`field.GetObjectName() + "." + field.Name()`](https://github.com/dgraph-io/dgraph/blob/2d993721ada2a90a92c707d516e8247055c81583/graphql/resolve/resolver.go#L2015) as is already, with a check before that to look for a param from the lambda directive.

This would allow me to use the lambda directive as the following:

```auto
addGraphQLResolvers({
  transform: ({ parent, variables: { func = null, field = null } = { } }) => func ? parent?.[field]?.[func]?.() : null
})

```

```auto
type Item {
  id: ID
  title: String!
  text: String
  transform: String @lambda(transform)
}
type Second {
  id: ID
  title: String!
  text: String
  transform: String @lambda(transform)
}

```

* * *

I might have offered some pull requests but I am not familiar enough with Go nor do I understand how to read the directive from the schema or the request, sorry.

---

<div class="post-metadata">

**Author:** ![pawan](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/pawan/32/1946_2.png) [@pawan](https://discuss.dgraph.io/u/pawan)\
**Post date:** [December 10, 2020, 10:15am UTC](https://discuss.dgraph.io/t/pass-client-variables-through-directive-to-lambda/11224/2 "2020-12-10T10:15:43Z")

</div>

So seems like if we accepted the function name as an argument to `lambda` that would make it slightly easier to reuse the same functions across multiple fields. This sounds like a good to have though not sure if we can have it in the next release.

---

<div class="post-metadata">

**Author:** ![codinghusi](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/codinghusi/32/6573_2.png) [@codinghusi](https://discuss.dgraph.io/u/codinghusi)\
**Post date:** [March 15, 2021, 8:07pm UTC](https://discuss.dgraph.io/t/pass-client-variables-through-directive-to-lambda/11224/4 "2021-03-15T20:07:06Z")

</div>

Hey there, I’m a bit late to the party.  
Is this still under consideration? I’d find this a really good fitting addition 🙂

Edit: would be also nice: create own directives instead of @lambda and start them with \_ so everyone knows that this is a custom one 🙂