AWS

API Diversions

Experimenting with a new API via Cloudflare workers.

James Montgomery

5 minute read

TL; DR Recently reinvigorated with my new UI work, I set myself to task with simplifying the front end player code. No matter how I looked at it, I’d needed to rewrite the back end API to support a front end rewrite. But what if I didn’t precisely need to do that? Enter stage left, Cloudflare Workers. Below I explain how I arrived at this. If you would like to view the Worker code, you can do so here.

New UI for my text-to-speech player

I revisit the UI, hoping to improve the general experience.

James Montgomery

3 minute read

TL; DR My previous user interface (UI) could be, at best described as functional. Whilst it technically worked on any platform I tested, a desktop browser received the best experience. Recently @suivethefirst recommended Bootstrap to me. So I tried to make a better experience with this. Putting the minimum into MVP Putting together the UI as it stood was the last functional step in my project. Delivering an audio player with a combination of CSS and JavaScript felt beyond what I had in the tank at the time.

Migrating site to AWS

Moving to AWS Amplify and Cloudflare.

James Montgomery

2 minute read

TL; DR Some time ago, I decided to multi-cloud my site. I’ve recently decided to revert to a single cloud hosting provider. I’m taking the opportunity to experience Amplify static hosting for this site. Challenges with the previous configuration Multiple hosting locations meant multiple build processes. In effect, the site was built, deployed (to Firebase) then rebuilt and redeployed (to AWS). Admittedly, the latter was rarely an overhead as the AWS Amplify CI/CD workflow was triggered upon commit to the master branch on CodeCommit.

Introducing async to my serverless text-to-speech player for jokes and quotes

Using AWS components, Cloudflare, and public APIs.

James Montgomery

3 minute read

TL; DR In this post, I revisit my serverless “jokes and quotes” player. The purpose was to remove the tight coupling between the client request and audio playback API source. To explore the issue, I have introduced DynamoDB to store pre-generated results. Challenge overview Logically, all the components of my existing solution depend on each other to succeed to deliver audio to the client. You can visualise it as follows:

A Serverless text-to-speech player for jokes and quotes

Using AWS components, Cloudflare, and public APIs.

James Montgomery

2 minute read

TL; DR I decided to dust off my text-to-speech list, implementing a serverless solution delivering random jokes and quotes. You may visit it at this address: https://tts-ja.mesmontgomery.co.uk/ You can get a preview of the joke quality here: Your browser does not support the audio element. Note: I can’t affect the humour quality 🤣. Solution overview Upon visiting the page, an event triggers calls to the API routes for their relative jokes and quotes.

Backup of Cloudflare DNS to AWS DynamoDB

Using AWS Lambda to copy records into DynamoDB via the Libcloud library

James Montgomery

5 minute read

TL; DR After a short break, I decided to take an item off the project list. DNS is a rich source of inspiration for me - and so I elected for a quick win in the form of serverless DNS records backup. The goal of which is to backup my DNS zone contents, via functions as a service (FaaS) and storage as a service (object or database). You can find all the associated code for this on my GitHub page.