Prisma1: Include context for functions

[marktani]

• authenticated header or user id
• project id
• custom "environment variables"

[enricenrich]

+1 on this 👍🙌

[joarwilk]

Oh god yes

[thenikso]

I would add a function to query the current graph.cool api as well? or maybe in a library that would make more sense?

[cameronk]

+1 to @thenikso. It would be really powerful to define a query that is sent by the "Data write" step to the next step (essentially, in the same position as TRANSFORM_PAYLOAD).

[kbrandwijk]

I would suggest a uniform approach to custom mutations (so a event.context.graphcool object with projectId and PAT)

[mattfysh]

This sounds like something that might be easy to add to beta testing? If you guys are running on AWS lambda, the context object contains a few things that would be useful within a function.

The project ID/alias would also be great for porting the function across multiple environments, for now I'm hard coding the value and updating as I promote functions across environments

[joarwilk]

This issue currently blocks using graphcool-lib on AWS Lambda, since it relies on the context.graphcool object.

[marktani]

Hey @joarwilk, you can manually construct the needed context as I showed in a recent answer in the Forum 🙂

[kbrandwijk]

Please also include project region in the context information. The use case for this is that some third party API's (like Azure) have regions too, and it would be nice to automatically use the project region for those.

[kbrandwijk]

Fixed?

[mattfysh]

I had this issue a couple of days ago, fromEvent from graphcool-lib was working for Schema Extensions, but not for Request Pipeline functions. @sorenbs has this fix been released?

[kbrandwijk]

It seems projectId and PAT are now also available for RP hooks, but not authentication data... @marktani?

[sorenbs]

Sorry about the confusion. We are currently consolidating our internal and external issue trackers and that got me tripped up. I closed this issue prematurely.

Previously subscriptions and request pipeline functions did not have a context object. They now have a context that is partially correct, including the pat and projectId.

Please be aware that we will make a decision on https://github.com/graphcool/graphcool/issues/460 shortly, and that might require you to specifically configure a pat to be available in the context. Please also note that we are in the process of renaming pat to rootToken.

In short - i'll reopen this ticket for now :-)

[marktani]

We'll also need to take https://github.com/graphcool/graphcool/issues/460 in account.

[sorenbs]

All functions will have the following context:

{
  auth: {
    typeName
    nodeId
    token
  },
  graphcool: {
    projectId # this will be deprecated shortly, use serviceId instead
    serviceId
    alias
    pat # this will be deprecated shortly, use rootToken instead
    rootToken
  }
}

By default, rootToken will contain a Temporary Root Token that is valid for 5 minutes.

See https://github.com/graphcool/graphcool/issues/740 for token terminology

For a given function you can configure a named Root Token to be injected instead of a Temporary Root Token or you can choose to not inject a Root Token at all:

Inject named Root Token

This configuration injects the Root Token with the name authenticate:

functions:
  authenticteCustomer:
    handler:
      code:
        src: ./code/authenticate.js
    context:
      rootToken: authenticate
    type: schemaExtension
    schema: ./code/authenticate.graphql

rootTokens:
- authenticate

Note: In the future it will be possible to control the scope of a Root Token. This feature will make it more relevant to use a named Root Token

No Root Token

This configuration disables Root Token injection:

functions:
  authenticteCustomer:
    handler:
      code:
        src: ./code/authenticate.js
    context:
      rootToken: null
    type: schemaExtension
    schema: ./code/authenticate.graphql

rootTokens:
- authenticate

When no Root Token is injected, the rootToken field will be omitted from the context.

Note: In the future we might make it possible to configure the default behaviour for root token injection.

[kbrandwijk]

Can anyone explain the difference between the 'context' node and the 'environment' node in the project file? I think both were meant to end up in the context?

Also, I would still be very much in favor of adding region, because https://github.com/graphcool/graphcool/issues/219#issuecomment-320753224

Third, what's the benefit of alias in the context?

[FredyC]

I don't get this. What's the purpose of named root tokens? I mean is there some danger coming from using temporary root token? I just don't understand why should I bother with that? I can only think of some long running task within a function that might need longer lifetime for a token, but otherwise...? Please explain.

I feel like I am misunderstanding something about root tokens in general. They are supposed to be used to access graphcool api with admin rights, correct? Then it kinda makes sense to have "temporary root tokens" as only way which would expire to avoid security leaks.

[kbrandwijk]

You don't know the contents of a temporary root token. If you use any external code (not a webhook), you need the actual value of the token. For example, a cron job running on webtask. For that, you can use a named root token, because you need to put the actual token value in your webtask code.
For all functions called directly from Graphcool (so all hooks, subscription, resolvers and webhooks) the temporary token will be passed in, so you can use it directly.

Also, in the future, it will be possible to have more control over the permission of a root token. In that case, using a specific named root token will also imply specific permissions connected to it.

All in all, until that last part is implemented, I see no use in passing in named root tokens to Graphcool functions.

[FredyC]

Ok, I understand now, I wasn't even aware of gc get-root-token command. Yea that is surely useful for some external service. Being able to set different permissions for those tokens sounds intriguing too :)

[kbrandwijk]

I would like to request another addition to the function context. I would like to have access to the Typename and operationname for hooks.. This allows for generic functions to be reused on multiple hooks.

[sorenbs]

@kbrandwijk I seem to remember that you brought up including Typename and operationname for hooks in a separate issue. I like the idea and would like to track it separately so it doesn't get lost. Can you find the old issue again and link it here, or alternatively create a new issue?

[kbrandwijk]

@sorenbs I thought so too, but I can't find it anymore... https://github.com/graphcool/graphcool/issues/750

[joarwilk]

@sorenbs

pat # this will be deprecated shortly, use rootToken instead

Can you elaborate on this? Is this documented somewhere? If I'm using the fromEvent function from the graphcool-lib package, am I using rootTokens or pat's?

Last thing I want is my backend to stop working suddenly when you stop passing in pats, given I rely on them.

[sorenbs]

@joarwilk

graphcool-lib currently depends on the pat field. It will be updated to use rootToken in the near future. There will be a multi-month notice period before we remove pat, and all developers with active projects using functions will be notified by email in advance.

[kbrandwijk]

@sorenbs Regarding https://github.com/graphcool/graphcool/issues/740#issuecomment-334952721, there's currently pat and token, if we know which one will stay, it saves some refactoring later...

Also, I would expect a new graphcool-lib release when the function context field names change, so fromEvent should simply keep working. Only for cases where people manually construct the context, like for hooks and subscriptions or external code, this would mean a change. Then again, I hope adding context to functions will come before this change, to minimize any manual code updates.

[FredyC]

It might be a good idea to use defineProperty for the pat and log deprecation message. Although I am not entirely sure about logging in deployed functions in general, that's another issue :)

[sorenbs]

Following has been implemented:

• The context has been streamlined between all function types.
• injected rootTokens are now shortlived.

879 covers configuring the injected rootToken

[dhruska]

When invoking a resolver locally, event.context is undefined. Is this the correct behavior? Additionally, when passing in an argument (for example, contactId), it is passed in as event.contactId locally, but event.data.contactId when deployed. I could be mistaken but this seems like incorrect behavior.

[kbrandwijk]

@dhruska What do you mean by 'locally'? In a local cluster, or using graphcool invoke-local?

[dhruska]

@kbrandwijk Using graphcool invoke-local

[kbrandwijk]

@dhruska Could you please create a new issue for that, as I don't think it is reported yet.

[dhruska]

@kbrandwijk will do!