Amplify-cli: Should I copy graphql schema in each lambda function?

Created on 21 May 2020  路  1Comment  路  Source: aws-amplify/amplify-cli

Note: If your question is regarding the AWS Amplify Console service, please log it in the
official AWS Amplify Console forum

Which Category is your question related to?

  • So I just pushed my lambda functions to the cloud and it doesn't have access to files outside the lambda function name - since I need to access the generated schema from src/graphql so I don't duplicate mutations. Should I copy the schema in each lambda function? or other ways?
  • I don't think it's wise to duplicate schema - I mean I can create scripts that will copy every time I compile a schema - but this can lead to bugs in future if a developer forgets to do that.
    Amplify CLI Version

You can use amplify -v to check the amplify cli version on your system

What AWS Services are you utilizing?
amplify, lambda

Provide additional details e.g. code snippets

{
  "data": {
    "getSomeThing": null
  },
  "errors": [
    {
      "path": [
        "getSomeThing"
      ],
      "data": null,
      "errorType": "Lambda:Unhandled",
      "errorInfo": null,
      "locations": [
        {
          "line": 2,
          "column": 3,
          "sourceName": null
        }
      ],
      "message": "Error: Cannot find module '../../../../../../src/graphql/es2015/mutations'"
    }
  ]
}
functions question

Most helpful comment

@gautamkshitij the current tooling does not have out of box support for this kind of code sharing as it can be done in a lot of different ways from published packages to local file copying during the build process. The generated source files are outside of the lambda directory and are not deployed with the lambda, hence the error message. As you've stated you've to add this functionality to your project that fit your needs. Either as a script or some other ways.

Personally when I was in this situation I had a node package in the root of my repository and followed yalc guide to allow me to reference local packages in a clean way. It still requires yarn like commands to keep up to date with the references, but it worked well for me.

I'm closing the issue are the question is answered, if you have other related question feel free to reopen the issue or create a new one.

>All comments

@gautamkshitij the current tooling does not have out of box support for this kind of code sharing as it can be done in a lot of different ways from published packages to local file copying during the build process. The generated source files are outside of the lambda directory and are not deployed with the lambda, hence the error message. As you've stated you've to add this functionality to your project that fit your needs. Either as a script or some other ways.

Personally when I was in this situation I had a node package in the root of my repository and followed yalc guide to allow me to reference local packages in a clean way. It still requires yarn like commands to keep up to date with the references, but it worked well for me.

I'm closing the issue are the question is answered, if you have other related question feel free to reopen the issue or create a new one.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

zjullion picture zjullion  路  3Comments

davo301 picture davo301  路  3Comments

onlybakam picture onlybakam  路  3Comments

amlcodes picture amlcodes  路  3Comments

ffxsam picture ffxsam  路  3Comments