The Serverless Spree

Me (and Claude) have been busy while I adjust to Dartmouth and get ready for my first day of class on Monday. I've been working on a lot of projects in the serverless space, and thought I'd quickly highlight a few to watch.

AI and I

Despite still being 18, my coding throughput is now constrained to two areas: academic output and longevity in a senior ecosystem. It sounds cynical to say, but I have learned pretty much everything I want to learn when it comes to programming as of now. I'm moving toward different things, especially within the context of what I would like to study in college. I'm also thinking about Quantitative Research/Trade, which is a very time-consuming skill to learn and investigate and maintain all of these projects as well. Thus I feel like the way that I am using Claude to help speed up the implementation bits and details is justified. Sure, I could spend a year or two recreating and hand polishing all of these projects by hand. cmdfx was AI-free until May, and I didn't even fully finish it until mid-summer. So I believe that I could do it, but do I have the time to do it, and is it something worth learning the exact, meticulous process about? Or could I learn the same thing with Claude or Codex, in an hour or two, and direct it on what to do next?

This is what I believe separates AI slop from AI-powered development. My coding background in the pre-AI era has allowed me to understand the underlying patterns and principles when it comes to scaffolding, designing, debugging, and publishing a piece of software, not just half-baked, presented information. I've been questioning my AI usage for a bit on this, and feel comfortable at this conclusion given my future goals and the limited amount of time I have with them.

I also think I am starting to grow tired of technology and its use. A lot of older, senior devs are very anti-machinery and anti-technology for a reason, because we know literally everything that is happening inside of it. Sure, this can sound condescending or cynical, but the idea, at least for me, is still there.

drupflare - Drupal on Cloudflare Workers

Starting with the biggest one here, as it spans a GitHub organization.

Drupal 11 + PHP 8.5 on a Cloudflare Workers Durable Object. Lots of inventions came out of it, and I'm going to likely write a big technical paper on it sometime in the winter toward the spring when I have more free time. For one, @drupflare/cartridge means that you can execute any kind of interpreted language inside of a DO. Java, Python, PHP, the whole nine yards. It opens up the door to non-interpreted languages too, like C, Go, C++, and others. I envision some kind of project where you could emulate an entire operating system on a serverless architecture in the future, based on how much brainstorming and work goes into it.

I also learned a lot about the performance levers that happen between serverless and a traditional VPS. The metrics point drupflare beating out VPS in pretty much every major scenario, even sometimes tens or hundreds of times faster in ms latency. It also allows for Drupal to be run for free; one of the primary drawbacks of hosted services is that you have to buy a server to host them. This closes that economic gap too.

Cloudflare is also working on inbound TCP, and hopefully soon, an inbound/outbound UDP socket as well, which means that this project can serve as a precedent for full-stack server applications or communication state also available on serverless. A Minecraft server could theoretically then also run on serverless, scaling automatically with user demand. That would be an amazing engineering feat and a sight to see.

It's a really interesting and novel piece of technology that I hope to present one day. Perhaps even turn it into a SaaS thing. But as of writing, v1.0.0 should be out or should be out shortly after publishing this post; I just need to make sure that everything is green and cleaned up properly.

bytebox - Java on Cloudflare Workers

Drupflare was the baseline and this was one of its artifacts, albeit a side project under my personal domain. When building @drupflare/cartridge, it pulls in third-party executable interpreters that could compile the inputted programming language to WebAssembly to be consumed. No competent Java runtime existed, other than TeaVM, and it had no typing system or bindings for Cloudflare Workers itself. So I made one.

It mostly builds off the research drupflare presented and applies it to JVM. It will also likely be the subject of my first academic paper in the coming few weeks. If all goes well too, I may also do talks with it soon. It's an interesting experiment and take about how you can get stateful stuff on a stateless machine with all the proper primitives provided.

tinyimg - Cloudflare Images Killer

Another drupflare artifact, but this time a dependency for the project.

While measuring drupflare, Cloudflare Images wasn't really the best option for Drupal's image optimization and resizing operations. Sure, it worked and did what it was supposed to do, but it cost $500 per million image transformations. tinyimg is a C project that compiles to wasm32 and outputs an NPM package that can resize and handle images over your CPU compute. Cost per million image transformations falls to $0.05 per million, and will drop as more performance enhancements come out.

I think the biggest surprise was how much space a codec took up. AVIF and HEIC are 50% of the bundle when I added them in v1.1. Now, I was only going to do that because Cloudflare raised their Workers size limits to 64 MiB uncompressed, up from a 10 MiB compressed limit on paid and 3 MiB compressed on free. Great opportunity to better performance, memory usage, and monitor health.

You can kind of see a pattern in how I build software. I had an idea, a What if ..., if you will, with a goal: Drupal for free, Drupal for smaller projects, image transformations for cheap, Java on Serverless, etc. Many of my future SWE projects will revolve around these themes: what is the missing link or primitive to this completion, and how do we build it? edgeport, a project I've already posted about, is an example of this: it was created to solve the SSH + SFTP library gap that MyLoRA needed.

Conclusion

Short highlight dev post, not really any code.

I've been on a bit of a serverless spree, and I think Cloudflare Workers might need to start opening those doors a lot more for me.

Peace.