The architecture of sibsforever.org

In this previous story,

Becoming a web developer at 66 years old (for my nonprofit)

I described my journey in creating sibsforever.org at the ripe old age of 66. The site is live and hosted on Amazon Web Services (AWS) with active users. AWS gives non-profits $1000 of cloud credits every year, and my goal was not to stray too far from this budget.

What am I building?

SibsForever is a site where siblings who have lost a sibling memorialize their sibling relationship through photos, videos, and words. The sibling relationship extends beyond death and the precious moments, memories, and dreams continue. SibsForever is where these sibs can upload photos and videos; write stories, journal entries, and postings. The community of sib-less sibs using SibsForever can support each other through commenting and sharing. Privacy is configurable down to the individual photo, video, or entry.

Basic Architecture Explained

The sibsforever.org technology stack consists of React, Node.js, Bulma CSS, and PostgreSQL hosted on Amazon Web Services. Below is the architecture diagram:

SibsForever Architecture

Front End

The front-end artifacts (after triggering a React production build) are deployed directly to an S3 bucket and are served up from CloudFront using the closest edge location.

Single-page applications (SPAs) that have their content rendered client-side (in the browser), like sibsforever.org, cannot easily be crawled by search engine indexing bots and therefore do not perform well in search engine rankings. Since SibsForever.org only has nine public pages that do not require authentication, the pre-rendered page source for these nine pages gets returned for all search engine bot traffic using CloudFront functions. This relatively new AWS feature supports the lightweight processing of web requests. This way, the public sibsforever.org pages show appropriately in search engine rankings.

Client-rendered applications can be slow as all web artifacts (e.g., CSS and javascript) are ingested before the initial page rendering. I analyzed the SibsForever bundle to identify heftier, less frequently used packages as candidates for lazy loading. Additionally, big libraries (such as Lodash) don’t get imported. Instead, only the applications' functions get imported, so dead code from these libraries does not load at startup.

I used CloudFront signed cookies to ensure that all CloudFront files (e.g., images, videos, diary entries) accessed by authenticated pages are private. These cookies restrict access to the sibsforever.org domain, giving the SibsForever application full data privacy responsibility. SibsForever has strong security and privacy controls at both client and server levels.

SibsForever does not manage passwords. The authentication methods supported are:

• Login with Google
• Login with Facebook
• Request Login Link — a secure login experience using emailed magic links that, when selected, will log a user into SibsForever.

Back End

The $1000 annual cloud credits can be used for on-demand resources only, so I didn’t look at any savings plan options.

I wanted the backend, which is a Node/Express application, to be resilient, and therefore I chose the following AWS resources:

• Two t4g.small instances in different availability zones. T4g instances are the next-generation low-cost burstable general-purpose instance types that deliver 40% better price performance over the previous generation (T3 instances). Cost=$25/mo
• Application Load Balancer (ALB). I put a CloudFront distribution in front of the ALB to achieve certain security and performance benefits. Security is improved since an AWS Web Application Firewall (WAF) can be integrated with CloudFront. TLS negotiation for more distant viewers from the ALB results in improved performance since the entry into the Amazon network occurs at the nearest edge location. Cost=$17/mo
• The node servers running in EC2 are very lightweight (mostly database access workflows). All heavy liftings get performed in a set of AWS Lambda functions. There are three functions: image processing (using the Sharp library), video processing (using FFmpeg), and scheduled processing. The cost for this tier depends on the number of function calls, but we have not surpassed the free tier limits so far.
• To keep the node servers as lightweight as possible, the client accesses S3 directly to persist image and video files, using multi-part uploads as needed. Short-lived pre-signed URLs get used for uploads.
• Amazon RDS PostgreSQL database (t4g.micro), multi-az for resilience with three days of rolling backups. Cost=$30/mo
• Miscellaneous AWS services, including Systems Manager Parameter Store for secrets; Simple Queue Service (SQS), and EventBridge for scheduled processing

Integrations

• Stripe to support the payment flow for donations
• Google for captchas and authentication
• Facebook for authentication

The total monthly AWS cost is about $85/mo, close to the allotted budget of $1000/year.

What Improvements and Changes are Planned

Since this was my first project using this tech stack, I got better as I gained more experience. Here is an (incomplete) list of tasks from my Trello board:

• During the development of sibsforever.org, several packages I used came out with major releases (with breaking changes). I now have a list of packages that need to get upgraded, and it will take time to integrate and test. This work has to get done to avoid becoming a legacy application.
• I wrote minimal tests during development. As the sole developer, I tested as I went along. I also did a lot of experimentation which was not conducive to rigorous tests. The bottom line is that I have now prioritized automatic testing to avoid using real users as testers.
• I plan to support the domain joinedforever.org to offer this service to anyone grieving the loss of a loved one who wants to memorialize their relationship using this service. I will use the same AWS resources with a separate database (on the same RDS instance), so the AWS bill will not be significantly higher.
• My task list includes a proof-of-concept project migrating the Node/Express API to AWS Fargate. I have a working prototype of this topology that looks cost-effective and does not require significant changes to the software.
• I will write all new code in TypeScript. I’ve completed a TypeScript course and feel ready to embrace it for all future web development.