This is a part in a series on AWS serverless architecture. The original blog post series can be found both here and on my blog J-bytes.

Let's Send Some Tweets With Lambda

Okay, so now is finally the point where this Twitter thing comes together. In this section, we'll process the user's authorization to have them follow us, as well as send them a tweet stating that they are successfully signed up!

Please remember that if you make the user follow you without having checked that checkbox, you can have your account banned from twitter. This can be a serious problem, because without that account, all of the twitter handles you have collected become useless.

Also, we'll be sending the twitter user a DM from themselves to themselves. This is because sending direct application DMs are strongly rate-limited by account, but having users DM themselves is something you can absolutely do at mass scale. It's a bit strange, I know, but that's how we do it. That is why it is super critical that you request DM access in your twitter app settings.

Anyway, we'll be doing the familiar steps here - upload a lambda, make a gateway connection to hook it up, and complete our testing. We'll also talk about how to update lambdas with zero downtime in production.

Step 1: Lambda

You know the drill by now, so I'm going to make this very short (and see how much you remember)! Warning: Christmas tree and non-DRY Javascript ahead. Suggestions very much welcome.

Make a folder called callback_lambda. cd into it, and copy loader.js into it. Move index.js into it, and download the node-twitter-api library here as well. Change the database region in index.js to your region. Zip it. Create a lambda function on the AWS console called twitter_callback. Upload your files as we have before. Don't forget to set the timeout to 15s and the role to master_lambda! Create two aliases - staging and production, pointed to $LATEST.

Don't worry about updating your json-env file yet. We'll do that post API phase to make sure everything is all smooth. We also won't be testing this yet, because it is a lot easier to test once we've actually hooked up the API and are testing through that.

Step 2: Api Gateway

So, this gateway is going to be slightly different, because it's a GET instead of a POST.

That is about the only difference.

Go to our API. On the resources tab, click on /api, then click actions, create resource. Name this "twitter-callback". Create a GET method on twitter-callback. The lambda is twitter_callback:${stageVariables.alias}
Set it up in your AWS CLI with staging and production again. On the integration request, the body mapping template is application/json (you MUST manually type this in. AWS has it as a template, but it won't actually auto fill if you leave it blank). The request passthrough is "when there are no templates defined", and the body passthrough is "Method Request passthrough".

Method Response is again a 301 with header of location.

Set the integration response to our 301, error regex to "^Twitter.MovedPermanently.*", then after clicking save add a header mapping value of "integration.response.body.errorType" to the location header mapping. Go back to the GET method execution screen and under Integration Response change the HTTP status pattern to what we just set.

Publish, export. Fire up postman for the last round!
NOTE: If your follow account is the same account you are testing this with, your CloudWatch logs will tell you that you can't follow yourself. This is good; it means follow is working. Also, if you can't see your account following someone, make sure the account to be followed doesn't have a padlock symbol next to it. That means it is only followed if it manually approves its followers.

Step 3: Env-Config

Go to API gateway, then stages, then staging, then twitter-callback - GET. Copy that URL. Go to your S3, download your staging environment vars, and paste that huge url into your "twitter_api_callback" key. Reupload with KMS encryption. Repeat for production (API Gateway, stages, production, etc.).

Step 4: Postman

Go get the staging url for twitter-session (or check your postman history), and put it into postman. Header is still Content-Type : application/x-www-form-urlencoded, and the body is still x-www-form-urlencoded with key-value pair of follow : true.

Send with POST. When you get the response, click on "pretty." Ctrl-f for the word "redirect". You should see a tag with a value of "https://twitter.com/oauth/lots_of_stuff". Copy that entire URL and paste it into a browser. Authorize the app. You should see some loading stuff and then be redirected back to your site! Hopefully the redirect address has params with success. If not, you'll have to read your Cloudwatch logs and see where you may have gone wrong. You should be able to check the twitter account you authorized with and see a tweet from yourself to yourself. If you followed chose to follow yourself with postman, You should also see:

Trace: {
  statusCode: 403,
  data: '{"errors":[{"code":158,"message":"You can\'t follow yourself."}]}'
}

otherwise you should simply be following someone.

Congrats on your hard work! Remember, if you aren't getting the right messages and you don't know what you did, check your twitter app settings.

Lastly, to update your lambda settings, go into your AWS panel and click on the lambda that needs updating. Make whatever changes you need and publish a new version. Then click on the button to the left of the blue test button (versions, qualifiers, alias, etc.) and click on the aliases tab. Select the alias you want to update, click on the "configuration" tab, then simply click the version drop-down and confirm. Updated!

Next, we're going to put the whole thing on CloudFront and then download the data through data pipeline to an S3 bucket so we can do cool things like decrypt email addresses and send DMs.