feat(graphql-function-transformer): port @function to v2

[cjihrig]

Description of changes

This commit ports the @function directive to v2 of the GraphQL
Transformer.

Issue #, if available

Description of how you validated changes

Manual and automated testing.

Checklist

• PR description included
• yarn test passes
• Tests are changed or added

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[codecov]

Codecov Report

Merging #7055 (8c721b2) into master (07525b3) will increase coverage by 0.09%.
The diff coverage is 98.00%.

@@            Coverage Diff             @@
##           master    #7055      +/-   ##
==========================================
+ Coverage   56.43%   56.52%   +0.09%     
==========================================
  Files         445      447       +2     
  Lines       21859    21909      +50     
  Branches     4373     4380       +7     
==========================================
+ Hits        12336    12385      +49     
- Misses       8745     8746       +1     
  Partials      778      778              

Impacted Files	Coverage Δ
...on-transformer/src/graphql-function-transformer.ts	97.95% <97.95%> (ø)
.../amplify-graphql-function-transformer/src/index.ts	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 07525b3...8c721b2. Read the comment docs.

[yuth]

Overall looks good. Couple of nits. Onething we should think a bit deeper about is to see if directives like @auth or data enhancers say @default can be built in a generic way and if it can be used with the @function directive

[yuth]

We have had some issues come in earlier where customers have hit the stack size limitation for directives that create just 1 stack (like connection). Since only one stack contains all the @function, could we look into splitting this when it hits some threshold?

[cjihrig]

I'd like to avoid character counting if possible. It would also be nice if the related data source, app sync function, and resolvers could be kept together in the same file to avoid awkward dependencies between files.

What do you think about splitting this up at the data source level? That would ensure that there are no dependencies across files. It would still be theoretically possible to hit a limit, but I don't think that can ever be avoided if an app is sufficiently large.

[yuth]

I'd like to avoid character counting if possible. It would also be nice if the related data source, app sync function, and resolvers could be kept together in the same file to avoid awkward dependencies between files.

I don't char counting either. One approach we could take is to say how many function we put in a single stack, and if we exceed the number of functions then we create another stack for function. I am not sure what would the ideal number of function in a stack. We could potentially change the number of function in future if we want without causing any issue as the functions are just data sources and by themself they can be moved around without causing any data loss.

What do you think about splitting this up at the data source level? That would ensure that there are no dependencies across files. It would still be theoretically possible to hit a limit, but I don't think that can ever be avoided if an app is sufficiently large.

I am not sure if I understand this correctly, but with @function the DataSource is a lambda function right. Are you suggesting all the @function that use the same lambda function go in a single stack?

[cjihrig]

Are you suggesting all the @function that use the same lambda function go in a single stack?

Yes. So, in the following example, there would be a single data source, a single appsync function configuration, and two pipeline resolvers. I was proposing trying to keep all of that together in a single file.

type Query {
    echo(msg: String): String @function(name: "echofunction-\${env}")
    magic(msg: String): String @function(name: "echofunction-\${env}")
}

One approach we could take is to say how many function we put in a single stack, and if we exceed the number of functions then we create another stack for function.

That would work too, and should be fairly straightforward.

[siegerts]

👋 Hi, this issue was referenced in the v4.50.2 release!

Check out the release notes here https://github.com/aws-amplify/amplify-cli/releases/tag/v4.50.2.