Table of contents
Open Table of contents
Introduction
It’s no surprise that serverless applications are on the rise. As such, cloud provider and platforms have been increasingly providing serverless solutions that are either built from the ground up to support serverless workloads in mind or have been investing in porting existing off the shelf solutions into serverless services (ex: postgres).
Edge Ecosystem
One obvious way of improving application performance is to move the application closer to the client (end user). This makes edge platform providers are an attractive destination.
However, edge platform providers are often resource constrained, at least when compared to full fledge cloud providers. Edge platforms promise globally available application by abstracting away the infrastructure and deployment details. Most applications require some sort of state or persistence. Managing state at the edge is ideally done in the same runtime as the execution. However, collocating state and execution is often not possible due to the way execution layer works. This means state is handled external to the execution, adding latency and execution delay.
Cloudflare
Cloudflare is one of the largest edge platform provider with over 300+ edge locations. Logically, if you want your application to be available across most geographical locations, cloudflare is definitely one of the ways to do so.
FlagShip
I wanted to build FlagShip - a feature flag application. Feature flags are read heavy applications are are expected to have low latencies. I started off with using sveltekit for the application logic and admin dashboard for managing feature flags. The sveltekit application is hosted on Cloudflare workers.
For persistence, Cloudflare has a number of offerings. From D1 - a sql database at the edge to KV - a key value store. Some other offerings include R2 - for object store, Queues for messaging and Durable objects for building application that require low latency shared access object.
FlagShip stores all the configuration data in D1, which exposes a SQL interface. As of today, D1 does not offer geographical replication capabilities yet. However, this is not an issue as admin dashboard is not expected to be as performant. The flags are synced in near real-time to Cloudflare KV, which is a low latency key value store at the edge. By decoupling the application data from flags data, FlagShip remains to be performant while leveraging platform capabilities offered by Cloudflare.
The writes on KV have a considerable propagation delay (up to 30 seconds, according to Cloudflare), especially when used across different geographic locations.
FlagShip uses other services offered by cloudflare. For instance, for authentication and authorization, FlagShip leverages Cloudflare zero trust access. In the future, I plan on using Cloudflare Workers analytics engine (which is an offering based on clickhouse) for feature flag usage and analytics.
Here’s an example usage of feature flags:
We can dynamically render Moonipappa, either the summer variant or the winter one, by setting the isWinter flag to true or false on flagShip dashboard. You can find the demo here.
Screenshots
Conclusion
As of today, state management at the edge is still not mature enough. There is a lot of room for improvement and I think platform capabilities have a big impact on the overall application development, deployment and performance.
I’m personally bullish on platforms like Turso.tech and unikraft, which have some really cool tech around the serverless and edge computing scenes.
With more and more platforms and edge providers being introduced, especially niche platforms such as edge caching and edge database services, the future of edge ecosystem is definitely exciting.