Why use Cloudflare Workers?
Cloudflare Workers let you host pages and run code without managing servers. Unlike traditional servers placed in a single or a few locations, the deployed static assets and code are mirrored around the globe in the data centers shown as blue dots below. Naturally, this offers better latencies, scalability and robustness.
Their developer platform also extends beyond “Workers” (the compute part) and include storage, databases, queues, AI and lots of other developer tooling. The whole with a generous free tier and reasonable pricing beyond that.
Why am I writing this? I find it fairly good, had a good experience with it, and that’s why I will present it here. This article is not sponsored in any way. I just think it’s somehow a responsibility of developers to communicate about the tools they use in order to keep their ecosystem lively. I’ve seen too much good stuff getting abandoned because there was no “buzz”.
The benefits of using Cloudflare Workers is:
Great latencies worldwide
Unlimited scalability
No servers to take care of
Further tooling for data, files, AI, etc.
GitHub pull requests preview URLs
Free tier good enough for most hobby projects
When not to use it
Like every tool, it has use cases for which it shines and others it is not suited for. This is important to grasp and understanding the underlying technology helps tremendously. Basically, in loads your whole app bundled as a script and evaluates it on the fly. It’s fast and works wonderfully if your API and used frameworks are slim and minimalistic. However, it would be ill-advised in following use cases:
Large complex apps
The cost of evaluating your API / SSR script will grow as your app grows. The larger it becomes, the more inefficient its invocation as a whole will become. There are also some limits how large your “script” can be. Although it has been raised multiple times in the past, the fact that this is extremely inefficient will always remain. Thus, be careful when picking dependencies/frameworks since they can quickly bloat your codebase.Heavy resource consumption
Due to its nature, it is not suited to compute stuff requiring large amounts of CPU/RAM/time like statistic models or scientific computation. Large caches are problematic too. Waiting for long-running async server-side requests is OK though, the execution is suspended in-between and do not count towards execution time.-
Long-lived connections
That’s also problematic. You should rather use polling than keeping connections open.
In other words: “The slimmer, the better!”
It’s kind of difficult to say what’s small enough and when it becomes too large. This is rather suited for small self-contained microservices of modest size. Even debugging using breakpoint might turn out challenging. For such larger applications, traditional server deployments would be more suited.
What will we build?
A “Quote of the Day” Web application.
The purpose is not to build something big, but rather a simple proof-of-concept. The quotes will be stored in a KV store and fetched Client-side. That way, we can measure how fast the whole works and if it lives up to the expectations.
The default version of https://quoted.day is available in two flavours:
https://quoted.day/spa: a static page, fetching the quote text/author asynchronously
https://quoted.day/ssr: Server-Side-Rendering, rendering the page with the quote on the server
I swapped which one is the default from time to time to perform experiments. Performance (latency) may vary depending where you are located and whether what you fetch is “hot” or “cold”. Before we delve into details on how to build such an app, let’s take a look at the performance we can expect.
Benchmarking latencies worldwide
Unlike the internal Cloudflare latency measures, measured “inside” the worker and therefore quite optimistic, we will look at the “real” external latency thanks to the great tool https://www.openstatus.dev/play/checker .
Thanks to that, we can obtain a pretty good idea of the overall latencies that can be observed all over the world. Note however that Australia, Asia and Africa may have rather erratic latencies that “jump” sometimes.
We will also benchmark multiple things separately:
Static assets
Stateless functions
Hot KV read
Cold KV read
KV writes
Also, every case will get “two passes”, to hopefully fill caches on the way, and only record the second one.
Static assets
This was obtained by fetch the main page at https://quoted.day/spa
| Region | Latency |
|---|---|
| 🇩🇪 fra Frankfurt, Germany | 30ms |
| 🇩🇪 koyeb_fra Frankfurt, Germany | 31ms |
| 🇫🇷 cdg Paris, France | 33ms |
| 🇳🇱 railway_europe-west4-drams3a Amsterdam, Netherlands | 33ms |
| 🇬🇧 lhr London, United Kingdom | 31ms |
| 🇸🇪 arn Stockholm, Sweden | 32ms |
| 🇫🇷 koyeb_par Paris, France | 31ms |
| 🇳🇱 ams Amsterdam, Netherlands | 54ms |
| 🇺🇸 ewr Secaucus, New Jersey, USA | 32ms |
| 🇺🇸 iad Ashburn, Virginia, USA | 36ms |
| 🇺🇸 koyeb_was Washington, USA | 35ms |
| 🇨🇦 yyz Toronto, Canada | 50ms |
| 🇺🇸 ord Chicago, Illinois, USA | 36ms |
| 🇺🇸 lax Los Angeles, California, USA | 28ms |
| 🇺🇸 sjc San Jose, California, USA | 26ms |
| 🇺🇸 railway_us-east4-eqdc4a Virginia, USA | 41ms |
| 🇺🇸 railway_us-west2 California, USA | 49ms |
| 🇺🇸 koyeb_sfo San Francisco, USA | 29ms |
| 🇸🇬 railway_asia-southeast1-eqsg3a Singapore, Singapore | 53ms |
| 🇮🇳 bom Mumbai, India | 95ms |
| 🇺🇸 dfw Dallas, Texas, USA | 30ms |
| 🇯🇵 nrt Tokyo, Japan | 28ms |
| 🇦🇺 syd Sydney, Australia | 31ms |
| 🇸🇬 sin Singapore, Singapore | 294ms |
| 🇸🇬 koyeb_sin Singapore, Singapore | 436ms |
| 🇧🇷 gru Sao Paulo, Brazil | 252ms |
| 🇿🇦 jnb Johannesburg, South Africa | 559ms |
| 🇯🇵 koyeb_tyo Tokyo, Japan | 28ms |
Stateless function
his is obtained by fetching the endpoint https://quoted.day/api/time which simply returns the current time.
| Region | Latency |
|---|---|
| 🇬🇧 lhr London, United Kingdom | 38ms |
| 🇩🇪 koyeb_fra Frankfurt, Germany | 32ms |
| 🇳🇱 railway_europe-west4-drams3a Amsterdam, Netherlands | 36ms |
| 🇫🇷 cdg Paris, France | 75ms |
| 🇳🇱 ams Amsterdam, Netherlands | 76ms |
| 🇩🇪 fra Frankfurt, Germany | 88ms |
| 🇫🇷 koyeb_par Paris, France | 73ms |
| 🇸🇪 arn Stockholm, Sweden | 97ms |
| 🇺🇸 railway_us-east4-eqdc4a Virginia, USA | 36ms |
| 🇺🇸 koyeb_was Washington, USA | 62ms |
| 🇺🇸 ewr Secaucus, New Jersey, USA | 95ms |
| 🇺🇸 lax Los Angeles, California, USA | 39ms |
| 🇺🇸 sjc San Jose, California, USA | 25ms |
| 🇺🇸 iad Ashburn, Virginia, USA | 92ms |
| 🇺🇸 dfw Dallas, Texas, USA | 90ms |
| 🇨🇦 yyz Toronto, Canada | 22ms |
| 🇺🇸 ord Chicago, Illinois, USA | 108ms |
| 🇮🇳 bom Mumbai, India | 99ms |
| 🇸🇬 railway_asia-southeast1-eqsg3a Singapore, Singapore | 45ms |
| 🇯🇵 nrt Tokyo, Japan | 27ms |
| 🇺🇸 railway_us-west2 California, USA | 99ms |
| 🇧🇷 gru Sao Paulo, Brazil | 89ms |
| 🇦🇺 syd Sydney, Australia | 26ms |
| 🇸🇬 sin Singapore, Singapore | 220ms |
| 🇺🇸 koyeb_sfo San Francisco, USA | 26ms |
| 🇿🇦 jnb Johannesburg, South Africa | 540ms |
| 🇸🇬 koyeb_sin Singapore, Singapore | 354ms |
| 🇯🇵 koyeb_tyo Tokyo, Japan | 71ms |
Hot KV read
This is obtained by fetching a fixed quote from the KV store using the endpoint https://quoted.day/api/quote/123
| Region | Latency |
|---|---|
| 🇬🇧 lhr London, United Kingdom | 34ms |
| 🇫🇷 cdg Paris, France | 39ms |
| 🇳🇱 railway_europe-west4-drams3a Amsterdam, Netherlands | 35ms |
| 🇫🇷 koyeb_par Paris, France | 37ms |
| 🇸🇪 arn Stockholm, Sweden | 34ms |
| 🇳🇱 ams Amsterdam, Netherlands | 77ms |
| 🇩🇪 koyeb_fra Frankfurt, Germany | 103ms |
| 🇨🇦 yyz Toronto, Canada | 25ms |
| 🇺🇸 dfw Dallas, Texas, USA | 33ms |
| 🇺🇸 koyeb_was Washington, USA | 55ms |
| 🇩🇪 fra Frankfurt, Germany | 168ms |
| 🇺🇸 iad Ashburn, Virginia, USA | 106ms |
| 🇺🇸 railway_us-west2 California, USA | 52ms |
| 🇺🇸 ewr Secaucus, New Jersey, USA | 122ms |
| 🇺🇸 koyeb_sfo San Francisco, USA | 33ms |
| 🇺🇸 railway_us-east4-eqdc4a Virginia, USA | 123ms |
| 🇿🇦 jnb Johannesburg, South Africa | 43ms |
| 🇮🇳 bom Mumbai, India | 99ms |
| 🇸🇬 railway_asia-southeast1-eqsg3a Singapore, Singapore | 88ms |
| 🇺🇸 ord Chicago, Illinois, USA | 69ms |
| 🇧🇷 gru Sao Paulo, Brazil | 99ms |
| 🇺🇸 sjc San Jose, California, USA | 40ms |
| 🇦🇺 syd Sydney, Australia | 64ms |
| 🇺🇸 lax Los Angeles, California, USA | 91ms |
| 🇸🇬 sin Singapore, Singapore | 345ms |
| 🇯🇵 nrt Tokyo, Japan | 126ms |
| 🇯🇵 koyeb_tyo Tokyo, Japan | 65ms |
| 🇸🇬 koyeb_sin Singapore, Singapore | 856ms |
Cold KV read
This is obtained by fetching a random quote from the KV store using the endpoint https://quoted.day/api/quote
Note that each call will cache the result for a day at the edge location, resulting in possibly turning cold reads into hot reads as traffic increases.
| Region | Latency |
|---|---|
| 🇩🇪 fra Frankfurt, Germany | 131ms |
| 🇩🇪 koyeb_fra Frankfurt, Germany | 105ms |
| 🇬🇧 lhr London, United Kingdom | 110ms |
| 🇳🇱 ams Amsterdam, Netherlands | 130ms |
| 🇫🇷 cdg Paris, France | 145ms |
| 🇸🇪 arn Stockholm, Sweden | 134ms |
| 🇫🇷 koyeb_par Paris, France | 127ms |
| 🇳🇱 railway_europe-west4-drams3a Amsterdam, Netherlands | 133ms |
| 🇺🇸 ewr Secaucus, New Jersey, USA | 197ms |
| 🇺🇸 ord Chicago, Illinois, USA | 201ms |
| 🇺🇸 iad Ashburn, Virginia, USA | 220ms |
| 🇨🇦 yyz Toronto, Canada | 243ms |
| 🇺🇸 koyeb_was Washington, USA | 229ms |
| 🇺🇸 dfw Dallas, Texas, USA | 287ms |
| 🇺🇸 railway_us-east4-eqdc4a Virginia, USA | 270ms |
| 🇸🇬 sin Singapore, Singapore | 288ms |
| 🇺🇸 sjc San Jose, California, USA | 245ms |
| 🇮🇳 bom Mumbai, India | 502ms |
| 🇿🇦 jnb Johannesburg, South Africa | 322ms |
| 🇸🇬 railway_asia-southeast1-eqsg3a Singapore, Singapore | 323ms |
| 🇺🇸 lax Los Angeles, California, USA | 247ms |
| 🇺🇸 koyeb_sfo San Francisco, USA | 217ms |
| 🇺🇸 railway_us-west2 California, USA | 300ms |
| 🇧🇷 gru Sao Paulo, Brazil | 601ms |
| 🇯🇵 nrt Tokyo, Japan | 822ms |
| 🇸🇬 koyeb_sin Singapore, Singapore | 574ms |
| 🇯🇵 koyeb_tyo Tokyo, Japan | 335ms |
| 🇦🇺 syd Sydney, Australia | 964ms |
KV writes
This is obtained by fetching quoted.day/api/bump-counter which creates a temporary KV pair with an expiration time of 10 minutes. It kind of emulates the concept of initiating a “session”.
| 🇫🇷 cdg Paris, France | 128ms |
|---|---|
| 🇩🇪 koyeb_fra Frankfurt, Germany | 151ms |
| 🇩🇪 fra Frankfurt, Germany | 147ms |
| 🇫🇷 koyeb_par Paris, France | 194ms |
| 🇳🇱 ams Amsterdam, Netherlands | 145ms |
| 🇸🇪 arn Stockholm, Sweden | 240ms |
| 🇬🇧 lhr London, United Kingdom | 176ms |
| 🇺🇸 dfw Dallas, Texas, USA | 212ms |
| 🇺🇸 railway_us-west2 California, USA | 238ms |
| 🇺🇸 koyeb_was Washington, USA | 305ms |
| 🇺🇸 railway_us-east4-eqdc4a Virginia, USA | 295ms |
| 🇺🇸 ewr Secaucus, New Jersey, USA | 408ms |
| 🇺🇸 iad Ashburn, Virginia, USA | 423ms |
| 🇨🇦 yyz Toronto, Canada | 337ms |
| 🇺🇸 ord Chicago, Illinois, USA | 359ms |
| 🇸🇬 koyeb_sin Singapore, Singapore | 409ms |
| 🇺🇸 lax Los Angeles, California, USA | 335ms |
| 🇮🇳 bom Mumbai, India | 347ms |
| 🇺🇸 sjc San Jose, California, USA | 438ms |
| 🇺🇸 koyeb_sfo San Francisco, USA | 247ms |
| 🇸🇬 sin Singapore, Singapore | 508ms |
| 🇯🇵 nrt Tokyo, Japan | 684ms |
| 🇦🇺 syd Sydney, Australia | 713ms |
| 🇯🇵 koyeb_tyo Tokyo, Japan | 734ms |
| 🇳🇱 railway_europe-west4-drams3a Amsterdam, Netherlands | 1,259ms |
| 🇸🇬 railway_asia-southeast1-eqsg3a Singapore, Singapore | 1,139ms |
| 🇿🇦 jnb Johannesburg, South Africa | 2,266ms |
SSR Page with KV cold reads
Lastly, in this test, we combine the reading a random quote (that usually results in a cold KV read) and renders it server-side in a page.
| Region | Latency |
|---|---|
| 🇫🇷 koyeb_par Paris, France | 111ms |
| 🇬🇧 lhr London, United Kingdom | 108ms |
| 🇳🇱 railway_europe-west4-drams3a Amsterdam, Netherlands | 125ms |
| 🇫🇷 cdg Paris, France | 133ms |
| 🇩🇪 koyeb_fra Frankfurt, Germany | 139ms |
| 🇩🇪 fra Frankfurt, Germany | 146ms |
| 🇸🇪 arn Stockholm, Sweden | 142ms |
| 🇳🇱 ams Amsterdam, Netherlands | 70ms |
| 🇺🇸 railway_us-east4-eqdc4a Virginia, USA | 151ms |
| 🇺🇸 koyeb_was Washington, USA | 159ms |
| 🇺🇸 ewr Secaucus, New Jersey, USA | 201ms |
| 🇺🇸 iad Ashburn, Virginia, USA | 209ms |
| 🇺🇸 ord Chicago, Illinois, USA | 217ms |
| 🇺🇸 dfw Dallas, Texas, USA | 220ms |
| 🇺🇸 sjc San Jose, California, USA | 191ms |
| 🇺🇸 railway_us-west2 California, USA | 201ms |
| 🇨🇦 yyz Toronto, Canada | 255ms |
| 🇺🇸 lax Los Angeles, California, USA | 257ms |
| 🇺🇸 koyeb_sfo San Francisco, USA | 268ms |
| 🇮🇳 bom Mumbai, India | 422ms |
| 🇯🇵 nrt Tokyo, Japan | 332ms |
| 🇸🇬 sin Singapore, Singapore | 284ms |
| 🇧🇷 gru Sao Paulo, Brazil | 327ms |
| 🇸🇬 railway_asia-southeast1-eqsg3a Singapore, Singapore | 632ms |
| 🇸🇬 koyeb_sin Singapore, Singapore | 677ms |
| 🇿🇦 jnb Johannesburg, South Africa | 673ms |
| 🇦🇺 syd Sydney, Australia | 385ms |
| 🇯🇵 koyeb_tyo Tokyo, Japan | 350ms |
Observations
In is interesting to see how you can infer how the KV works just by watching the numbers. It appears the KV store is not actively replicated, but rather KV pairs are copied “on-demand” at remote locations. When cached (by default 1 minute), subsequent reads are fast. The latencies of such “hot” KV pairs are pretty good overall. No complains here. How long the pair remains cached there can also be configured using the cacheTtl parameter during the KV get request. However, the downside of increasing that value is that this cached copy do not reflect changes / updates triggered from other locations during that time.
Unsurprisingly, cold reads have worse latencies. The other thing you can infer from the numbers is that there seem to be an “origin location”, and cold reads latencies increase proportionally according to the distance to this location. Therefore, pay attention “where” you create the KV store, as it impacts all future latencies around the globe. Note that workers KV might change in the future, this is merely an observation of its state right now.
While read operations are OK, the write operations are rather disappointing right now. I expected it to have great latencies too, writing to the “edge” and letting the propagation take place asynchronously, but it is the opposite. Writes appear to communicates with the “origin” storage. The time it takes to set a value gets higher the further away you are from where you created the KV store. This is kind of bad news, because setting/updating values is a pretty common operation, for example to authenticate users. Dear Cloudflare team, I hope you improve that part in the future.
A word of caution
If you develop your webapp, publish it and take a look at it, you will probably not even notice the bad latencies. You will face the optimal latencies with the origin KV store being near you. However, someone at the other end of the planet will have an uglier experience. If that person has a handful of cache misses or writes, the response time might quickly climb into a few seconds before the response arrives. That is not how I would expect a “distributed” KV store to behave. Let us be clear, right now this behaves more like a centralized KV store with on-demand cached copies at the edge.
Quite ironically, it basically feels more like a traditional single-location database right now (+caches). While latencies of a single cache miss or a single write is not dramatic, it can quickly pile up with multiple calls and especially write-heavy webapps risk facing increased “sluggishness” depending on their location. Here as well, being “minimalistic” regarding KV calls should be taken to heart during the conception of the webapp using workers.
Lastly, there was one more setting available in the Worker: “Default Placement” vs “Smart Placement”. I tried both but I did not see noticeable changes within the latencies. I think it’s due to the fact that there is a single KV store call and that it takes time and traffic to gather telemetry and adjust the placement of workers. It might be great, but for this experiment, it had no effect at all.
Single-Page-Applications vs Server-Side-Rendering
Here as well, one is not universally better or worse than the other and the answer which one to use is “it depends”.
Besides strong differences regarding frameworks and overall architecture, it also has practical fundamental differences for the end user. It’s also fascinating to see history repeating itself, where the internet first started with server rendered pages, than single-page-application with data fetching took over and a resurgence of SSR, just like in the past, just with new tech stacks.
SSR is actually the easiest one to explain: you fetch all the required data server side, put everything in a template and return the resulting page to the end user. It takes a bit of time and processing power server-side, is not cachable, but the client gets a “finished” page.
The SPA does the opposite. Although the HTML/CSS/JS is static and cached (hence quickly fetched), the resources are typically much larger due to all the client-side javascript libs needed. Then starts the heavy lifting, where data is fetched and the page rendered, typically while showing a loading spinner. As a result, the total time to render the page is longer.
However, interacting with the SPA is typically smoother afterwards, because interactions just exchange data with the server and make local changes to the page. In contrast, SSR means navigating and loading a new page. Hence, the choice whether SPA or SSR is more suited depends on how “interactive” the page/app should be.
As a rule of thumb, if it’s more like a static “web page”, go for SSR, if it’s more like an interactive “web app”, go for SPA.
Lastly, the nice thing about Astro, picked here as illustrative example, is that the whole spectrum is possible: static pages, SPA and SSR.
Sources
The source code of this experiment is here: https://github.com/dagnelies/quoted-day
If you have a Github and a Cloudflare Account, you can also fork & deploy by clicking here:
If the button doesn’t work, here it is as link instead: https://deploy.workers.cloudflare.com/?url=https://github.com/dagnelies/quoted-day
It will fork the GitHub repository and deploy it on an internal URL so that you can preview it. Afterwards, you can edit the code and it will auto-deploy it, etc.
Note that the example references a KV store that is mine. So you will have to create your own KV store named and swap the QUOTES KV id in the wrangler.json file with yours. You will also have to initially fill it with quotes if you want to reproduce the example. Luckily, there are scripts in the package.json to do just that.
Everything beyond this point would deserve a tutorial on its own. This was merely the result of an experiment, how the latencies hold up and some insights on the platform. Enjoy!
Top comments (0)