serverless-components / graphql Goto Github PK

When I set domain and region (to value other than us-east-1) together in my serverless.yml, I got the following error message when trying to deploy:

InvalidViewerCertificate: The specified SSL certificate doesn't exist, isn't in us-east-1 region, isn't valid, or doesn't include a valid certificate chain.

I have the domain all setup in Route53, and when I remove the region setting, it works fine, so that eliminates the possibility of mis-configed domains. But the resource is deployed to us-east-1, which is not what I wanted.

According to aws doc here

The certificate must be imported in the US East (N. Virginia) Region.

With my limited knowledge of AWS and serverless framework, my theory is that the region config is used by the process to import the certificate. I think we should hard code it to use us-east-1 right now given it's a hard requirement from AWS officially.

graphql 3.0.3

I have graphql components configured to deploy to different stages each with a different provider defined in the serverless web ui with each provider being a different aws account.

When I deploy to the different stages the resources are created in the correct account, but about 50% of the time the account id in the lambda's role for invokeFunction is incorrect. When this happens making a graphql call returns an error that appsync is not able to call the lambda.

When the account id is incorrect it is an account id from one of the other 2 accounts.

        {
            "Effect": "Allow",
            "Action": [
                "lambda:invokeFunction"
            ],
            "Resource": "arn:aws:lambda:us-west-2:<wrong account id>:function:api-v8-stagename-appname-s2229lk*"
        }

When deploying to one account with one configured provider in the serverless UI it successfully created lambda invokeFunction policies with the correct account ids.

Hi, I need to implement real-time notifications, and the recommended way of doing it with app sync seems to be local resolvers:
See here: https://docs.aws.amazon.com/appsync/latest/devguide/tutorial-local-resolvers.html

How can I get this to work with graphql? And if it's not possible now do you have a timeframe for that? Real-time notification is a crucial feature for a lot of apps these days.

Thanks

The graphql-starter needs that to prevent accidentally uploading keys.

It doesn't look like there's support for HTTP resolvers. When I specify an endpoint it assumes it's the elasticsearch resolver. Are there plans to add it?

Hello, we've seen some intermittent deployment failures when deploying graphql components. I put this in with support and they asked me to put it in here.

Here's the output:

