I would like to showcase the architecture of the website you are currently on. It does look like a WordPress website, hints of it are all over the place: blog canonical urls are in the classic wp format (YYYY/MM/GG/blog-post-title) and a quick check with any inspection tool reveals some resource paths containing wp-content and wp-includes which are a clear give-away that we are facing a website powered by WordPress.
Is it your thought too?
Well, if so, you are not far from the truth. It is based on WordPress, blog posts are written on it but…there is a but…this website is server-less. Everything is statically hosted on S3 and served via a CloudFront distribution. Well, almost everything: contact forms and comments require a backend call to work properly.
Let’s see how the magic happens and let’s start from the AWS architectural design.
Website is developed locally, on a personal laptop, using WordPress which provides, among other things, a huge list of third party plugin to install. I use SimplyStatic to generate static html pages out of your blog.
Once they are generated, a custom script runs and sets proper hostname for links:
- the ones pointing to sections of the website, such as /contact, receive the main domain name (enricobaioni.com) which is configured in Route53 to point to an S3 bucket.
- all the others, get the CDN domain name (media.enricobaioni.com) which has the same bucket as source
Why sections are served through the S3 bucket and not through the CDN?
Because CloudFront doesn’t allow you to set a default object for subpath, it only fetches the default object for the root path (/), while an S3 bucket, configured to host a static website, serves index.html (or any name you specify) for any path. In this way, it’s possible to have /blog route to display content, while, if we were to fetch it via CDN, it should be /blog/index.html.
It's possible to "trick" cloudfront into still following bucket's rules: simply set as cloudfront origin, the url of the bucket configured as web server. Thanks to Francesco Cambiaso for pointing it out!
How do Contact Forms work?
Contact forms require a call to an end point that executes few lines of code to work. There is no way around it! But there is also no need to have it set up on an EC2 instance.
API Gateway addresses exactly our needs: it offers a publicly available end point that can trigger the execution of a lambda function.
When lambda is triggered, it parses the form fields submitted and interacts with SES (Simple Email Service) to shoot an email to a predefined addressed.
Here’s how send-email-from-wp endpoint is configured on API Gateway. It only accepts POST calls, it triggers a lambda function and sends back the response.
How about comments?
Comments are a different beast. While contact forms have a fire and forget kind of lifecycle, comments require persistence. It could be possible to create more API Gateway end points and lambda functions to handle both comment creation and retrieval. It sounds like a simple task, and it is, but it easily gets really time consuming when the concept of comments is developed further. For example, we may want only authenticated users (via facebook, linkedin, google or any other service we may think of) to be able to leave a comment. Also, we may want to be able to moderate them. There is an entire world behind the scenes and getting it right requires time.
So, back to the question for this section, the answer is: I use a third party service.
Disqus developed a very simple way to add comments to your website
Q&A – Feedback
I always look for feedback, so please feel more than welcome to send a message or shoot me an email at email@example.com with your thoughts and questions.
Also, should you be looking for professional consultation, I work as freelance solutions architect.