I have react web app that uses aws amplify to build its backend. This backend consists of a graphql api with a dynamodb table as data source (created by the model declared in my graphql schema) and a lambda function that fetches information from a 3rd party api and saves the results into the dynamodb table to make it available for the app.
Following this tutorial:
https://docs.amplify.aws/cli/function#graphql-from-lambda
I created the lambda function running the "amplify add function" command. I answered "yes" when I was asked if the lambda should have access to other amplify resources and I gave the lambda write and update access to my graphql api, so that I can perform mutations from the lambda.
When I finish the creation process, amplify informs me that I have two new environment variables available in the lambda:
API_<MY_APP>_GRAPHQLAPIENDPOINTOUTPUT
API_<MY_APP>_GRAPHQLAPIIDOUTPUT
The problem is, however, that I also need the api key in order to be able to perform the mutations (my graphql api has "api key" as primary id method).
The tutorial makes use of process.env.API_KEY. However they don't explain where this variable comes from, as in my case its value is undefined.
Do you know how to make the api key available to my lambda?
P.S.: Hardcoding is not an option, as I have several backend environments.
The env var is called API_<APP_NAME>_GRAPHQLAPIKEYOUTPUT. It appears only if you enable API KEY authentication for your GraphQL API.
Here is an example of what is printed into the console when you add access permission for a Lambda function to access a GraphQL API:
You can access the following resource attributes as environment variables from your Lambda function
API_AMPLIFYTEST_GRAPHQLAPIENDPOINTOUTPUT
API_AMPLIFYTEST_GRAPHQLAPIIDOUTPUT
API_AMPLIFYTEST_GRAPHQLAPIKEYOUTPUT
Also, the Amplify CLI generates a comment on top of your Lambda function index file with the list of useful env vars.
I tested this with Amplify CLI version 4.36.0.
Related
I’m approaching AWS for the first time, and I’m trying to build an app using Amplify, API Gateway, Cognito, Lambda and Dynamo DB (I’m building some sort of a ToDo app).
I’ve learnt how to use lambda and dynamoDB without any authentication system and now I want to implement it.
I’ve already setup cognito, api gateway and lambda in order to access API with an IdToken, but what I’m not able to do is saving into dynamoDB the data of the user that called the API, as when I log the event inside CloudWatch I see that all the fields that refer to cognito are null (ex. “Context.identity” is null).
I need it so when an user want to see its data I’ll call the GET method which filters only that user’s data and retrieves it.
Anyone could please explain if this is the correct way to do it and what I’m missing, or if there’s an easier way to build this?
I'm using AWS Amplify for react native. I've created a Lambda function with the amplify cli tool.
I've also wired this function to a query type I've made in my API, like so:
type Query {
doCoolStuff(msg: String): String #function(name: "doCoolStuff-${env}")
}
The AWS docs says that the structure of the function event contains identity data. You can see that part of the docs here: https://docs.amplify.aws/cli-legacy/graphql-transformer/function/#structure-of-the-function-event
How do I know that the claims provided in the identity section of the event are valid? Is there any auth'ing going on under the hood? I've been looking through the docs but I can't tell if this Lambda does any authenticating or not.
If there is no authentication, how do I add it? I'm using v2 of the schema.graphql.
I am working on a project and trying to use API Gateway to invoke a lambda function. The lambda function is used to update a DynamoDB item. The DynamoDB table is used to keep a running count of visitors to a web page. I need to create an API to invoke the lambda function but I'm not sure how to create the API. Any assistance is appreciated.
General steps would be:
Create AWS_PROXY integration between API Gateway and your Lambda function. The example of this is in the AWS tutorials: Set up Lambda proxy integrations in API Gatewa and in Tutorial: Build a REST API with HTTP proxy integration
Add/amend execution role to your function allowing it to access DynamoDB. This is exemplified in the AWS tutorial: Using AWS Lambda with Amazon DynamoDB.
Test the API. It can be done directly in API gateway console, or using external tools such as curl or Postman.
I figured out my issue. In my lamdba function, I needed to change the output to a JSON object. Once I made the change, I was able to get my API working. Here is a link to the fix.
I have a mobile back-end set up on as:
Apigateway-->[Cognitico authorizer]AWS Lambda --> DyanmoDb
I have one Environment setup for PROD
I want to create another environment for DEV and UAT. For this purposes I have created separate AWS account. My lambda code is easy to deploy and I can create DynamoDB tables manually.
API gateway was created via the web console. Now I could export the API via swagger but when I import into another account I get the error below:
Invalid authorizer ID specified. Setting the authorization type to CUSTOM or COGNITO_USER_POOLS requires a valid authorizer.
I could manually remove authorizers and import the swagger file but that seam like a hack.
So the questions:
1) Assuming having one account for PROD and another account for UAT is the right approach. What would proper/easier way to move API Gateway config from one AWS account to another?
2)Is there a better way to have multiple environments for kind of setup above? Any official recommendations?
I'm building an API using AWS API Gateway and AWS Lambda. I would like to achieve continuous delivery for this API. The path I've chosen to do it is to use CloudFormation through AWS CodePipeline. I've managed to to it for another project using Lambdas (without API Gateway), it works perfectly and it is really pleasant to use.
The issue I'm facing when deploying is that the Lambdas are properly updated but not the API definition. From what I understand, the AWS::ApiGateway::Deployment are immutable resources which means that for each deployment of the API I need to create a new AWS::ApiGateway::Deployment resource. This is not practical at all because for each of this AWS::ApiGateway::Deployment I have a new Invoke URL. This is not acceptable since I would have to either change my DNS record to the newly deployed API invoke URL or ask our API users to change the URL in their applications.
What I would like is to be able to change the API definition and the Lambdas implementations without my API users having to change anything in their applications.
How can I achieve this behavior?
I created a tutorial to highlight my issue. You can find it at: https://github.com/JonathanGailliez/aws-api-gateway-lambda-example
As per: https://forums.aws.amazon.com/thread.jspa?messageID=789869󀵭
joey-aws says:
We are currently in the process of rolling out a solution which
addresses this exact problem. In the meantime, a common workaround
would be to update something small, such as a "description" field
which could then be used to "trigger" an API Gateway deployment when
updating the CloudFormation stack.
I'll update this answer and the example repo once it's rolled out.
You could run a Cloudformation update from the command line or in the AWS console. This would change the API definitions and any lambda code without changing the unique id to access your gateway.
The other option is to put your API behind a custom domain name and then you could keep deploy a new API or stage and switch over the custom domain mapping when you are ready. The users wouldn't recognize any change.
A way to achieve that is by leveraging existing frameworks like
AWS SAM
Serverless
Claudia
I was able to achieve this by using CloudFormation template generated by troposphere and boto3 api in Python as follows:
Split the template into two parts
API definition, Method(s), IAM roles, ApiKey and Lambda (a)
Deployment, UsagePlan and UsagePlanKey (b)
Once changed Lambda code is zipped up and uploaded to S3 using boto3 api
Stack (b) is deleted
Stack (a) is updated with new resource id for the GET method connected to lambda
Stack (b) is created anew
Steps 3, 4, 5 are performed using CloudFormation boto3 api with blocking until completed.
Most importantly after all steps are done ApiKey value and stage Invoke URL remain the same, running updated Lambda code as tested with curl.
Note: it may take additional 30-60s for API to become fully functional after CloudFormation update is completed.