25lInitializing...
Action: "deploy" - Stage: "dev" - Org: "rioverde" - App: "api" - Name: "base"
Deploying...
Deploying "api-v8-dev-nw3gq5z" to the "us-west-2" region.
TypeError: self.intercepts.console[type].apply is not a function
at intercept (/opt/nodejs/node_modules/@serverless/core/node_modules/@serverless/platform-client/src/index.js:1289:41)
at console.log (/opt/nodejs/node_modules/@serverless/core/node_modules/@serverless/platform-client/src/index.js:1298:7)
at log (/var/task/serverless.js:28:30)
at GraphQL.deploy (/var/task/serverless.js:95:5)
at async Runtime.module.exports [as handler] (/opt/nodejs/node_modules/@serverless/core/handler.js:337:24)
6s › Serverless › self.intercepts.console[type].apply is not a function
Documentation: https://github.com/serverless/components
Support: https://app.serverless.com/support
Slack: https://www.serverless.com/slack/
25hError executing "AWS_PROFILE=rio-beta sls deploy --stage dev --debug" Exit code: 1
Error: Process completed with exit code 1```

When an appsync api is deployed and then extended with additional graphql components that reference it's appId the resolvers they attached are disconnected.

To fix each component that references the appId need to be removed and deployed.

Unexpected errors can occur when resolvers.js is loaded as part of the deploy process.

For example, it's common to create things like DB connections outside of the handler so that they persist as long as the lambda is running without being recreated on each call. Another thing that I'm experiencing is that I instrument my lambdas with aws xray and that loads and instruments http which can errors.

If this require was replaced with a fs read file and it was parsed differently it would still be possible to determine the keys under Query and Mutation.

In order for this Serverless component to be usable for anything more than a hobbyist project, it should support schema stitching out of the box.

As GraphQL projects and codebases grow, schema management becomes critical. The best way to manage a schema at scale is to split it up into multiple smaller files and then "stitch" them during the build/deploy process.

So in order to just specifying a single schema.graphql file, it would be awesome if we could specify either (a) an array/list of files OR (b) a directory.

This feature is also supported by the serverless-appsync-plugin plugin.

AppSync now has full support for completely custom auth via Lambda authorizers (https://aws.amazon.com/blogs/mobile/appsync-lambda-auth/)

It's common practice to write initialization process like db connection (opening db connection and reuse it in handler function) at the top of handler function and write finalization process like db closing (closing db connection before lambda container would be destroyed).
How could we do it with resolvers.js because this resolvers.js wouldn't include handler function definition?

It seems that the name of the instance as specified in the serverless.yml is also used as the name withing app sync, plus some unique id. It would be preferable if that could be overwritten, in our case I would prefer the name to include the stage to make identification easier.

E.g. issuer becomes issuer-prod-234drfs3 when deployed for production.

Hi,
When specifying the the auth option for OpenID, I get an error saying:

"BadRequestException: Authentication type not specified"
I believe this is an issue here:
https://github.com/serverless/aws-sdk/blob/b552a3954e6cadb093db4127cb8458192c7bb35b/src/deployAppSyncApi.js

But it could be an issue with how the structure of the yaml in this component.

I don't know if this is something that is not supported yet, a bug, or my bad implementation.

Any help would be appreciated.

For clarity my serverless.yaml looks like this (with placeholders replaced with real value):

component: graphql
name: [my app]-graphql

inputs:
  src: ./build
  auth:
    issuer: https://[domain].auth0.com
    authTTL: 0
    clientId: [my client id]
    iatTTL: 0

The log group exists for the lambda in cloudwatch, but the AWS lambda console shows:

Missing permissions
Your function doesn't have permission to write to Amazon CloudWatch Logs. To view logs, add the AWSLambdaBasicExecutionRole managed policy to its execution role. Open the IAM console

Is this something that is meant to be explicitly added to the lambda's configuration? If so how do go about that?

Thanks

Currently the config sets these lambda parameters:

const deployLambdaParams = {
        lambdaName: this.state.name,
        description: inputs.description,
        handler,
        memory: inputs.memory,
        timeout: inputs.timeout,
        env: inputs.env,
        layers: inputs.layers,
        roleArn,
        lambdaSrc: zipPath
      }

vpcConfig needs to be added. It would be a nice distinction if the lambdas parameters were broken out from the top level inputs into their own key.

A standard pattern when using subscriptions to database updates is to use IAM authentication for certain mutations (example directive: @aws_iam).

Can you specify multiple authentication types using this component?

It seems that by default the lambda deployed by graphql has it's logs captured and sent to serverless and they don't show up in the cloudwatch console.

It would be ideal if there was a way to configure it to also log to cloudwatch.

I've inherited a codebase using this component, and am getting the error below when attempting to deploy. Obviously the error is remote, but I can't see why I would be having this issue deploying when the previous dev did not.

There's one issue here (serverless/serverless-graphql#316) which mentions it happening intermittently, but I'm getting it for every attempt (unless I get a timeout which is also happening).

% nvm exec 14.15.4 sls deploy --debug --stage=dev  

Running node v14.15.4 (npm v6.14.10)
Initializing...
Action: "deploy" - Stage: "dev" - Org: "OrgName" - App: "appname-graphql" - Name: "appname-graphql"
Deploying...
Deploying "appname-graphql-n7lr7nr" to the "us-east-1" region.
Deploying Role "appname-graphql-n7lr7nr" to the "us-east-1" region.
Deploying resolvers for AppSync API with ID "yeaexzl3gjeqtak3fftwqu5btm".

 ConcurrentModificationException: Data source locked due to concurrent update, please retry
    at Object.extractError (/var/task/node_modules/aws-sdk/lib/protocol/json.js:52:27)
    at Request.extractError (/var/task/node_modules/aws-sdk/lib/protocol/rest_json.js:55:8)
    at Request.callListeners (/var/task/node_modules/aws-sdk/lib/sequential_executor.js:106:20)
    at Request.emit (/var/task/node_modules/aws-sdk/lib/sequential_executor.js:78:10)
    at Request.emit (/var/task/node_modules/aws-sdk/lib/request.js:688:14)
    at Request.transition (/var/task/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/var/task/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /var/task/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/var/task/node_modules/aws-sdk/lib/request.js:38:9)
    at Request.<anonymous> (/var/task/node_modules/aws-sdk/lib/request.js:690:12)

14s › Serverless › Data source locked due to concurrent update, please retry 

  Documentation: https://github.com/serverless/components 
  Support: https://app.serverless.com/support 
  Slack: https://www.serverless.com/slack/ 

The only thing of note is that n7lr7n in appname-graphql-n7lr7n is different from the existing dev stage deployment, possibly because the OrgName has changed. If there's any hints on how to override this so I can get the original hash, that might indirectly solve the problem (in the hope its only happening when doing a fresh deploy).

I tried modifying the apiId: which seems to work for resolvers line, but doesn't change the general naming.