Ability to store data at the edge for use with Edge Functions

[leerob]

Hey everyone! 👋

Now that we’ve released Edge Functions, we’ve heard from many members of the community they would like a solution for storing some data at the Edge. We also want this 😄 and we’re exploring ideas for what a solution could look like. But, we need to hear from you to make sure it suits your needs.

• What type of data are you looking at access from your Edge Functions?
• What type of data do you want to store at the Edge?
  • e.g. caching (ephemeral) or storing (durability/persistence)
• How frequently does the data change?
• What are your consistency requirements? (e.g. eventual or strong)
• Where is your origin?

[artooras]

Great initiative! I do indeed have a need for something just like that. Here's my scenario:

• When loading a Next.js page/route (hosted on Vercel), the getServerSideProps function fetches data from an external database (Firebase in my case) that is used for page props calculations. The amount of data from the server is substantial enough (~150 kB), so now if the user refreshes the page, the data is fetched once again.
• The data in nature is not very dynamic, it would suffice for me to refresh it once a day.
• Such implementation puts strains (and cost!) on my database usage...

The alternatives that I was considering were:

• Create a Firebase function that the Next.js route would call instead of querying the database directly. Firebase functions allow for storing data in variables that persists between function calls, which would allow me to query the database only once per day, and use that data to provide responses. It will work, but it seems a bit of an overkill to use the route of DB -> Serverless Function 1 (Firebse) -> Serverless Function 2 (Next.js/Vercel) -> Client.
• Instead, it would be great to have just one Function to be able to do that, hence a +1 for this initiative!

[dbrrt]

• What type of data are you looking at access from your Edge Functions?

  • Domain related data (Tenant specific), JSON data stored in a cache or relational data stored in a remote store.

• What type of data do you want to store at the Edge?

  • Mostly precomputed data for reporting or configuration. e.g.: KPI for a dashboard, Quotas, User preferences etc...

• e.g. caching (ephemeral) or storing (durability/persistence)

  • Ephemeral at Edge

• How frequently does the data change?

  • Depends on user activity, on the edge I'd imagine 1h per refresh interval is reasonable for my use case

• What are your consistency requirements? (e.g. eventual or strong)

  • Strong for most data

• Where is your origin?

  • USA (Washington, N. Virginia) and Europe (Ireland, Frankfurt).

[ErnestBrandi]

Can not see how this is related to Edge Cache : #108 🤔

[supaspoida]

Some of the things I'd like to do with data on the edge:

• User sessions
• Personalization / Segmentation
• Config that would previously live in env vars and require a rebuild/deploy to update
• The above, but encrypted as secrets (ex: store an API key used to fetch personalization data in edge functions)

This is less of a specific use case, but I'd love to see any stores like this accessible via the same set of abstractions in both edge and serverless functions. That'd enable some really interesting use cases I'd think, where serverless functions w/out the constraints of the edge function environment could be used to push data out to the edge function. So for example you might use mdx-bundler in a serverless function to push compiled templates up to the edge to be ultimately rendered with user specific data like personalization attributes.

[dijonmusters]

Edge Functions are awesome, as they get that logic as close as possible to the user. However, any functions that require a DB need to do a round trip to the origin server.

Being able to cache data at the CDN layer would mean the trips to the origin server could be reduced significantly.

As Vercel's Edge Functions are a wrapper around Cloudflare Workers, it would be amazing to get access to something similar to KV storage (for eventual consistency) and Durable Objects (for strong consistency).

This would allow the developer to make the trade off between speed and consistency!

[IamManchanda]

Where is your origin?
storing (durability/persistence)

@leerob - Something like this would be very handy ⬇️ for durable and persistent data storage needs

import { type NextRequest } from 'next/server'

export const config = {
  runtime: 'edge', // 'experimental-edge' as of today
  regions: ['iad1', 'dub1', 'bom1'] // https://vercel.com/docs/concepts/edge-network/regions#region-list
}

export default async function handler(req: NextRequest) {
  // Below example is for External Service Backend API access but 
  // similar pattern can be followed for External Backend DB access also, 
  // let's say with Prisma https://www.prisma.io/nextjs
  const data = await fetch(`https://api-${req.region}-external-service.com/data`, {
    method: req.method,
    headers: {
      authorization: process.env.API_KEY,
    },
  });
  
  // ... other code
}

Originally Posted at: https://github.com/orgs/vercel/discussions/974#discussioncomment-4001617

[leerob]

We released our first storage solution: Edge Config 🎉 (in private beta)

Edge Config allows you to distribute data to our Edge Network without needing to perform a deployment. Instead, your data is actively replicated to all our regions before it’s requested. This means your data will always be available, instantly.

The Edge Config architecture acts similarly to a push-based Content Delivery Network (CDN). Pull-based CDNs load the data on the first request and keep it around until it expires, while push-based CDNs get the data before it is requested and keep it around until a new version is pushed.

While Vercel handles most aspects of our infrastructure like a pull-based CDN, Edge Config works more closely to a push-based CDN. It propagates your config data to all our regions before it's requested, and keeps it in cache until a new version is published.

Your data is structured as JSON, but Edge Config is not a general-purpose key/value store. Instead, it is optimized for fast, inexpensive reads and infrequent writes. Writes of configuration values may take a few seconds to propagate globally, but reads return with very low latency.

Most lookups return in 5 ms or less, and 99% of reads will return under 15 ms.

[ogbotemi-2000]

I have an approach that I used to make the backend of my web app: https://rmrf-css.vercel.app work on Vercel.
This workaround works with just about any type of serverless functions and here are links to it

1. GitHub issue workaround: Global variables next.js#15054 (comment)
2. Detailed technical article on workaround: https://dev.to/ogbotemi2000/persist-data-in-vercelnextjs-serverless-backends-1h70