Last week we wanted to create better social media ...
# guide
j
Last week we wanted to create better social media share images for Serverless-Stack.com. We wanted to generate them dynamically. So we decided to build this in serverless using SST! The entire thing is publicly available on GitHub (https://github.com/serverless-stack/social-cards). We also added a chapter going over the details of how we built it and how it integrates with our static sites. The gist of it is that we create HTML templates that are loaded locally in a Lambda function. It takes screenshots of these using Puppeteer and caches it in S3. We also add CloudFront in front of it with a custom domain. Check out all the details here. https://serverless-stack.com/chapters/dynamically-generate-social-share-images-with-serverless.html
a
So it’s generated in runtime or once and cached?
j
Yeah generated on the first request and cached from that point on.
a
But how it knows when to generate it?
j
There’s a meta tag on our webpages, that Twitter/FB/etc. will hit when you share the URL. That’s what triggers generating the image.
a
I see.
But how we know when to get from cache and when not?
j
We take the request URL and convert it into an S3 key, then check if that key exists in S3.
a
Ohhh nice.
j
Yeah and a CloudFront distribution in front of it all.
a
Yeah cdn makes sense.
a
For those who want a hosted solution my mate runs this: https://ogimpact.sh/
j
Would you at some point move the AWS Chrome Layer into the SST config instead of hardcoding it?
j
@justindra Sorry I missed this. What do you mean by moving into the SST config?
j
All good @Jay! I mean would we be able to define these installable lambda layers through SST/Cdk instead of hardcoding an arn.
I'm assuming future state that is
j
Interesting, so being able to specify them by name instead of their ARN?
j
Yep exactly. I think that would be a lot more re-deployable when creating new environments etc.
j
cc @Frank