Is anyone else beyond sick of seeing AI shoved into absolutely everything, like it's the new sriracha? Why did my dishwasher need AI included in it?!?! What's next, are they going to shove AI in my toothpaste?
On the first attempt of writing this post I followed a workflow similar to the one discussed below, using AI to scaffold the body of the post, but this lead to an obvious outcome. The whole thing read like it was written by AI(duh). This was also blatantly hypocritical given my rants at the beginning and frustration over all the AI slop out there. There was only one path forward, I trashed the original and rewrote it the "old school" way. I'm writing directly in markdown, will use spellcheck, and have some human reviewers but no AI writing.
Let me get back on track here, since this is supposed to be about how I use AI in the context of software engineering. To me AI is purely another tool in my ever expanding toolbox; sitting comfortably on the shelf next to many other tools.
The usefulness I find in AI as a tool is predominately faster "googling" and non-deterministic automation.
With it I am able to research an error, bug, or potential solution via multiple sources in a more rapid fashion than manual searching. Is it perfect? No. This is clear from one of my most frequent prompts being:
Can you please provide links to the documentation you are referencing?
Documentation This one is kinda related to the next item in the list but I wanted to call it out specifically. If you need to write documentation for a chunk of code or create a readme for a project you're new to, AI can be great. The documentation it creates still requires careful review but significantly faster and less brain melting than writing documentation completely by hand.
Scaffolding I rarely use fancy IDE's that have features for spitting out templated or boilerplate code so I leverage AI for scaffolding out the code that I have already handwritten in the past; once scaffolded the code can be reviewed with a fine tooth comb and have any adjustments made that are needed.
Research The context within which I operate often varies massively day to day (sometimes hour to hour); writing a script one moment, followed by debugging an API, followed by tweaking firewall rules, and then deploying some infra. This makes it extremely valuable to be able to do things like
Rubber Duck Sometimes there is no human available and due to the non-deterministic nature of LLM responses they can be used to think through potential solutions or weird edge cases.
Learning Tool Basically the polar and principally opposite idea to "vibe-coding". I never blindly accept a line of code or a change proposed by an AI tool. If I don't understand what the code does, it's not getting committed. I will stop and have the tool explain character by character, over and over, until I fully understand it.
Currently my workflow looks like this:
Have a real problem to solve. Not some tutorial exercise or hypothetical that has no real world use.
Delve through the dark caverns of my brain searching for prior experience with a related problem and come up with some potential solutions. This is required, brain must be exercised regularly.
When a fellow human isn't available, I'm sick of talking to myself, or more feedback is needed than what my dog can provide I'll use an AI tool as a rubber duck. I'll use it to rip apart the potential solutions from step 2 or surface potential solutions that may not have occurred to me.
Once a path forward is decided on, think through how to break the work into workable chunks. Repeat this step as many times as needed to not feel overwhelmed.
Scaffolding - I really enjoying working with computers so if there are things for a solution that I have memorized, can quickly scaffold myself while enjoying my creamy keyboard, or something I want to learn I will do it without any AI involvment. The biggest constraint here is the amount of time available for a task. Sometimes you have a problem that needs to be solved as quickly as possible for whatever reason and in those situations I will use any tool available. Given infinite time I would spend time on every char, tracing every bug, perfectly optimize resource usage, or creating the perfect user experience. But unfortunately we don't have the watches from Clockstoppers, yet!
Scaffolding with AI - Describe the current piece of the problem being attacked in as much detail as possible. Being hyper specific with what you want will reduce the frustration that future you feels, sometimes.
Only when 100% understanding is achieved will the proposed action be allowed to be taken. This is for two main reasons. First, because I have been burned in the past by not following this rule. Second, it allows me to continue to gain knowledge along the way.
Review all of the generated code with a flea comb to find errors, vulnerabilities, edge cases, and adherence to specifications - triple check EVERYTHING.
Fix anything that is wrong and revise things that I don't like. For example I can't stand "magic" code that someone with no context of the project can't easily understand. If some random engineer can't there is a high probability that future you won't understand either.
For the non-deterministic automation I'm referring to tasks like "scaffold me a readme for this Github action I created" or "create an api endpoint based on this existing one". I'm open to at least trying AI tools to assist with things that don't depend on repeatable logic that is guaranteed to perform the exact same actions every single time. Often times I will use an AI tool to assist in scaffolding the code to build deterministic automation. There are many situations where the risk of having an agent do something completely off the wall based on a prompt is simply not worth it. The idea of the "DevOps" or "SRE" agents with the access required to resolve a production incident from a novel root cause gives me the heebs.
Take as an example (an overly simple one) the prompt:
create a local branch, fix error X, and push those changes
This could be executed in fundamentally different ways depending on the model being used, the context the agent has, or which way the wind is blowing. Even when you specify in the agents config, the specific way that it is supposed to complete specific tasks there is no guarantee that it will follow the exact same steps every single time.
AI can speed up the completion of tasks that don't require critical thinking or deterministic outcomes; things like drafting a readme for a chunk of code. That being said reviewing AI generated code is a time suck which requires you to be constantly on guard. AI will confidently propose things that are total garbage and your knowledge/experience is the final safe guard.
I may be biased from working in software engineering but the constant stream of redacted that "AI" will make software engineers(and related roles) obsolete is not occurring anytime soon based on the capabilities I have seen. There is a massive gap between vibe coding an app that would be at best considered a POC and successfully engineering a piece of software that can run for years on end. Software that can scale when needed, stable under load, adapt when a capability is missing, and valuable to the user.
It should also not be ignored that most of those hyping the capabilities of "AI" have a direct financial interest in the products success. That's not a reason to blindly dismiss the technology, but it is a reason to be skeptical of the marketing spiel.
AI tools are interesting but hardly the magical thing they are hyped as. Do I use it? Yeah, where it makes sense; but if it disappeared tomorrow I'd be perfectly fine.
Always say "Please" and "Thank you" when prompting AI, you know, just in case... oh and never stop learning!
]]>API Gateway routes all three endpoints to the same Lambda function. The handler reads the route from the event and dispatches:
def handler(event, context):
route = event.get("routeKey", "")
if route == "POST /subscribe":
return handle_subscribe(event)
elif route == "GET /confirm":
return handle_confirm(event)
elif route == "GET /unsubscribe":
return handle_unsubscribe(event)
return {"statusCode": 404, "body": json.dumps({"message": "Not found."})}
Example code: subscribe/index.py
The subscribe flow:
confirmed = falseDuplicate signups return the same generic success response as a new signup. The initial code Claude generated returned {"message": "Already subscribed."} for duplicates, but that's visible in browser dev tools even when the frontend hides it, which leaks subscriber status to anyone who pokes the API directly. Fixed by returning an identical response either way.
The subscribe endpoint is public, so it needs abuse protection beyond rate limiting. Cloudflare Turnstile (managed mode) is added to the subscribe form. The widget runs in the browser and produces a token that the Lambda verifies with Cloudflare's siteverify API before doing anything else.
The Turnstile secret is stored in SSM Parameter Store as a SecureString. It's fetched outside the Lambda handler so it's reused across warm invocations. SSM standard parameters have no per-call cost, but the fetch still adds latency on cold starts, so keeping it out of the hot path matters.
The confirm link in the email points to mydomain.com/confirm?token=...&email=..., a Docusaurus page that calls the API on load and renders a success or error message. (Claude's initial implementation pointed directly to the API endpoint, which just dumped raw JSON at the user.)
The Lambda confirm flow:
token and email from query string parametersconfirmed = true in DynamoDBToken and email are URL-encoded in the confirmation link to handle special characters safely.
The unsubscribe link in every email footer works the same way: GET /unsubscribe?token=...&email=.... The Lambda validates the token, then deletes the item from DynamoDB.
token is a DynamoDB reserved word. Using it directly in a ConditionExpression throws a ValidationException at runtime, not at deploy time and not in local testing, unless you're hitting real DynamoDB. The fix is to use ExpressionAttributeNames:
response = table.update_item(
Key={"email": email},
ConditionExpression="attribute_exists(email) AND #tok = :token",
ExpressionAttributeNames={"#tok": "token"},
ExpressionAttributeValues={":token": token, ":confirmed": True},
UpdateExpression="SET confirmed = :confirmed",
)
This one only showed up after the first real confirmation attempt.
On the first test send, SES returned MessageRejected. In sandbox mode, both the sender AND recipient address must be verified in the console: it's not enough to have a verified sending domain. Either verify the recipient manually or request production access. For a personal blog newsletter with double opt-in, production access was approved the same day within a few hours.
At small scale, the subscribe Lambda costs essentially nothing:
The poller is a second Lambda, fired by EventBridge on a daily cron. It fetches the RSS feed, checks whether anything is new, emails every confirmed subscriber if so, and updates a cursor.
def handler(event, context):
last_seen = get_last_seen()
new_posts = fetch_new_posts(last_seen)
if not new_posts:
return
subscribers = get_confirmed_subscribers()
for post in new_posts:
send_to_all(post, subscribers)
update_last_seen(post["published"])
Example code: poller/index.py
The feed is fetched with urllib.request.urlopen with a 10-second timeout. No third-party dependencies: the feed is straightforward XML and xml.etree.ElementTree handles it fine.
Error handling covers the two likely failure modes:
try:
with urlopen(RSS_URL, timeout=10) as response:
xml_content = response.read()
except URLError as e:
logger.error("Failed to fetch RSS feed: %s", e)
raise
ET.ParseError is also caught separately in case the feed is reachable but returns malformed XML. In both cases the Lambda raises so EventBridge can log the failure. Silent swallowing would make it hard to notice the poller has stopped working.
last_seen is stored as an ISO 8601 timestamp in DynamoDB, in a dedicated item with a fixed partition key (SYSTEM#last_seen). It's separate from subscriber records: same table, different key prefix.
On first run, last_seen doesn't exist yet. The poller treats a missing value as "never run" and emails all posts in the feed. In practice this means you should set last_seen manually (or let the first run email everything) before subscribing real users.
The diff is a simple comparison: post["published"] > last_seen. Posts are sorted oldest-first so emails go out in chronological order if multiple new posts exist on the same day.
The poller uses the confirmed GSI to query only confirmed subscribers, avoiding a full table scan:
response = table.query(
IndexName="confirmed-index",
KeyConditionExpression=Key("confirmed").eq(True),
)
The query handles LastEvaluatedKey pagination so it works correctly as the subscriber list grows:
kwargs = {"IndexName": "confirmed-index", "KeyConditionExpression": Key("confirmed").eq(True)}
while True:
response = table.query(**kwargs)
subscribers.extend(response["Items"])
last_key = response.get("LastEvaluatedKey")
if not last_key:
break
kwargs["ExclusiveStartKey"] = last_key
Each confirmed subscriber gets a plain-text and HTML email with the post title, a short excerpt from the RSS description, a link to the post, and an unsubscribe link in the footer. No tracking pixels, no open rates, no click tracking.
The unsubscribe link is constructed from the subscriber's stored token:
https://mydomain.com/unsubscribe?email=...&token=...
Both email and token are URL-encoded. The HTML email body escapes RSS content (title, description, link) before embedding, as RSS feeds occasionally contain characters that would break an HTML template.
SES failure is caught per-subscriber. If a send fails, the error is logged and last_seen is not advanced for that post, so the next run will retry. This means failed sends can result in duplicate emails if the failure was transient, but it's preferable to silently skipping subscribers.
If EventBridge fires the Lambda twice in a day (rare but possible), the second run will find last_seen already advanced and send nothing. That's the correct behavior.
last_seen only advances after a successful send batch. If the Lambda errors mid-run, it will retry the whole batch on the next invocation. At the scale of a personal blog newsletter, occasional duplicate emails are acceptable. The alternative (distributed transactions across SES and DynamoDB) isn't worth it.
At small scale, the poller costs essentially nothing:
The items below were either caught during review of Claude's generated code or checked for based on architecture:
No SQL injection surface (both Lambdas): DynamoDB has no query language that accepts raw strings. All operations use the AWS SDK's structured API: keys, update expressions, and condition expressions are parameterized via ExpressionAttributeValues, so user input is always passed as a typed value and never interpolated into an expression. There is nothing to inject into.
Input validation (subscribe Lambda): email format checked with a regex, hard-capped at 254 characters. UUID format checked on tokens before any DynamoDB call. This avoids wasting a DynamoDB read on obviously invalid input.
Domain typo detection (subscribe Lambda): a lookup table of ~40 common misspellings across Gmail, Yahoo, Hotmail, Outlook, and iCloud is checked before anything else. If the submitted domain matches a known typo, the endpoint returns a 400 with a "Did you mean user@gmail.com?" message instead of silently accepting an address that will never receive the confirmation email. This is purely a UX call: a valid-format address that happens to be a fat-finger will pass regex validation just fine, so the only way to catch it is an explicit list.
URL encoding (both Lambdas): email and token are URL-encoded in confirmation and unsubscribe links via urllib.parse.quote. Without this, special characters in email addresses (valid per RFC) would silently corrupt the links.
HTML escaping (both Lambdas): confirmation URLs embedded in HTML email bodies are escaped before insertion. RSS content in the poller (title, description, link) is escaped before going into the HTML template.
No email enumeration (subscribe Lambda): subscribe returns the same response whether the address is new or already exists.
Token design (subscribe Lambda): tokens are UUIDs generated at subscribe time, stored in DynamoDB alongside the subscriber record, and validated on confirm and unsubscribe. They're not guessable, not reused, and not derived from the email address.
SES failure handling (both Lambdas): Claude's initial code silently returned 200 if SES threw an exception. Both Lambdas now catch, log, and return 500.
Reserved concurrency: not applied. AWS reserved concurrency caps and reserves at the same time, there's no way to just limit without also reserving capacity. The account's total concurrency limit is exactly 10, which is the minimum AWS requires to remain unreserved across the account, so setting any reserved concurrency at all fails with a 400. API Gateway throttling is the blast radius protection here instead.
source_account on Lambda permissions (both Lambdas): API Gateway and EventBridge are shared AWS services. Without a source_account condition on the Lambda invoke permission, the permission effectively says "any account's API Gateway can invoke this function." Adding source_account = your_account_id scopes it to your account only, preventing a confused deputy attack where a malicious actor with your Lambda ARN configures their own API Gateway to invoke it.
Hardcoded domain (poller Lambda): the initial code suggested by Claude hardcoded the API domain directly in the Lambda. Fixed by reading API_DOMAIN from an environment variable, which Terraform sets from a variable. Keeps the code deployable to a different domain without touching the source.
SPF, DKIM, and DMARC all passed on the first live send (Terraform configures all three). Despite that, Thunderbird flagged the confirmation email as junk (found this thanks to a brave volunteer). A brand new sending domain with zero history has no reputation signal for mail clients to work with, so some will err on the side of caution regardless of authentication results. Not much to do about this except send mail consistently over time and let the reputation build.
An improvement I made over Claude's initial code: adding a List-Unsubscribe header to all outbound emails. It gives mail clients a machine-readable unsubscribe path and is a strong signal that you're a legitimate sender. SES's send_email API doesn't support custom headers, so this required switching to send_raw_email and constructing the MIME message manually using Python's stdlib email.mime classes. More code, but no new dependencies. The List-Unsubscribe-Post header enables one-click unsubscribe (RFC 8058), which major mail clients now expect.
That's the full system: four posts covering a weekend project that now actually runs in production. The architecture isn't novel, but the details in each layer are where the interesting decisions live: OIDC over static keys, GSI over scan, double opt-in over server-side trust, Turnstile over WAF.
I refuse to hide the fact that I leveraged Claude to scaffold out the starting code, but there are critical aspects to my workflow that I adhere to when using any AI tool(sounds like a good blog post topic for the future). The issues flagged in this post - email enumeration, raw JSON confirmation responses, silent SES failure, missing List-Unsubscribe, are a good illustration of what that collaboration actually looks like in practice. The generated code was a solid starting point, but knowing enough about the problem to spot where it fell short mattered just as much as the speed of getting there.
This is part of the Blog Subscription Service series.
]]>A note on process: the architecture and design decisions here are my own, but I used Claude to help scaffold the initial Terraform and Lambda code. The example files linked throughout this post reflect that collaboration.
The infrastructure lives entirely in infra/terraform/. There's no module abstraction - everything is flat. A future post will go through refactoring the code into modules; I wanted to be able to show the progression from flat terraform to using modules because I know this was tricky to wrap my brain around when I started. For now, the flat structure makes it easier to see exactly what Terraform is doing before introducing that layer of organization.
Resources deployed:
subscribe, poller)The API uses the HTTP API type (v2), not REST API. HTTP APIs are simpler to configure and cheaper - REST APIs cost roughly $3.50/million requests, HTTP APIs cost $1/million. For a personal blog, the savings are negligible, but there's no reason to use the more expensive one.
Three routes, all pointing to the same Lambda:
POST /subscribe - new subscriber signupsGET /confirm - email confirmation link targetGET /unsubscribe - unsubscribe link targetThe API sits behind a custom domain at api.mydomain.com, with an ACM certificate and a Route53 A record (alias) pointing at the API Gateway domain name. TLS is handled by ACM - no certificate management needed.
Throttling is configured on the $default stage via default_route_settings with low sustained and burst limits. This stops scripted abuse without needing WAF, which runs at minimum ~$5-6/month.
Example code: api_gateway.tf
Both Lambda functions are Python 3.12. Terraform zips the source at plan time using the archive_file data source, so the zip is built locally before any AWS API calls are made. The resulting zip paths are referenced by the Lambda resources.
Each function gets its configuration via environment variables - table name, SES sender address, domain - so nothing is hardcoded in the Python source.
Each function gets its own IAM execution role. Claude initially scaffolded a single shared role, but I split them in the spirit of least privilege - the poller has no business touching the Turnstile SSM parameter, and a shared role would give it that access for free. The subscribe role needs: DynamoDB read/write, SES SendEmail, and SSM GetParameter (for the Turnstile secret). The poller role needs: DynamoDB read/write and SES SendEmail - nothing else.
The Lambda zip artifacts from tf:plan are uploaded as CI artifacts and downloaded by tf:apply in the same pipeline. This is why tf:apply uses dependencies on tf:plan - artifacts don't persist across pipeline boundaries.
Example code: lambda.tf | iam.tf
Single table (blog-subscribers) with email as the partition key. Each item stores:
email - partition keyconfirmed - boolean flagtoken - UUID used to validate confirmation and unsubscribe linkslast_seen - timestamp used by the poller (stored in a dedicated item, not on subscriber records)The poller needs to query only confirmed subscribers. A full table scan would work at small scale, but a GSI on the confirmed attribute is the right pattern - it lets the poller use a Query instead of a Scan, which is both cheaper and faster as the table grows.
Two sanity saving settings worth enabling via Terraform:
deletion_protection_enabled = true - prevents the table from being accidentally deleted via the console or a Terraform mistakepoint_in_time_recovery { enabled = true }) - allows restoring to any second in the last 35 daysOne gotcha: token is a DynamoDB reserved word. Any ConditionExpression that references token directly throws a ValidationException. The fix is to use ExpressionAttributeNames={"#tok": "token"} and reference #tok in the expression.
Example code: dynamodb.tf
SES handles all outbound email from contact@mydomain.com. Three things are configured via Terraform:
mail.mydomain.com as the envelope sender domain, which improves deliverabilitySES starts in sandbox mode, where it can only send to verified addresses. In order to send to addresses that are not pre-verified, production access is required. Approval from AWS came through the same day within a few hours.
Example code: ses.tf
A single scheduled rule runs the poller Lambda daily. The rule uses a cron expression targeting a fixed UTC time. EventBridge needs permission to invoke the Lambda - this is granted via a aws_lambda_permission resource with principal = "events.amazonaws.com" and the rule ARN as the source.
Example code: eventbridge.tf
Terraform state lives in S3 (mydomain-terraform-state) with versioning enabled. Versioning is worth the negligible storage cost - it lets you roll back a corrupted state file without losing everything.
State locking uses S3 native locking (use_lockfile = true) rather than DynamoDB. DynamoDB-based locking was deprecated in Terraform 1.10.
Example code: backend.tf
Part 4 covers both Lambdas - the subscribe, confirm, and unsubscribe flows, the security decisions behind them, and how the daily poller fetches the RSS feed and emails confirmed subscribers.
This is part of the Blog Subscription Service series.
]]>The lazy approach to Terraform in CI is to create an IAM user, generate an access key, and paste it into a CI variable. It works, but it comes with real downsides:
OIDC solves all of this. GitLab acts as an identity provider, and AWS grants temporary credentials to CI jobs that can prove they came from the right project and branch. The token expires when the job ends, nothing to rotate, and nothing to leak.
When a CI job runs, GitLab injects a short-lived JWT into $GITLAB_OIDC_TOKEN. That token is a signed assertion from GitLab that says "this job ran in project X, on branch Y, triggered by event Z." AWS STS accepts that token via AssumeRoleWithWebIdentity and returns temporary credentials scoped to the role.
The CI job writes the token to a file and sets an environment variable so the AWS SDK picks it up automatically:
before_script:
- echo $GITLAB_OIDC_TOKEN > /tmp/web-identity-token
- export AWS_WEB_IDENTITY_TOKEN_FILE=/tmp/web-identity-token
- export AWS_ROLE_ARN=$AWS_ROLE_ARN
- export AWS_REGION=us-east-1
Writing the token to a file rather than passing it as a shell argument keeps it out of process listings and CI logs. The AWS SDK exchanges it for short-lived credentials automatically on the first API call, no explicit sts assume-role-with-web-identity call needed.
Done once via the AWS Console: IAM → Identity providers → Add provider → OpenID Connect.
https://gitlab.comsts.amazonaws.comAWS validates well-known providers against its own root CA store, no manual thumbprint retrieval needed.
IAM → Roles → Create role → Web identity. The role is named your-role-name, scoped to the your-group/your-project project. The reference path is left blank, meaning any branch can assume the role. Restricting apply to main is handled in CI rules instead, which lets tf:plan run on feature branches to validate changes before merging.
The trust condition this generates:
gitlab.com:sub = project_path:your-group/your-project:ref_type:branch:ref:*
The lazy part of my brain of course wanted to use AdministratorAccess, but we can do better. The role gets two things:
your-role-name-boundary): a hard cap on what the role can ever do, even if someone attaches a broader policy later. Scoped to the exact services this project uses.your-inline-policy-name): the actual permissions needed to deploy: Lambda, API Gateway V2, DynamoDB, SES, EventBridge, ACM, Route53, CloudWatch Logs, IAM (scoped to your-prefix-* roles only), and S3 (scoped to the state bucket).The important thing about permission boundaries: both the boundary and the inline policy must allow an action for it to go through. When debugging, check both. I hit this multiple times: once when the boundary had a one character typo in the bucket name, and again when iam:CreateServiceLinkedRole was missing, both surfaced as 403 AccessDeniedException errors mid apply.
A few permissions that were missed until the first deploy (required in both policy and boundary):
events:ListTagsForResource: Terraform reads tags when refreshing existing EventBridge rulesiam:CreateServiceLinkedRole (scoped to API Gateway SLR): API Gateway needs a service-linked role on first use in a regionlambda:ListVersionsByFunction, lambda:GetFunctionCodeSigningConfig, etc.): all called by the AWS provider when refreshing existing Lambda statetf:validate: runs automatically on any branch when infra/ changes. Catches syntax errors cheaply before a plan.tf:plan: auto on MR pipelines and on main after merge when infra/ changes (so the diff is visible in the MR UI before merging); manual on other branch pushes with infra/ changes (this manual plan could be automatic but I do stupid things and I don't want plans running for no reason).tf:apply: manual trigger, restricted to main only, when infra/ changes. Depends on the tf:plan artifact from the same pipeline; artifacts don't cross pipeline boundaries, so plan and apply must run in the same main pipeline. (I also plan to create some policy checks in the future that will enable automatic apply in certain, non-destructive situations.)The plan produces a JSON report (terraform show -json tfplan > tfplan.json) uploaded as a reports: terraform artifact. GitLab (in theory) renders this as a summary in the MR UI showing resources to add, change, or destroy.
One gotcha worth noting: the Terraform Docker image sets its entrypoint to terraform, which breaks all non-terraform shell commands in before_script. The fix:
image:
name: hashicorp/terraform:1.15.2
entrypoint: [""]
Two variables stored in GitLab CI settings:
AWS_ROLE_ARN: the ARN of the your-role-name role. Not a credential, so it's fine unprotected, but set as masked.TF_VAR_route53_zone_id: the Route53 hosted zone ID for mydomain.com. Also unprotected and masked.Both must be unprotected because tf:plan runs on feature branches, and protected variables are only injected on protected branches. Restricting apply to main in CI rules is sufficient access control. There are ways to lock this down tighter but this should be sufficent to protect me, from myself.
The TF_VAR_ prefix is the clean way to pass Terraform variables through CI; Terraform picks them up automatically without any extra configuration.
Part 3 goes deeper into the Terraform itself: the actual resources, how they're organized, and a few design decisions worth explaining.
This is part of the Blog Subscription Service series.
The blog runs on Docusaurus, deployed to GitLab Pages. It already generates an RSS feed at /blog/rss.xml. What I needed was something to watch that feed and email subscribers when a new post drops, plus a way for people to sign up and manage their subscription.
The requirements were simple:
No tracking pixels, no analytics, no third-party data sharing.
The honest answer is that it's more interesting to build. But there are more legit reasons too:
The whole thing runs on AWS, managed with Terraform (I'm pretty new to mermaid so these should improve as time goes on) :
API Gateway (HTTP API) sits at api.mydomain.com and routes three endpoints to a single Lambda: POST /subscribe, GET /confirm, and GET /unsubscribe.
DynamoDB is a single table blog-subscribers with email as the partition key. Each item stores the email, a confirmed flag, and a UUID token used to validate confirmation and unsubscribe requests. A GSI(Global Secondary Index) on the confirmed attribute lets the poller query only confirmed subscribers efficiently.
SES handles all outbound email from a custom domain address. Domain identity, DKIM, and a custom MAIL FROM domain are all configured via Terraform.
EventBridge triggers the poller Lambda on a daily cron. The poller compares the RSS feed against a last_seen timestamp stored in DynamoDB and only sends emails for new posts.
This isn't a marketing platform. There's no open tracking, no click tracking, and no segmentation. It's a plain-text (and HTML) email that says "new post dropped, here's the link." That's it.
The next post covers the CI/CD setup. How GitLab authenticates to AWS without storing any credentials and how the permission model is structured to limit blast radius.
This is part of the Blog Subscription Service series.
]]>After completing the intial setup of benjaminheath.dev I wandered around for a while in my mind wondering what do next? I could make any number of random projects to illustrate that I have used terraform, aws, etc before, but the question is WHY?
After sitting for a while I started to research adding either an RSS feed or a email subscription functionality to the blog for the weirdo's out there who actually find interest in my rambles. I found some SaaS solutions that would work for this functionality but then it dawned on me, what if I built it and use that as the content for one or more blog posts?
More to come on that in an upcoming post!
]]>