Cloudflare Workers - Routing Made Easy

Hi, just wanted to share something cool I found while working on a side project using Cloudflare Workers. It’s called itty-router-openapi and it’s from Cloudflare themselves.

I’ve been working on a globally distributed server provisioning platform using Cloudflare’s compute (Workers) and storage (KV, R2, Durable Objects.) As part of the API portion of this work, I first rolled my own naive implementation of endpoint routing to get things off the ground. After building up the service further it, was becoming apparent that I would need a proper routing framework.

I first started working on my own framework but that quickly turned into something I really didn’t want to dig into and I (correctly) assumed that this had been solved somewhere else first. The first thing I landed on was itty-router. It’s a micro routing framework that works with Javascript and TypeScript that seemed to fit the bill perfectly for what I needed.

I started rewriting my endpoints using this framework. As I was running into issues, I started searching around for additional documentation or sites when I stumbled upon itty-router-openapi. Seeing that it was intended for use with Workers, been used in production for Cloudflare Radar and had the added support for OpenAPI, I was instantly sold.

I’ve only now started the third re-write using this new library. So far it has been going pretty good but I will try to update soon on how things are going and if I’m still using the framework.

OpenBMC Development on Windows

I’m writing this to help others who may be in the same predicament as me. I wrote this a while back when I ran Windows 10 on my personal laptop (gotta have those games) but I also enjoyed working with projects and developing in a Linux environment. WSL2 has been a savior; it gets me a working, performant Linux environment with ease. But, as I’ve been playing more lately with developing Rust applications in OpenBMC, one big thing has been holding me back: the ability to run the QEMU image for the OpenBMC device itself. Let me describe my workflow:

  1. I have WSL setup with rust, cargo and cross. This allows me to build binaries for ARMv5.

  2. I use VSCode loaded into the WSL2 environment using the remote development extensions.

  3. Once I build my binary using cross, I SCP it to a running OpenBMC instance running via QEMU on a remote Linux box.

Now, this workflow has been working alright, but I hate to have a dependency on some second Linux box that is dedicated just to running this tiny ARM image. So I started doing some research.

I found that QEMU supports the same virtualization extensions in Windows 10 that WSL2 leverages to run as a lightweight VM without requiring a full Hyper-V installation. Using this, I don’t have to install and configure Hyper-V along with a separate Linux VM that would suck resources and have to be maintained just emulate some basic software.

Here is the procedure for getting this up and running:

  1. Make sure you have the Windows “Virtualization Platform” feature enabled. If you are running WSL2 already, this should be on. If it’s not, do a search for “Windows Features” and enable it.

  2. Download a build of QEMU for Windows. You can find links here to the installers: https://qemu.weilnetz.de/

  3. After running the install, add the binaries to the path variable for your Windows installation.

  4. Download the latest OpenBMC development image, found on the Development Environment setup documentation https://github.com/openbmc/docs/blob/master/development/dev-environment.md).

  5. Reboot or logout/login to reset your environment variables.

  6. Open up a Windows Terminal (which is also awesome!) and navigate to where the emulated image is.

  7. Run the following command to start the image: 

    1.  qemu-system-arm.exe -m 256 -M romulus-bmc -nographic -drive file=obmc-phosphor-image-romulus.static.mtd,format=raw,if=mtd -net nic -net user,hostfwd=:127.0.0.1:2223-:22,hostfwd=:127.0.0.1:2443-:443,hostname=qemu

  8. Default login is “root” and password “0penBmc” (that’s a zero). End the session with ctrl+a, ctrl+x.

  9. You can also ssh via the forwarded port 2223.

Using this process, I have been able to remove the dependency on my secondary box and continue developing using only my Windows box.