First, what’s rich social sharing?

You know the cards that pop up on Twitter, Facebook, LinkedIn, etc when you post a link into your “New Post/Status/Tweet/Content” box?

That’s enabled by Rich Social Sharing — and a protocol called Open Graph. You can specify what the image is, what the title says and what the description is…among other things!

Normally on a static HTML page without a lot of JavaScript state management, it’s easy and simple to generate the required <meta> tags because the page isn’t going to change a lot after initial load.

However, with a complex single page app that does something important after the first load, our <meta> tags might not be quite so simple to generate. It makes it even more complicated if you don’t have a dedicated server to generate your <meta> tag content on the fly! The normal and traditional solution would be to create your HTML and <meta> tag content on the server before sending it to the client. This is a technique called Server-Side Rendering. But what if you don’t want to go down that road if you don’t have to?

Serverless Single Page React Apps

Imagine you have a fairly complex Single Page App, hosted on a serverless AWS architecture that requires Rich Social Sharing. What next?

At Concept3D, our team is developing a new product built on a serverless application framework with all Front End React assets being hosted on S3 and distributed via Cloudfront. The API layer is developed using the serverless framework and express.js, which is ultimately triggered via a Lambda function via API Gateway. One of the requirements of this application is the enabling of Rich Social Sharing.

The majority of rich social content is generated utilizing Open Graph meta tags which rest in the <head> as <meta> tags. Now, with a dedicated server that serves up static JS content, this would be a no big deal….but since our API and our Frontend apps are completely disjointed, we needed another solution.

Basically, a server without a server. In came Lambda@Edge!

Lambda@Edge to the rescue!!

Lambda@Edge was developed with this kind of issue in mind! Before going forward and actually trying to implement anything below for your own application, I suggest you read all about setting up Cloudfront Distributions and using Lambda@Edge.

Basically, Lambda functions sitting “on the edge” of your Cloudfront distribution will intercept requests and/or responses and have a chance to do something with them before ever hitting your origin code — which, in our case, is our React App.

High level, here’s what we wanted to do.

When a request from a social site comes to our domain, check if it’s Facebook, Twitter, Linked-In, Google, or some other form of social sharing we would like to implement. If yes, parse the URL and determine the state of the React app that is being shared. Retrieve the relevant information from our DynamoDB and send back only the required information in the form of static Open Graph meta tags, with no JavaScript. If no, pass the request on to the origin React App as this is just a normal browser request from a typical user of the app.

I’ll go into some more detail and code below