Why does this site exist?
A long-standing problem with learning any new technology is that most of the documentation and examples you might get on the internet or from the AIs are so trivial that they give you no idea whether the technology or your implementation of it will withstand a real, complex workload. An example of this is the numerous to-do list examples.
I have a SASS project planned based on several technology assumptions that need testing before even attempting to build the real project, and a personal profile site like this, driven by a complete CMS backend, is just about complex enough to deserve a proper production buildout and simple enough not to take too long putting together; with the additional benefit, if all goes well, I get a profile site that performs well and will be a good testbed for more technical experiments.
Cloudflare as a deployment target
Cloudflare Workers https://workers.cloudflare.com/ seem, at first glance, to be an extremely cheap way to deploy a complex application. Back-end development looks simple and robust, and the OpenNext https://opennext.js.org/ package appears to provide an efficient way to develop your front-end in Next.js https://nextjs.org/ and deploy to Cloudflare.
I doubt this site will attract much human traffic; however, I will attempt to push as much web search and AI crawler traffic to it as possible. That way, I should be able to figure out the actual cost of running a busy site on Cloudflare’s platform.
Make this site more complicated than it should be
Content Management Backend (CMS)
In all honesty, this site, as it currently stands, could be cobbled together with a coding agent in a few hours; however, a serious system should not need a deployment to change basic content. Therefore, this site uses a full CMS based on Payload CMS (https://payloadcms.com/) deployed as a separate Cloudflare Worker.
Payload itself uses a SQL database, which in turn needs to be deployed as a CloudFlare D1 SQLite database instance https://developers.cloudflare.com/d1/, and properly managed with database migrations to support the development lifecycle.
Automated translations
This site supports 20 languages. Given that the website is a simple scaffold for the CMS content, the i18n side is handled with a coding agent (Co-pilot and Claude Opus 4.5) during development.
That leaves all current and future CMS content needing to be automatically translated whenever any English content is changed.
Queue and Cron-Based Worker
The translation requirement requires a reasonably complicated process that:
- Will trigger on a Cron timer.
- Identify any content that needs a new translation.
- Reliably execute a translation.
- Reliably recover from a failure.
Therefore, another CloudFlare D1 instance is used to track translation work, and Cloudflare queues (https://developers.cloudflare.com/queues/) are used with a cron-based producer-consumer pattern to manage and scale the tasks. OpenAI’s gpt-5.2 API is called to do the translations and AI.SDK https://ai-sdk.dev/ hooks it all together.
For this site, it is overkill, but any production system, at any scale, needs a robust pattern to orchestrate background processing.
Previous versions of this site
I have done this site twice already as a tool to learn new technologies:
2013 - Learning Ruby and AWS
- Ruby on Rails v4.0.0.
- Bootstrap styling v3.
- CoffeeScript for the UI.
- Backbone Marionette VMC front-end pattern.
- Deployed on an AWS host.
2017 - Learning React
- React v16.0.0 for UI.
- Redux and Thunk for asynchronous operations.
- Semantic UI for styling.
What next
The site is properly hooked up for SEO, and a regular cadence of new content is needed to drive crawler traffic. I will be posting more detailed articles on the various technologies and solutions used.