SvelteKit is the upcoming full-stack application framework for Svelte, the UI framework that builds your app at compile time to produce smaller, faster JavaScript. While SvelteKit allows you to write server-side logic using endpoints, it's up to you how you want to persist your application's data.

In this blog post, we will implement a waiting room page for your website.

Why?​

High number of visitors on your website is a good thing generally but not always. Sudden high traffic may easily overwhelm your applications which may disrupt your services completely. Waiting room is a solution that helps you to control the traffic and protect your resources during traffic surges. Cloudflare Waiting Room is a good solution but it is only available for business and enterprise accounts. Don’t worry, in this blog we will build a waiting room for any type of web site using Cloudflare Workers and Upstash Redis.

What are Next.js Functions? Why are they important?​

Today, the Vercel team announced the Next.js Edge functions. Edge functions allow developers to run their code at the servers distributed globally. This means your code will be executed at the location that is closest to your user. You can think of edge functions as the serverless functions which are run at the CDN infrastructure. Edge functions have the following advantages:

• Global low latency: Because the code is replicated to many global locations (PoP: points of presence), a user anywhere in the world will experience low latency. Each client will fetch the response from the nearest server.
• No cold start: Edge infrastructure providers use V8 Isolates which eliminates the cold starts. This means much faster startups.

Upstash started its journey with a mission to be the best database option for your AWS Lambda functions. Meanwhile, we discovered another great option to build your serverless functions: Cloudflare Workers. It is an exciting product because it promises a better latency all over the world with a lower cost and no cold starts. But it has many limitations when compared to AWS Lambda. Extra limitations makes the list of database options shorter. We saw this as an opportunity to position Upstash as a great solution for the question: CF Workers are stateless. Where should I keep my data then?

In recent years, serverless architectures and edge computing are becoming very popular for application deployments. But storing application state and the data inside a serverless and/or edge function is a different story. There are many difficulties such as; managing the connections to the database, making the data available for fast access from multiple locations etc. There are only a few database services supporting serverless access and very few of those are also suitable for edge functions. (You can read a detailed analysis here.)

At Upstash, from day one, we are providing a serverless Redis compatible database for low latency and with a per-request pricing model. Additionally we expose a first-class REST API built directly on the database. REST API removes the connection management hassle, especially when used in serverless functions, but also accessible even from restricted environments like edge locations or web browsers.

Today we are happy to announce the Global Database, which is a step further to make the database available globally, closer to the clients and edge locations for low latency reads. Global Database is available on free tier, you can try it without any cost.

In this article, I will compare AWS Lambda and Cloudflare Workers based on my experiences and observations during developing applications to showcase Upstash use cases.

Both are similar in that they provide a serverless runtime for developers to run their functions. But there are many differences between them and I will list them in the following categories: Performance, Pricing, Runtime and Language Support, Tools and Resources, Ecosystem and Integrations, Configurability and Limitations. I will declare a winner for each category from my point of view.

Serverless is great for developers who want to build an application end to end with lowest maintenance and financial cost. Serverless functions enable you to run your own code without maintaining the backend infra. But they are stateless by design so you need an external data store. So the next question is which databases are best fit for serverless? The good news is database vendors see the serverless trend and they are either launching either serverless offerings or trying to adapt their product. In this article, I will first list the things that make a database great for serverless. Then I will list the database that I personally think to be candidates to be the great database for Serverless.

• This is a continuation of the blog post published in April,2021.

We built a sample application which compares the performance of leading serverless databases using a common web use case and serverless functions. The databases are DynamoDB, MongoDB (Atlas), Firestore, Cassandra (Datastax Astra), FaunaDB and Redis (Upstash)

1 ms latency is easy with Redis when the database and clients are in the same region. But if you want the clients to be globally distributed then the latency rises over 100 ms. We built Edge Caching to overcome this.

AWS Lambda pioneered serverless space. Many developers think that serverless is the future of development. It gives you the true pay-per-use model, relieves you from the maintenance and scaling of the backend infrastructure. But it also comes with challenges. One of those is its statelessness. You need to keep the state in an external data store. Unfortunately most of the popular data stores are connection based. But as we explained in this post, managing connections can become painful in serverless. That’s why, we have developed a high performance REST API on top of Upstash Redis. In this blog post, I will implement a very basic stateful api (page counter) on AWS Lambda and Upstash Redis using the REST API.