Publishing Messages From a Web App to an AWS SQS Queue via AWS Lambda
In the ever-expanding list of ways AWS Lambda can help, we see how to use it to publish your web app's messages to AWS SQS.
Join the DZone community and get the full member experience.
Join For FreeI’m building a simple project that needs to receive requests from a simple webpage and process them over time sequentially (more on this later!). Using an AWS SQS queue seems like a good fit for what I’m looking for. Without creating something heavyweight like exposing a REST endpoint running in an EC2 instance, this also seemed like a good opportunity to look into integrating calls from a webpage to an AWS Lambda function. This gives the benefit of not needing to pay for an EC2 instance when it’s up but idle.
To get started, I created an AWS SQS queue using the AWS Console (the name of the queue might give away what I’m working on:
I then created a Lambda function to post a message to the queue using the script from this gist here:
var QUEUE_URL = 'https://sqs.us-east-1.amazonaws.com/{AWS_ACCUOUNT_}/matsuoy-lambda';
var AWS = require('aws-sdk');
var sqs = new AWS.SQS({
region: 'us-east-1'
});
exports.handler = function(event, context) {
var params = {
MessageBody: JSON.stringify(event),
QueueUrl: QUEUE_URL
};
sqs.sendMessage(params, function(err, data) {
if (err) {
console.log('error:', "Fail Send Message" + err);
context.done('error', "ERROR Put SQS"); // ERROR with message
} else {
console.log('data:', data.MessageId);
context.done(null, ''); // SUCCESS
}
});
}
#!/bin/sh
FUNCTION_JS=sendsqs.js
FUNCTION_FILE=sendsqs.zip
FUNCTION_NAME=sendsqs
REGION=us-east-1
EXEC_ROLE='arn:aws:iam::{AWS_ACCUOUNT_}:role/lambda_exec_role'
zip $FUNCTION_FILE $FUNCTION_JS
aws lambda upload-function \
--region $REGION \
--function-name $FUNCTION_NAME \
--function-zip $FUNCTION_FILE \
--role $EXEC_ROLE \
--mode event \
--handler $FUNCTION_NAME.handler \
--runtime nodejs \
--description "test" \
--timeout 60 \
--memory-size 128 \
--debug
Testing the Lambda from the AWS Console, I get this error:
2017-11-12T17:07:19.969Z error: Fail Send Message: AccessDenied: Access to the resource https://sqs.us-east-1.amazonaws.com/ is denied.
2017-11-12T17:07:20.007Z {"errorMessage":"error"}
Per the post here, we need to update the default policy we added during creation of the Lambda to include permission to post messages to the queue. The missing permission is to allow sqs:SendMessage and sqs:GetQueueUrl on your SQS Queue resource (insert your ARN for your queue in the Resource name):
{
"Action": [
"sqs:SendMessage",
"sqs:GetQueueUrl"
],
"Effect": "Allow",
"Resource": "arn:aws:sqs:us-east-1:SOME_ID_HERE:test-messages"
}
Using the Saved Test Event, now we’re looking good!
2017-11-12T17:32:03.906ZmessageId: f04a...
END RequestId: 658a...
REPORT RequestId: 658a... Duration: 574.09 ms
Billed Duration: 600 ms
Memory Size: 128 MB
Max Memory Used: 42 MB
Let’s take a look at our queue from the SQS Management Console and see if our payload is there:
Now that we’ve got our Lambda to post a message to our queue, how can we call it from a webpage using some JavaScript? Looking in the AWS docs, there’s an example here. This page also walks through creating configuring the AWS SDK API to use a Cognito identity pool for unauthorized access to call the Lambda. A step-by-step guide on how to create Cognito pools via the AWS Console is in the docs here. It seems there’s a gap in the docs though, as it doesn’t explicitly state how to create a Cognito pool for unauthorized access.
Just out of curiosity, if you attempt to call your Lambda function without any authentication, you get an error that looks like this:
Error: Missing credentials in config
at credError (bundle.js:10392)
at Config.getCredentials (bundle.js:10433)
at Request.VALIDATE_CREDENTIALS (bundle.js:11562)
Ok, so back to creating the Cognito Pool. From the AWS Console, select Cognito. The option you need to select is ‘Manage Federated Identities,’ which is where the option is for creating a pool for authenticated access:
Check the box: ‘Enable access to unauthenticated identities’:
Now we’re back to the AWS SDK for JavaScript and can plug in in our Cognito pool id into this config:
AWS.config.update({
region: 'REGION'
});
AWS.config.credentials = new AWS.CognitoIdentityCredentials({
IdentityPoolId: 'IdentityPool'
});
My JavaScript to call the Lambda function, so far, looks like this:
var AWS = require('aws-sdk');
//init AWS credentials with unauthenticated Cognito Identity pool
AWS.config.update({region: 'us-east-1'});
AWS.config.credentials = new AWS.CognitoIdentityCredentials({IdentityPoolId: 'pool-id-here'});
var lambda = new AWS.Lambda();
// create payload for invoking Lambda function
var lambdaCallParams = {
FunctionName : 'LightsOnMessageToQueue',
InvocationType : 'RequestResponse',
LogType : 'None'
};
function callLambda(){
var result;
lambda.invoke(lambdaCallParams, function(error, data) {
if (error) {
console.log(error);
} else {
result = JSON.parse(data.Payload);
console.log(result);
}
});
}
module.exports = {
callLambda: callLambda
}
Calling the JavaScript now, I get a different error:
assumed-role/Cognito_PostToQueueUnauthRole/CognitoIdentityCredentials
is not authorized to perform: lambda:InvokeFunction
on resource: arn:aws:lambda:us-east-1:xxx:function:LightsOnMessageToQueue"}
The error is telling us that the permission ‘lambda:InvokeFunction’ is missing for the role Cognito_PostToQueueUnauthRole, so let’s go back and edit and add it. The role was created when we stepped through the Cognito setup steps, but to edit it we need to go to the IAM section on the AWS Console. Searching for Lambda related policies to include in this role, it looks like this is what we’re looking for:
We don’t want to grant InvokeFuntion on all (*) resources though, we can use the JSON for this policy to add a new ‘inline policy’ to our role, and then edit it to specify the ARN for our function.
Back to the JavaScript app, we can now see the SDK making several XHR requests to AWS, including a POST to /functions/LightsOnMessageToQueue/invocations returning with a 200.
Checking the AWS Console, we’re now successfully making calls to our Lambda function, and messages are being posted to the queue:
To host my simple webpage, since it’s static content, this can easily be served from AWS S3. I created a new Bucket, granted public read access, and enabled the ‘static website hosting’ website option:
To package the app for deployment, AWS has a sample webpack.config.js here. I did an ‘npm run build’ and then uploaded the index.html and bundle.js to my bucket.
So far, this is one part of a project. I’ll post another update when I’ve made some progress on the next part.
Published at DZone with permission of Kevin Hooke, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments