DEV Community: rachel

Monitoring UX in Single Page Applications

rachel — Tue, 06 Jul 2021 17:49:22 +0000

This is a crosspost from my personal blog, rachelisaweso.me

A seamless user experience is the key to success for all modern web applications, but sometimes tracking user behavior is a bit difficult when you’re dealing with single page applications (SPAs). Let’s learn about Real User Monitoring (RUM) to get some insight into our users’ behavior so we can continue crafting the best journey.

First we’re going to start with an application I built over the past year. One thing we all struggled with during the pandemic was connecting with our friends, and one of the things my friends and I love doing in normal circumstances is taking photobooth pictures. Specifically, Japanese style photo booths called purikura. In Japan, purikura (プリクラ) refers to a photo sticker booth or the product of such a photo booth. The name is a shortened form of the registered trademark Purinto Kurabu. The term derives from the English print club.

Purikura booths start off like any photo booth that you might see in the US, by taking your photos in a photo booth. Once you’re done, you move around to another side of the machine, where an interactive screen allows you to decorate your photos with filters, stickers, writing, and stamps. Finally, you move outside the booth to wait for your photos to be printed in sticker form, so you can share them with your friends.

I knew I wanted to build a web application that would enable myself and others to recreate that experience, but completely in the browser. Since I love a challenge, I decided to use only technologies that were new to me. That project is called Purrybooth.

Purrybooth is a React application utilizing WebAssembly for ultra fast image filtering, and HTML5 canvas for the photo decorating. It’s hosted on Netlify, so any time I push changes to my main GitHub repository, the build automatically kicks off and everything is generated and deployed and I don’t have to worry about a thing.

Let’s walk through the technical specifications so you can have an understanding of how this was built. I knew that I was going to be building a fairly simple React application, and that all of my components were going to be React hooks. It would be a single page application with no routing.

For the image, you are able to either use your webcam to take a photo, or upload a photo of your own before moving onto the filters. Image filtering is included in most image manipulation libraries. I had used ImageMagick before, but had a terrible time with it. I wanted to find a better way to do Instagram-like filtering. I came across Photon, a high performance image processing library written in Rust and can be compiled to WebAssembly, and there was already a React demo so it was easy to integrate. Once you choose the filter you want, you move onto the decoration stage.

This was the trickiest part to solve! I knew I needed to use a canvas element, and I would be placing the filtered image as the background, but I also needed a way to add the stickers. I ended up using Fabric.js to achieve this, with some additional custom interactions I had to integrate—such as changing the z-index of the stickers and the capabilities for removing them. Once you’re done decorating with the stickers, you go to the final page where the canvas is rendered as an image, which you can save and share with your friends.

Now that I had a fully working app, as well as a base set of stickers and filters, I wanted a way to keep track of how my users were interacting with the photo booth. How could I know which stickers and filters were popular? I needed to have these kinds of insights in order to continue to make the best possible experience.

The next thing I did was integrate my app with Datadog’s Real User Monitoring. You only need a few lines of code in your main index.js file. Out of the box it gives you a lot of visibility into where your users are clicking, performance info, errors, and the usual analytics This was a good start, but It was missing something. Since I made the decision to create a routeless SPA, I only knew generally where users were clicking, but there was a way to improve on this data!

Custom User Actions allow you to collect additional events and data from your application. I wanted to be able to know what stickers were the most popular as well as what filters people were using. By adding Custom User Actions, I’m able to add or remove features depending on usage without having to A/B test, which really saved me a lot of time.

For more info on Purrybooth please try out the app for yourself at purrybooth.com, and check out the code on github.com/rachelnicole/purrybooth. For more info on Datadog Real User Monitoring, check out Datadog's RUM documentation.

Part 2 : How to Monitor a Serverless Application

rachel — Tue, 20 Apr 2021 18:00:32 +0000

This post originates from https://rachelisaweso.me/posts/serverless-lambda-pt2/ and is by Rachel White @ohhoe

Datadog makes setting up monitoring on your serverless function easy with our AWS Integration.

The first part is enabling the AWS integration. Head to the AWS integration tile and fill in your information.

The AWS integration sets up some IAM roles and begins scraping your AWS account for information about what’s going on within your AWS infrastructure.

Next we set up the Datadog Forwarder Lambda function, which is required for ingestion of AWS Lambda traces, enhanced metrics, custom metrics, and logs.

https://docs.datadoghq.com/serverless/forwarder/

You can just launch right from our documentation. It’ll ask you for your Datadog API key, which you can find under Integrations > APIs on your Datadog Dashboard.

https://app.datadoghq.com/account/settings#api

Now that we’ve added the integration and forwarder, we can begin to instrument our Lambda function.

We’ll need to is add some more information to our serverless.yml file.

custom:
  datadog:
    flushMetricsToLogs: true
    apiKey: 
    addLayers: true
    logLevel: "info"
    enableXrayTracing: true
    enableDDTracing: true
    forwarder: 
    enableTags: true
    injectLogContext: true

plugins:
  - serverless-plugin-datadog

https://docs.datadoghq.com/serverless/serverless_integrations/plugin/

Our serverless plugin has configuration options that you can use as needed for your specific use cases. You’ll need to add your Datadog API key here.

In addition to the serverless plugin, we’re going to add the AWS X-Ray integration, which lets developers trace distributed applications built using AWS products.

https://docs.datadoghq.com/integrations/amazon_xray/?tab=nodejs

You need to make sure the following permissions are present in the policy document for your AWS/Datadog Role before adding to your code.

'use strict';
const AWSXRay = require('aws-xray-sdk');
const AWS = AWSXRay.captureAWS(require('aws-sdk'));

AWSXRay.captureHTTPsGlobal(require('http'));
AWSXRay.captureHTTPsGlobal(require('https'));

// captures axios chained promises. 
AWSXRay.capturePromise();

const AxiosWithXray = require('axios');

After that we head back to our handler.js file from Part 1. Run npm install aws-xray-sdk and require it in your Lambda function first because you want to catch everything that happens after it’s included.

We add the code for capturing all HTTP and HTTPS traces, as well as capturing chained promises, which is super important since so much of Node.js is promise based.

We’re also going to change the Axios global name to axioswithxray just so we remember we’re catching those responses as well. We’llchange the line in our code that was previously making the Axios call as well.

Run sls deploy one last time so our instrumentation is fully reflected in our serverless function, and that’s all we have to do for our specific use case.

You can see additional documentation for tracing SQL queries and other options on the X-Ray documentation: https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-nodejs.html

Now that we have set up the AWS Integration and instrumented our serverless application, we can begin to have more insight into how our systems are working.

Part 1: How to Build a Serverless Twitter Bot

rachel — Tue, 20 Apr 2021 18:00:29 +0000

This post originates from https://rachelisaweso.me/posts/serverless-lambda-pt1/ and is by Rachel White @ohhoe

So you want to build a Twitter bot? With serverless functions, it’s easier today than ever before—since you don’t need to worry about configuring daemons to constantly run your code or anything else server-side. Welcome to a two post series on building and monitoring a serverless application: in our case, a Twitter bot! In the first post we’ll be looking at AWS Lambda, S3 buckets, and CloudWatch to trigger our function to run. And in the second, we’ll cover setting up a AWS Integration with Datadog so that you can monitor your serverless function.

First let's talk about a brief history. Twitter bots used to be very popular around 2015, before Twitter made it so that you had to apply for a developer account to have access to their API. There are lots of different kinds of bots: some are generative image bots, while others are text based, either tweeting random words mashed together, or Markov chaining data from various corpora.

One great example is @softlandscapes, made by @v21. It uses a tool called Tracery, which generates language and text; bot developers realized they could use its structure to replace elements in SVG, which enables a lot of flexibility with creating generative images. You can see some other bots that are created with Tracery at Cheap Bots Done Quick.

Another great example is @BracketMemeBot, made by Darius Kazemi, who thankfully documents a lot of what he makes. Bracket Meme Bot takes random categories of items from Wikipedia that meet a certain set of guidelines (must have a plural noun in the title, and must have at least sixteen pages)Once it finds some categories that meet the requirements, it picks 16 of them at random and draws them on the bracket. It’s extremely silly, and you end up with brackets for things like ‘SpongeBob SquarePants video games’ and ‘Underground Laboratories’.

I picked one from Darius because he also keeps a GitHub repository of a lot of corpora that a ton of bot makers pull from. You can find at https://github.com/dariusk/corpora.

Now that you understand a bit about where we’re coming from, let’s get into the technical aspects.

Some prerequisites:

Node installed
Serverless Framework CLI installed: https://www.serverless.com/framework/docs/getting-started/
AWS Credentials set up with Serverless Framework for easier deployment (see quick setup): https://www.serverless.com/framework/docs/providers/aws/guide/credentials/
AWS Account
Twitter Developer Account

The first thing we’re going to do is navigate to the folder we want to use for our code and run serverless create --template aws-nodejs

This is going to have the serverless framework set up a node template that’s already compatible with what AWS is looking for. We’ve got two files that are important: the handler.js where we write our bot code, and the serverless.yml file which is defining our provider, production environment, and other variables.

We’ve got to change the ‘service’ name in serverless.yml to something that is relevant to our application name.We can also change the name of the function and handler if you’d like.

Remember that if you change the function’s name in serverless.yml, you will need to make sure that it reflects the name in module.exports as well.

Now we can run sls deploy, which is short for serverless deploy. This will take our files, zip them up, and deploy them to AWS Lambda. Log into your AWS console and navigate to the Lambda Dashboard. Click on the service that has the name you chose in the previous step, so we can make sure everything is connected correctly.

I can see my app showing up in the Lambda service dashboard once I hit sls deploy

Since everything is hooked up, now we can focus on coding our bot. For the sake of simplicity, I’m going to focus on just sending out a single tweet. We’re going to use a Twitter API client for Node.js called ‘Twit’. https://github.com/ttezel/twit

In the same directory you ran the serverless template command, type npm init so we can create our package.json file. You don’t need to change any of the values here. Next, we’re going to run npm install twit.

Now we need to change code in our handler.js file so that we are using the Twit library, and sending our messages out to Twitter.

Starting on line 2 of handler.js, we are going to add the following code, which accesses the Twit library and sets up our credentials. You can find the consumer_key, consumer_secret, access_token, and access_token_secret in the dashboard of your Twitter Developer account:

const Twit = require('twit')

const T = new Twit({
  consumer_key:         '...',
  consumer_secret:      '...',
  access_token:         '...',
  access_token_secret:  '...',
  timeout_ms:           60*1000,  // optional HTTP request timeout to apply to all requests.
  strictSSL:            true,     // optional - requires SSL certificates to be valid.
})

Now we need to change the code inside of our module exports. With the base template that the serverless framework creates for us, we’re just returning a JSON object. We want to set up the code that handles the tweet we’re sending. (https://javascript.info/async-await & https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html) For now, let’s just tweet ‘hello world’. Here is the code for that:

module.exports.hello = async event => {

  const tweetResponse = await new Promise((resolve, reject) => {
    T.post('statuses/update', { status: 'hello world!' }, function(err, data, response) {
      console.log(data)
    })
  })

  return tweetResponse

};

The last thing we need to set up for our Lambda function is a way to trigger it.

Clicking on ‘Add trigger’ will take us to the trigger configuration page.

You can choose CloudWatch Events, and it will walk you through the process of setting up a rule. We created one called ‘tweeting’ which will run our function every 12 hours. You can set this up to run as frequently or infrequently as you want.

And that’s it! Now we have a working Twitter bot. I wanted to keep the example simple so that you can take the bot anywhere you want: you can create images and use Twit’s media upload ability, or play around with NLP models for mashing up words. For more resources on botmaking, check out https://botwiki.org/

Read Part 2: How to Monitor a Serverless Application