What Could Storage on Vercel Change for the Edge-First Strategy
Tags: webdev, nextjs, serverless, architecture
Published: 2023-05-06 15:40:57

The launch of [Vercel's first-party storage](https://vercel.com/blog/vercel-storage) has created a buzz in the media, with discussions around its pricing and business model and its potential to "[eat the cloud from outside](https://www.swyx.io/cloudflare-go)".

However, what caught my attention was the [Why now](https://vercel.com/blog/vercel-storage#why-now) chapter on their launching page, particularly the **edge-first** word in the first sentence：

> Driven by the need for both performance and personalization, frameworks are becoming server-first and edge-first.
> 

As someone who has been unsure about the benefits of edge computing in web applications,I am curious to see how this edge-first approach will enhance the strategy.

## Problems of Edge Adopted in Web Application

The selling point of Edge is faster response time, which is usually achieved through two factors:

- Edge runtime
- Edge location

### Edge Runtime

Edge runtime is a lightweight API layer built on top of the V8 engine. It is purposefully minimal and designed for security and speed, therefore could provide faster cold start times than serverless functions.

Leave alone the limited API inconvenience, does the cold start really a problem for you? In the recent serverless discussion,  Alex DeBrie pointed out that in AWS only 1% of Lambad invokes are cold start. He also provided a real-world example of a client:

> 27 cold starts out of 91k invokes in a 12 hour span(0.03%)
> 

Furthermore, counterintuitively, more instances running in different locations might result in longer cold start times. For more information, check out his talk linked below:

{% embed https://www.youtube.com/embed/N_mE-KixclI?start=1685 %}

### Edge Location

This one is actually more widely recognized by the public. By running the logic close to the end user, it could reduce the distance that data needs to travel. 

![edge](https://user-images.githubusercontent.com/16688722/236633596-26af9534-3133-4c86-a04b-cca0c11efd04.png)

However, when the database comes into play, this benefit is diminished. In fact, it may even become worse because the amount and frequency of data transferred between the edge and the database are typically higher than that between the edge and the user.

![edge-database](https://user-images.githubusercontent.com/16688722/236633594-bec9434e-9cbd-47dc-95ec-118ac4a0af10.png)

Imagine your Edge function does 3 database lookups and your database is located in the US West region iad1. Now imagine that a user in Australia hits this function. That user will connect to their closest data center in Sydney, and the function will send 3 queries to the database— all across the whole north pacific ocean over a full second. 

Vercel offers a regional edge function option that enables users to select the region where their function will run, thus reducing overall latency by locating it closer to the database. 

![regional-edge](https://user-images.githubusercontent.com/16688722/236633592-ac292dd8-9da8-4c1b-94c1-f4bc1f4ffbd2.png)

However, this approach seems to contradict the original promise of edge computing, which is to run logic near the end user, not the database.

**In essence, while the servers are distributed globally, the databases are not yet.** 

## Self-Provisioning to Unleash the Potential of Edge

Although there are geo-distributed database solutions available in the market like HaperDB, Turso, etc., Vercel has an advantage over others when it comes to coordinating data communication between the edge instance and the database, especially if Vercel is the storage provider. Since Vercel has a deep understanding of your application, it can optimize it in various ways similar to the [Self Provisioning](https://www.swyx.io/self-provisioning-runtime) concept.

For example, in the future, we may see scenarios such as the following:

1. An Edge function retrieves data from the database to render a Task component.
2. The read query is executed in the closest read replica database instance.
3. Vercel knows that the data is subject to frequent changes based on application traces, so it caches the result in the Vercel KV.
4. Another Edge function attempts to render the same Task component. Since Vercel knows that the data hasn't changed during the time period, it retrieves the cached data from the closest KV instance and returns it.

As a developer, I hope to see it coming soon so that we could focus more on "**Just write business logic**".

---

Speaking of "**Just write business logic**",  the [ZenStack](https://zenstack.dev/?utm_campaign=devto&utm_medium=organic&utm_content=vercel_storage) toolkit we are building shares the same goal.  It uses the declarative data model on top of Prisma adding access policy and validation rules, from which it will automatically generate APIs including OpenAPI, tPRC route, and hooks for you.  So you could focus on what matters-user experience.