Building serverless applications on the “edge” is becoming a reality. The promise of fast execution and seamless deployment is near, but is it here?
The goal: Use an edge platform to build a proof of concept clone of linkz.ai, a tooltip generator for external links (among other things).
I want to create a self-contained application, all serverless, without any external tools like a managed Postgres or lambda.
I want to write my code and deploy it to the edge. No-fuss. What are my options for deploying wicked-fast applications to the edge?
To build my linkz.ai clone, here’s how I would structure my application—starting with a list of URLs sent from the website and ending with the data needed to make my preview.
There are a few key points here that disqualify a lot of serverless providers:
Right off the bat, a lack of a native storage layer disqualifies the following:
To get around the limitations, I could use an external database like Upstash, but that is beyond the scope of this article.
Fastly offers four ways to build their Wasm bundles:
Rust seems to get the most love from the Fastly team, with items like fast reload launching with support only for Rust (with the other platforms coming later).
While I prefer Typescript, AssemblyScript was a bit restrictive and limited compatibility with third party libraries that could be useful. I opted for javascript.
However, after writing some code, I found that Fastly doesn’t allow for fetch requests to URLs not pre-defined in the application’s config.
While Compute@Edge feels like a great add-on to Fastly, it doesn’t quite fit the requirements for this full-stack application.
The developer experience for using Akamai’s edge workers is dramatically different than Fastly or Cloudflare.
To start, to even enable them on my account, I had to head to a Slack channel to ask for access.
Trying to set up the “Hello World” example they had, I had to jump through the hoops of enabling their “advanced TLS” and creating a certificate. This process is much more involved than with Cloudflare or Fastly.
The developer experience was lacking:
For someone just looking to use a workers platform, I would not recommend Akamai as a solution.
Note: My experience may not be typical. Maybe something went wrong during onboarding. However, the point remains that Akamai’s developer experience is currently not up to par with that of Fastly or Cloudflare, and I prefer not to develop an application on their platform.
While the developer experience on Cloudflare Workers isn’t perfect, it does get the job done without much fuss.
Setting up workers, creating a KV store for dev and prod environments, and deploying all happen without any challenges.
Here’s a sample of the final product.
Youtube link (opens an embed window when clicked)
Here’s a link to the repo. I was able to build the back end with under 200 lines of code!
Cloudflare knows that a huge use-case for workers is working with HTML files. Their built-in HTML rewriter made it easy to read and pull out the information I needed from the links needing a tooltip.
Edge KV is a globally distributed and eventually consistent database built for “write-once” or “write-rarely” data. For our purposes, this is great.
They also have a handy feature for Cache TTL, alleviating my worry that I’ll store old data that never gets accessed.
The only real “workers” option for building a tool like linkz.ai is Cloudflare Workers.
Other tools, like Fastly’s Compute@Edge, Akamai’s Edge Workers, and more, are positioned to be excellent in tandem with an existing application.
As a self-contained application, Cloudflare Workers is the only contender.
.jpg)
.jpg)