Forem: Enes Akar

Best Databases for Next.js

Enes Akar — Thu, 03 Feb 2022 22:46:03 +0000

Next.js enables developers to build full stack applications with the Server Side Rendering capability. Vercel and Netlify help them to write the backend API with serverless functions. So the next question is what is the ideal database for Next.js apps. In this post, I will review the databases which are popular among the Next.js community. I will comment on how they fit the serverless model. Two things to check:

Serverless pricing: Is the price pay-per-use? When the database is not in use, do you still have to pay?
Serverless connections: Is there support for HTTP based connections? So there should not be any connection problems which are common with serverless functions.

TLDR

I have reviewed PlanetScale, Supabase, Upstash, Fauna, DynamoDB and MongoDB Atlas. Check the table below to compare the feature set of each product.

Feature	PlanetScale	Supabase	Upstash	Fauna	DynamoDB	MongoDB Atlas
API	MySQL	PostgreSQL	Redis	Fauna	DynamoDB	MongoDB
Type	Relational	Relational	KV Store	Document	Document	Document
Free Tier	🟢	🟢	🟢	🟢	🟢	🟢
Serverless Pricing	🟡 (min $29)	🟡 (min $25)	🟢	🟡 (min $22.5)	🟢	🟢
REST API	🔴	🟢	🟢	🟢	🟢	🟢
GraphQL API	🔴	🔴	🔴	🟢	🔴	🔴
Global replication	🔴	🔴	🟢	🟢	🟢	🟡 (only for Dedicated)
Database Branching	🟢	🔴	🔴	🔴	🔴	🔴
Realtime Updates	🔴	🟢	🔴	🔴	🟢	🟡 (via Realm)
Price Reads	$1.5 / 10m	$0.09 / GB	$0.2 / 100K	$0.45 / 1m (4KB)	$0.25 / 1m (2KB)	$0.3 / 1m (4KB)
Price Writes	$1.5 / 1m	$0.09 / GB	$0.2 / 100K	$2.25 / 1m (1KB)	$1.25 / 1m (1KB)	$1.25 / 1m (1KB)
Price Storage	$1.25 / GB	$0.125 / GB	$0.25 / GB	$0.23 / GB	$0.25 / GB	$0.25 / GB

PlanetScale

PlanetScale is a MySQL compatible database as a service.
It is uses Vitess at the background. This is great as Vitess is being actively used by giants like Youtube.
PlanetScale introduced the database branching concept. You can create branches and merge schema changes to your production database just like git. Afaik, this feature is unique for PlanetScale.
It has a free tier with 100m reads per month.
Paid plans start from $29. The main price components for the paid plan are:
- Storage/month: $1.25/GB after first 25GB
- Reads/month: $1.50 per 10m, after first 500m
- Writes/month: $1.50 per 1m, after first 50m
PlanetScale does not have an HTTP/REST based API.

My Comments:

In the home page, it is said that: Trusted By Github, Square, Slack etc. Do these companies use PlanetScale or Vitess? If these companies use PlanetScale then it is great. Otherwise, I do not feel good about this type of marketing. Trusting Vitess and Trusting PlanetScale are different things
PlanetScale requires you to use TCP based connections (MySQL connections). This might be a problem for serverless functions as they are stateless. They say the number of connections is not a problem for Vitess but still there is a max connection limit for the plans.
Lack of the HTTP/REST API makes it impossible to use PlanetScale from Cloudflare Workers and Vercel Edge platforms because they do not allow TCP connections.
Planetscale paid plans start from $29, so the price does not scale to zero. Even if you are not using a DB, you have to use $29 per db at least. I think this is a conflict with the definition of serverless.

Useful Links:

Supabase

Supabase is a collection of developer tools including database, authentication service, storage. They call themselves as Open Source Firebase Alternative
Supabase provides a PostgreSQL database.
Just like Firebase, Supabase enables developers to listen to the changes on the database in real time.
Supabase provides a RESTful API using PostgREST. This is useful especially if you plan to use Supabase in serverless functions.
Supabase can be used in Cloudflare Workers thanks to its REST API. Check this.
Supabase free tier is limited to 500MB storage and 2GB data transfer monthly.
Similar to PlanetScale, Supabase has a minimum cost for paid databases which is $25/month. Summary of payg pricing:
- Storage: $0.125 per GB-month
- Data transfer: $0.09 per GB

My Comments:

Supabase provides database, authentication service, object storage and also serverless functions are coming. I am worried that it may be hard for a startup to provide many services with high quality and compete with Firebase backed by Google. I hope they will be successful.
Just like PlanetScale, I think their pricing is not true serverless. Their paid plans require a fixed monthly cost so it never scales to zero.

Useful Links:

Upstash Redis

Upstash provides Redis as a service with per request pricing.
It provides both Redis and REST API. So you can use it with both serverless and edge (Cloudflare Workers) functions.
Upstash has regional and global options. Global database replicates data to multiple regions.
It has a free tier with max 10.000 commands per day. Its pay-as-you-pricing is as follows:
- Commands: $0.2 per 100K commands
- Storage: $0.25 per GB

My Comments:

Both we (Upstash) and RedisLabs think that Redis is powerful enough for many use cases in addition to classic Redis use cases (caching, kv-store). But still I see many developers prefer SQL databases as the primary data store. If you need complex query capabilities, Redis may not be your first choice.

Useful Links:

Fauna

Fauna provides a Globally Replicated Strongly Consistent database as a cloud service.
It provides GraphQL API in addition to Fauna API.
Its connections are HTTP based so you can use Fauna in serverless functions without any connection related problems.
Its most basic plan (Individual) starts from $22.5/month.
Fauna pricing:
- Reads: $0.45/Million units (4KB)
- Writes: $2.25/Million units (1KB)
- Storage: $0.23/GB

My Comments:

Global strong consistency comes with extra performance costs. Writes have higher latencies than other alternative databases.
If you will use GraphQL then it’s great but otherwise FQL was hard for me to learn and use.
Fauna pricing has its own units (TRO, TWO, TCO) and many dimensions. You need to read articles to understand the pricing.

Useful Links:

MongoDB Atlas

Atlas is a MongoDB as a managed service which has serverless, shared and dedicated plans..
Data (REST) API has been recently announced. This allows you to access your database using HTTP.
MongoDB Atlas has a Serverless plan with some limitations. The pricing of this plan is per operations so it scales to zero as expected from a serverless product.
Multi region replication is only available with Dedicated plan.
Serverless Pricing:
- Reads: $0.30 per million unit (4KB)
- Writes: $1.25 per million unit (1KB)
- Storage: $0.25/GB-month

My Comments:

Serverless Plan and Data API tells us that MongoDB Atlas does not ignore the Serverless space. But both solutions are in the preview phase and needs some improvements to be a data solution ideal for serverless applications.

Useful Links:

DynamoDB

Fully managed NoSQL database with key-value and document data model.
The connections are HTTP based so it fits to serverless applications.
Pricing is per operation in addition to data transfer cost. So it scales to zero.
By default, the reads are eventually consistent. You can also request strongly consistent reads but it has some limitations.
You can enable multi region replication with extra cost.
The pricing:
- Reads: $0.25 per million read request units (2KB)
- Writes: $1.25 per million read request units (1KB)
- Data transfer (out): $0.09 per GB
- Storage: $0.25 per GB-month

My Comments:

For me, DynamoDB API is not as intuitive as Redis or MongoDB.
There is a vendor lock-in problem. DynamoDB is only at AWS and you can not move your application to another provider without changing the code.

Useful Links:

Conclusion

So what is the best database for Next.js? As expected, there is no single answer. But let's give some conditional answers:

If you need a relational DB 👉🏻 Supabase or PlanetScale
If you need database branching 👉🏻 PlanetScale
If you need real time updates 👉🏻 Supabase or MongoDB Atlas
If you need global low latency 👉🏻 Upstash or DynamoDB
If you need global strong consistency 👉🏻 Fauna
If you need low latency key value store 👉🏻 Upstash
If you love PostgreSQL 👉🏻 Supabase
If you love MySQL 👉🏻 PlanetScale
If you love Redis 👉🏻 Upstash
If you love Mongo 👉🏻 MongoDB Atlas
If you need GraphQL 👉🏻 Fauna

I tried to be fair and correct. If you think there is something I need to fix, please drop your comments to my twitter

Use Serverless Kafka as an Event Source For AWS Lambda

Enes Akar — Mon, 24 Jan 2022 22:46:14 +0000

In this tutorial we will implement a serverless message processing pipeline using Upstash Kafka and AWS Lambda. We will use Upstash Kafka as a source for an AWS Lambda function. The produced messages will trigger AWS Lambda, so your Lambda function will process the messages.

Because Upstash Kafka is a true serverless product, the whole pipeline will be serverless. You pay only when your pipeline is actively processing messages.

Create Upstash Kafka

First, create an Upstash Kafka cluster and topic following those steps. You will need the endpoint, username and password in the following steps.

Create AWS Lambda Function

Now let’s create an AWS Lambda function. For the best performance, select the same region with Upstash Kafka cluster. We will use Node.js runtime.

:::note
You can use Serverless Framework or AWS SAM for this step.
:::

Lambda Function Code

Update your function's code as below:


exports.handler = async (event) => {

    if(!event.records) {
        return {response : "no kafka event"};
    }

    for(let messages of Object.values(event.records)) {
        for(let msg of messages) {
            let buff = Buffer.from(msg.value, 'base64');
            let text = buff.toString('ascii');
            // process the message
            console.log(text);
        }        
    }

    return {response : "success" };
};

The above code parses the Kafka message from the event parameter. AWS encodes the message using base64 so we decode the message and log it to the console.

Create AWS Secret

AWS Lambda trigger needs the Kafka credentials to be bundled as a secret. So we will create a secret in AWS Secrets Manager. Select Other type of secret. Enter your Kafka cluster's username and password as key/value pairs as below:

In the next screen give a name to your secret.

Edit AWS Lambda Role

Now we need to configure the Lambda function’s role to access the secrets.

On the AWS Lambda function’s page, click on Configuration tab and Permissions. Click to the link just below the Role name label.

The IAM management console will be opened in a new tab. On the Permissions tab click on the link which starts with AWSLambdaBasicExecutionRole-....

Click on the Edit Policy button and add this configuration in the JSON tab:

{
    "Effect": "Allow",
    "Action": [
        "secretsmanager:GetSecretValue"
    ],
    "Resource": [
        "REPLACE_THE_ARN_OF_THE_SECRET"
    ]
}

You need to replace the ARN of the secret that you created in the previous step.

Create the Trigger

Go back to your Lambda functions page and click the Add trigger button. Select Apache Kafka from the menu and fill in the inputs.

Bootstrap servers: copy/paste endpoint from Upstash console.

Topic name: enter your topic’s name

Click on the Add button under Authentication. Select SASL_SCRAM_256_AUTH and select the secret that you created in the previous step.

Check the Enable trigger checkbox and you can leave the remaining inputs as they are.

Testing

Now let’s produce messages and see if AWS Lambda is processing the messages. Copy the curl URL to produce a message from Upstash Console.


➜ curl https://full-mantis-14289-us1-rest-kafka.upstash.io/produce/newtopic/newmessage -u  ZnVsbC1tYW50aXMtMTQyODkkimaEsuUsiT9TGk3OFdjveYHBV9Jjzow03SnUtRQ:4-R-fmtoalXnoeu9TjQBOOL4njfSKwEsE10YvHMiW63hFljqUrrq5_yAq4TPGd9c6JbqfQ==

{
  "topic" : "newtopic",
  "partition" : 0,
  "offset" : 48,
  "timestamp" : 1639522675505
}

Check the cloudwatch (Lambda > Monitor > View logs in CloudWatch). You should see the messages you produced are logged by Lambda function.

Build your own Waiting Room for your Web site with Cloudflare Workers and Serverless Redis

Enes Akar — Tue, 02 Nov 2021 18:37:22 +0000

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.

How?

There are two parameters to control the waiting room.

Max session duration: How long can a visitor stay idle on the web site?
Max website capacity: How many visitors can the website allow at the same time?

When a visitor enters our website, we will generate a unique key (like a session key) and keep it in Redis. We will put this key to the Redis with an expiration time which is the max session duration. Before letting a visitor into the website, we will check the dbsize of the Redis. If the size is higher than the **max website capacity, **then we will forward the visitor to the waiting room. The waiting room is a static html but refreshes every 30 seconds. That is, once every 30 seconds, the visitor can be allowed to enter the website if there is availability.

The unique key that we generated also is written to the visitor requests as a cookie. So the requests of the same visitor will have the same key. This is required to check if a visitor has already a session inside the website when the capacity is full. So as a visitor you are allowed to enter the website even if the capacity is full as long as your key exists in the Redis keyspace. If you stay idle longer than the max session duration, then your key will be deleted from Redis. And if the capacity is full when you send a request you will be forwarded to the waiting room.

We will implement this logic at Cloudflare Workers. We will use Upstash as a Redis store. Now let’s explain the background of these technology decisions.

Why Cloudflare Workers?

Waiting room implementation will intercept all requests to your website. So its performance overhead should be minimal. Cloudflare Workers leverages Cloudflare edge infrastructure, so it gives you the minimum latency globally. Also unlike AWS Lambda, it does not have a cold start problem. It is a serverless technology so scalability is not a problem too.

Why Upstash Redis?

You need to check the current size of the website before allowing each new visitor. Cloudflare Workers is stateless so you need to keep this information externally. Redis is the best choice with its low latency. But Redis offerings require TCP based connections which are not supported by Cloudflare Workers. Upstash is the only Redis offering with a built in REST API. Also thanks to Global replication it gives you low latency all over the world.

Step by Step Implementation

We will implement the project step by step below. If you want to clone the project and set up the waiting room for your web site directly, you can follow the steps in the readme of the source code.

`1` Project Setup

Create a project using wrangler.


wrangler generate waiting-room

Then install the dependencies:


npm install cookie upstash@redis

`2` Update wrangler.toml

Update the type:

type = "webpack"

Set your Cloudflare account id. Check this to find your account id.

account_id = "REPLACE_HERE"

Add these variables:

[vars]
UPSTASH_REDIS_REST_TOKEN = "REPLACE_HERE"
UPSTASH_REDIS_REST_URL = "REPLACE_HERE"
TOTAL_ACTIVE_USERS = 10
SESSION_DURATION_SECONDS = 30

You need to create a Global database from the Upstash console. You just need to copy and paste the REST token and URL from the console. The Redis database should be empty initially and used by only this application.

You should set TOTAL_ACTIVE_USERS and SESSION_DURATION_SECONDS depending on your own requirements.

`3` index.js

Index.js is the Cloudflare Workers implementation file. So we will put all the logic inside it. Copy and paste the below code into it:

import { parse } from 'cookie'
import { auth, dbsize, get, setex } from '@upstash/redis'


auth(UPSTASH_REDIS_REST_URL, UPSTASH_REDIS_REST_TOKEN)


addEventListener('fetch', (event) => {
    event.respondWith(
        handleRequest(event.request).catch(
            (err) => new Response(err.stack, { status: 500 }),
        ),
    )
})

const COOKIE_NAME_ID = '__waiting_room_id'
const COOKIE_NAME_TIME = '__waiting_room_last_update_time'

const init = {
    headers: {
        'Authorization': 'Bearer ' + UPSTASH_REDIS_REST_TOKEN,
    },
}

async function handleRequest(request) {
    const { pathname } = new URL(request.url)
    if (!pathname.startsWith('/favicon')) {
        const cookie = parse(request.headers.get('Cookie') || '')
        let userId

        if (cookie[COOKIE_NAME_ID] != null) {
            userId = cookie[COOKIE_NAME_ID]
        } else {
            userId = makeid(8)
        }

        let res = await dbsize()
        console.log('current capacity:' + res.data)
        // there is enough capacity
        if (res.data < TOTAL_ACTIVE_USERS) {
            return getDefaultResponse(request, cookie, userId)
        } else {  // site capacity is full
            let obj2 = await get(userId)
            if (obj2.data === '1') { // the user has already active session
                return getDefaultResponse(request, cookie, userId)
            } else { // capacity is full so the user is forwarded to waiting room
                return getWaitingRoomResponse(userId)
            }
        }
    } else {
        return fetch(request)
    }
}

async function getDefaultResponse(request, cookie, userId) {
    // uncomment below to test the function with a static html content
    // const newResponse = new Response(default_html)
    // newResponse.headers.append('content-type', 'text/html;charset=UTF-8')

    const response = await fetch(request)
    const newResponse = new Response(response.body, response)

    const now = Date.now()
    let lastUpdate = cookie[COOKIE_NAME_TIME]
    if (!lastUpdate)
        lastUpdate = 0
    const diff = now - lastUpdate
    const updateInterval = SESSION_DURATION_SECONDS * 1000 / 2
    if (diff > updateInterval) {
        await setex(userId, SESSION_DURATION_SECONDS, 1)
        newResponse.headers.append('Set-Cookie', `${COOKIE_NAME_TIME}=${now}; path=/`)
    }

    newResponse.headers.append('Set-Cookie', `${COOKIE_NAME_ID}=${userId}; path=/`)
    return newResponse
}

async function getWaitingRoomResponse(userId) {
    const newResponse = new Response(waiting_room_html)
    newResponse.headers.set('content-type', 'text/html;charset=UTF-8')
    return newResponse
}


function makeid(length) {
    var result = ''
    var characters = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'
    var charactersLength = characters.length
    for (var i = 0; i < length; i++) {
        result += characters.charAt(Math.floor(Math.random() *
            charactersLength))
    }
    return result
}

const waiting_room_html = `
<title>Waiting Room</title>
<meta http-equiv='refresh' content='30' />

<style>*{box-sizing:border-box;margin:0;padding:0}body{line-height:1.4;font-size:1rem;font-family:ui-sans-serif,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,"Helvetica Neue",Arial,"Noto Sans",sans-serif;padding:2rem;display:grid;place-items:center;min-height:100vh}.container{width:100%;max-width:800px}p{margin-top:.5rem}</style>

<div class='container'>
  <h1>
    <div>You are now in line.</div>
    <div>Thanks for your patience.</div>
  </h1>
  <p>We are experiencing a high volume of traffic. Please sit tight and we will let you in soon. </p>
  <p><b>This page will automatically refresh, please do not close your browser.</b></p>
</div>
`


const default_html = `
<title>Waiting Room Demo</title>

<style>*{box-sizing:border-box;margin:0;padding:0}body{line-height:1.4;font-size:1rem;font-family:ui-sans-serif,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,"Helvetica Neue",Arial,"Noto Sans",sans-serif;padding:2rem;display:grid;place-items:center;min-height:100vh}.container{width:100%;max-width:800px}p{margin-top:.5rem}</style>

<div class="container">
  <h1>
    <div>Waiting Room Demo</div>
  </h1>
    <p>
              Visit this site from a different browser, you will be forwarded to the waiting room when the capacity is full.
    </p>
  <p>  Check <a href={"https://github.com/upstash/waiting-room"} style={{"color": "blue"}}>this project </a> to set up a waiting room for your website.</p>
</div>
`

In the above code, you can edit the waiting_room_html variable. It is the static html of the waiting room page.

handleRequest method returns either getDefaultResponse or getWaitingRoomResponse depending on the availability of your website.

`4` Run Locally

To test the waiting room locally, it might make sense to set capacity to 1, session duration to 30 seconds. Then run


wrangler dev

Now open http://127.0.0.1:8787/ at Chrome, you will see:

And then open the same url on Safari (or Chrome incognito), you will see:

Wait for longer than 30 seconds. You should see the page in waiting room will refresh and enter the website.

Our local does not forward to a real website so we see the 404 page of Cloudflare, that’s ok.

`5` Publish

Deploy your CF Workers function with:


wrangler publish

It will give you a url like: https://waiting-room.upsdev.workers.dev/

Now let’s route our worker to your website. First your domain's nameservers should point to Cloudflare. Check this. Then, you need to add your domain as a route and select your Workers function in the CF Workers dashboard.

Conclusion

We have successfully built a waiting room without touching our application code thanks to Cloudflare Workers and Upstash Redis. We believe this is another indicator of how powerful edge functions become together with Upstash.

There are things to improve:

Estimated waiting time: We could calculate and show average waiting time.
Fair and ordered queue: Currently waiting visitors randomly enter the site when there is availability. We might keep a queue and try to let visitors in an ordered way.

Both of the above improvements require keeping more state and making more remote calls. That’s why we preferred to skip those. If your use case strictly requires those, you may check this blog to be inspired from Cloudflare team’s work on their enterprise solution.

Check the source code.

Let us know your thoughts on Twitter or Discord.

Building a Serverless Notification API for Your Web Application with Redis

Enes Akar — Fri, 29 Oct 2021 17:51:43 +0000

Notifications and announcements help you communicate with your web site visitors. It is not feasible to update your code and redeploy your website each time you want to show a new message. It may also be too much investment to set up a backend and maintain it to just serve these notifications. In this article, we will build a website which will load the notification message directly from the Redis database without a backend.

Backendless? How is that possible?

Yes, we will not use any backend service, even a serverless function. We will access Redis from the client side directly. This is possible with the read only REST API provided by Upstash.

Requirements

The page will display a notification if the user has not already seen the notification before.
The page will only show the latest notification.

Check out the code here.

Project Setup

I will create a React application but you can use any other web framework. It will simply call the Redis REST API and show the message as a notification.

Create the app:

npx create-react-app serverless-notification-api

Install a toast component to show the notification:

npm install --save react-toastify

Create a free database from Upstash and copy the REST url and read only token. You should switch the Read-Only Token setting. In the database details page, click on the Read-Only Token switch.

Implementation

The logic is simple. We will keep the notifications in a Redis Sorted Set. We will keep a version (integer) in the local storage. We will use the versions as scores in the sorted set. Each notification message will have a version (score) and the higher score means the newer message. At each page load, we will query the Redis sorted set to load the messages which have higher scores than the locally stored version. After loading a notification message I will set my local version equal to the latest notification’s version. This will prevent showing the same notification to the same users more than once. Here the implementation:

import logo from './logo.svg';
import './App.css';
import {ToastContainer, toast} from 'react-toastify';
import 'react-toastify/dist/ReactToastify.css';
import {useEffect} from "react";

function App() {

   useEffect(() => {
       async function fetchData() {
           try {
               let version = localStorage.getItem("notification-version");
               version = version ? version : 0;
               const response = await fetch("REPLACE_UPSTASH_REDIS_REST_URL/zrevrangebyscore/messages/+inf/" + version + "/WITHSCORES/LIMIT/0/1", {
   headers: {
       Authorization: "Bearer REPLACE_UPSTASH_REDIS_REST_TOKEN"
   }
});
               const res = await response.json();
               const v = parseInt(res.result[1]);
               if (v) {
                   localStorage.setItem("notification-version", v + 1)
               }
               toast(res.result[0]);
           } catch (e) {
               console.error(e);
           }
       };
        fetchData();
   });

   return (
       <div className="App">
           <header className="App-header">
               <img src={logo} className="App-logo" alt="logo"/>
               <p>
                   Edit <code>src/App.js</code> and save to reload.
               </p>
               <a
                   className="App-link"
                   href="https://reactjs.org"
                   target="_blank"
                   rel="noopener noreferrer"
               >
                   Learn React
               </a>
           </header>
           <ToastContainer/>
       </div>
   );
}

export default App;

How to Add New Notification Messages

You can simply add new messages to the Redis sorted set with a highest score so it will be displayed to the user with page loads. For our application the name of the sorted set is messages.

You can also remove a message using the ZREM command.

Conclusion

You do not need a backend to access Upstash Redis thanks to the REST API. You can expose the token with your client side application, as the token only allows read-only access. This helps developers to build applications without backend for many use cases where the data is already available publicly.

Serverless API with Java and Redis

Enes Akar — Thu, 30 Sep 2021 23:48:42 +0000

In this tutorial, we will build a stateful serverless API using Java and Redis on AWS Lambda. The API will simply count the page views and return it as http response.

Prerequisites

Install node and npm
Install the Serverless Framework installed with an AWS account set up.
Install JDK and not Java JRE. Set your JAVA_HOME.
Install Apache Maven.
Create a free Serverless Redis database from Upstash as described here.

Project Setup

Create the project:

serverless create --template aws-java-maven --name serverless-api-java-redis -p serverless-api-java-redis

Add jedis as dependency to the pom.xml:

<dependency>
   <groupId>redis.clients</groupId>
   <artifactId>jedis</artifactId>
   <version>3.6.0</version>
</dependency>

Update serverless.yml adding an http endpoint as below:

functions:
 hello:
   handler: com.serverless.Handler
   events:
     - httpApi:
         path: /hello
         method: get

The Code

Update Handler.java as below:

package com.serverless;

import java.util.Map;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import redis.clients.jedis.Jedis;

public class Handler implements RequestHandler<Map<String, Object>, ApiGatewayResponse> {
  @Override
  public ApiGatewayResponse handleRequest(Map<String, Object> input, Context context) {
     Jedis jedis = new Jedis("us1-lasting-lion-32618.upstash.io", 32618, true);
     jedis.auth("d5033b46dfbgheb6718f9dbbd2925");
     Long value = jedis.incr("counter");
     String message = "Hello World, Count:" + value;
     return ApiGatewayResponse.builder()
           .setStatusCode(200)
           .setObjectBody(message)
           .build();
  }
}

In the above code, you need to replace your Redis endpoint and password. You can copy Jedis connection code from the Upstash console.

Deploy and Run

First build your project with mvn clean install. Then deploy to AWS with serverless deploy. The last command will output the endpoint URL as below:


Serverless: Stack update finished...

Service Information

service: serverless-api-java-redis

stage: dev

region: us-east-1

stack: serverless-api-java-redis-dev

resources: 11

api keys:

  None

endpoints:

  GET - https://60tinzba0a.execute-api.us-east-1.amazonaws.com/hello

functions:

  hello: serverless-api-java-redis-dev-hello

layers:

  None

AWS Lambda vs Cloudflare Workers

Enes Akar — Thu, 30 Sep 2021 18:41:38 +0000

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.

Performance

AWS Lambda runs in containers and at the selected runtime (e.g. Node). Cloudflare Workers run your code in V8 Isolates. Cloudflare Workers has minimal latency in runtime startups. This eliminates the famous cold start problem.

In addition, because Cloudflare Workers is distributed globally on the Cloudflare network; you will experience lower latency all over the world. To minimize latency in AWS Lambda, your function and client must reside in the same region.

According to this benchmark; Cloudflare Workers looks to perform better. Note that the comparison was made by Cloudflare.

In this category, Cloudflare Workers wins.

Runtime & Language Support

AWS Lambda natively supports Java, Go, PowerShell, Node.js, C#, Python, and Ruby. Cloudflare Workers supports Javascript and TypeScript. Cloudflare Workers also supports WASM Compiled languages, but using them doesn't seem very easy.

This category is a clear win for AWS Lambda.

Configurability and Limitations

With AWS Lambda, you can choose a custom runtime (Layers) and memory size from 128MB to 10GB. Cloudflare Workers memory is fixed at 128MB. AWS Lambda function can run up to 900 seconds (max timeout). This is 30 seconds for Cloudflare Workers.

Cloudflare Workers are not Node-based, so packages that require Node dependencies are not supported in Cloudflare Workers. AWS Lambda has no such issue.

AWS Lambda wins in this category.

Pricing

AWS request pricing: $0.2 per 1M requests

Cloudflare Workers request pricing: $0.15 per 1M requests

AWS duration pricing: $16.67 per million GB/s

Cloudflare Workers duration pricing: $12.50 per million GB/s

In this category, Cloudflare Workers wins.

Tools and Resources

AWS Lambda was introduced in 2014. Cloudflare Workers was released in 2018. AWS Lambda is considered the pioneer of the serverless space. There are numerous third-party management and deployment tools for AWS Lambda. You'll find more tools and technical resources on AWS Lambda than Cloudflare Workers.

AWS Lambda wins in this category.

Ecosystem and Integrations

You can use most AWS services with AWS Lambda. You can access AWS databases and use AWS services to trigger your function. AWS Lambda can be part of many different use cases with different components. It can be part of an API for the web service as well as a stream processing engine. Cloudflare Workers has far fewer options. Use cases are mostly limited to web applications and edge computing. You can use Cloudflare Workers with Worker KV and Durable Objects, but they provide much more limited use cases than all AWS services.

AWS Lambda obviously wins this category.

Category	Winner
Performance	Cloudflare Workers
Runtime & Language Support	AWS Lambda
Tools and Resources	AWS Lambda
Pricing	Cloudflare Workers
Ecosystem and Integrations	AWS Lambda
Configurability and Limitations	AWS Lambda

What about Lambda@Edge?

It might make sense to compare Cloudflare Workers with Lambda@Edge rather than Lambda. But it seems to me that Lambda@Edge is more of a feature of Cloudfront than a standalone product. Other than a few blog posts and announcements, I couldn't find many resources. Maybe AWS isn't investing much in this anymore.

Conclusion

In this post, I tried to compare two popular serverless products based on my experiences and observations. So if you think differently, please leave a comment here or on my twitter.

There is no clear answer to the question of which product is better. It depends on the use case and your personal preferences. While AWS Lambda seems like the safer choice for many use cases; Cloudflare Workers is an excellent choice for use cases where you need low latency globally.

Best Databases for Serverless

Enes Akar — Tue, 28 Sep 2021 18:14:26 +0000

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.

What makes a database great for Serverless?

Ease of use: Next generation developers do not want to spend days and weeks learning the technologies. They want to learn by watching youtube videos instead of reading pages of docs. So a database for serverless should be simple and intuitive.
Serverless Pricing: The price should scale to zero. Why should I pay for something that I do not use. Pricing models based on per-bandwidth or per-request are serverless as they correlate with your exact usage. Personally I prefer per-request as it is always easier to estimate than bandwidth.
Developer friendly pricing: Pricing should be simple without traps. Some pricing pages are so complicated that there are extra articles and blog posts to explain the details. Some vendors have complex calculators. Unfortunately most vendors prefer a complex pricing to minimize their risks. So it is hard to foresee how much you will pay before seeing the invoice.
Serverless Connections: Serverless functions can scale to hundreds even thousands in seconds. If your database requires persistent connections then you can easily hit the connection limits of your database. HTTP based connections do not have such a problem as those are more lightweight and generally do not have such limitations.
Low latency: Extra latency is cost in serverless functions. But the real cost is the unhappy users waiting idle on your website.
Portability: If you want to move to another cloud vendor, do you have to rewrite the data layer. Or are you able to test your application in your laptop without connecting to the remote database.
Consistency: Generally, there is a tradeoff between consistency and performance. The databases are at different places on the consistency & performance spectrum. A good database should clearly define its consistency guarantees so the user will be aware of the possible issues and risks
Scalability: The database should keep up when your application starts to receive high throughput. Ideally, scaling should be automatic or managed by the cloud provider. You should not worry about it.
Edge friendly: Cloudflare Workers and Fasty Compute are cool technologies which enable you to run your serverless functions at the edge closest to your user. Those require REST based connections but also globally replicated database to minimize the latency.
Globality: As your application gets globally popular, you need a database which provides good performance all over the world. Multi region replication is the key feature to enable this. But be careful, check the pricing. This feature can be expensive.

The best databases for Serverless?

In this section, I will share my impressions and notes from trying the following databases. They are not based on scientific analysis but I hope to give you an idea before doing any real comparison analysis.

MongoDB (Atlas)

Ease of use: MongoDB is the most popular NoSQL database and document store. Its API is very simple and intuitive thanks to its JSON based data model.
Portability: Almost all cloud providers have database products with MongoDB API as well as you can run MongoDB yourself on-premise. So there is no portability issue.
MongoDB Atlas recently announced its Serverless database type. My personal impression is that it was more like a hosted MongoDB instance under a serverless pricing model. As seen here many features are not supported for Serverless database including Node.js SDK.
Serverless Connections: MongoDB Atlas does not provide you an HTTP based (e.g. REST) API. You can hit the connection limit easily. That’s why they publish articles how to avoid this https://docs.atlas.mongodb.com/best-practices-connecting-from-aws-lambda/

https://www.mongodb.com/community/forums/t/what-optimizations-for-not-hitting-connection-limit-in-serverless-functions/11507

Cassandra (Datastax Astra)

Datastax Astra provides REST and GraphQL API in addition to native Cassandra drivers.
Ease of use: For me it was harder to learn Cassandra compared to MongoDB and Redis. However, Datastax team did a good job with the console, it was very intuitive. But still I remember I was lost in the docs with different versions of the REST API.
Developer friendly pricing: The pricing of Datastax Astra is not a simple one. Every unit is calculated separately (reads, writes, bandwidth) and they have different prices depending on cloud provider and even region. Datastax has its own definition of read/write units (RRU and WRU).

DynamoDB (AWS)

Ease of use: If you are an AWS user, it is easy to start and work with DynamoDB. However I think MongoDB has an easier and more intuitive query API.
Serverless connections: DynamoDB connections are http based, you do not have any connection limit problem.
Portability: Biggest problem is here. You can not use DynamoDB anywhere but AWS.

FaunaDB

Consistency: Probably FaunaDB is the best on this list in terms of consistency. It guarantees consistency along with global replication. But beware that this comes at extra performance costs. Consider whether you really need such a strong consistency.
Performance: It has higher latency than others due to its strong consistency.
Ease of use: Honestly, FQL was the hardest one for me to learn and use. But FaunaDB also supports GraphQL API, so it might be easier.
Serverless connections: Thanks to its HTTP based connection, FaunaDB does not have problem with connection limits.

Upstash

Ease of use: Redis is probably the easiest to learn API in this list. Upstash makes it easy to use in the cloud with its intuitive and simple interface.
Developer friendly pricing: Upstash pricing is based on per-request. It also sets price-caps, so it guarantees that you will not pay more than a predetermined amount.
Performance: Thanks to memory based storage, Upstash gives the best latency numbers. Check this to get an idea.
If you need complex query capabilities (joins etc), Redis data structures may not be practical. You may need a database with better SQL support in such a case.

Firestore

Ease of use: Firestore is one of the best in this list for this category. The UI and API is quite intuitive.
Portability: Just like DynamoDB, Firestore has a vendor-lock problem. It is good as long as you are on Google Cloud.
Performance: I heard some complaints about its performance before. I have personally experienced its latency is worse than others together with FaunaDB. So there is a question mark here.

Closing Words

I believe that serverless is the future of development and there is an ongoing transition towards serverless. Serverless enables developers and small companies to create scalable products with a very limited budget. Databases should be part of this transition with offerings which are coherent with serverless principles.

5 ms Global Redis Latency with Edge Caching

Enes Akar — Mon, 23 Aug 2021 16:54:33 +0000

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.

Edge Caching

With edge caching, REST responses are cached at edge locations all over the world, just like the CDN. We see 5ms global latency at average when edge caching is enabled. See our benchmark application where we record latency numbers from the clients located in 10 different regions. We compare the latency between the requests that are made to edge url and plain REST url. As the distance between the server and the client increases, the impact of edge caching increases.

Click here to run the test yourself.

Use cases

Web/mobile (backendless) clients

Upstash provides read only authentication tokens to enable users to access the database without any backend. You can directly access the Redis from the web or mobile application. In this architecture, clients can be anywhere. It makes a lot of sense to cache the data in locations closest to your users.

Multi region serverless architectures

You can run your AWS Lambda function in multiple regions to lower global latency. Vercel/Netlify functions run in different regions in some configurations. Serverless Redis with edge caching will give you fast data wherever your serverless functions are.

Edge functions

Edge computing (Cloudflare workers etc) is becoming a popular way of building globally fast applications. The challenge with edge functions is that you do not have many options to keep your data. Redis with edge caching is a great fit for edge functions with its low latency and lightweightness.

Get Started

You can enable edge caching, in the Upstash console. Beware that edge caching has an extra cost.

Once edge caching is enabled, you can find the Edge URL in the REST API dialog. Edge caching is available only for GET calls. For updates (POST), you can still use the plain REST API.

By default, the cached responses expire in 30 seconds. You can control this with the Cache-Control: max-age=<seconds> header.

Example:

curl https://us1-smart-bunny-32732.edge-c.upstash.io/get/foo \

-H "Authorization: Bearer 2dfgf98elrg0w009c842z2adfdde9132"

-H "Cache-Control: max-age=50"

The first request to the above URL will fetch the response from the origin. The next requests will be fetched from edge locations. The cached responses will expire after 50 seconds at each edge location.

Edge Caching vs Global Database

Building a global database by replicating Redis to multiple regions is in our roadmap. Global databases will give you better consistency guarantees and write latency by replicating the writes too. But it can be very costly to replicate the database to all regions. Still you may need caching to minimize latency in all locations. So Edge caching and Global replication are solutions that complete each other rather than compete. If your use case tolerates eventually consistent reads, edge caching is already a great solution which provides global fast data.

Looking forward to hearing from you about our efforts on serverless and edge data. Talk to us on twitter and discord.

The Most Minimalist Next.js TODO app

Enes Akar — Wed, 14 Jul 2021 08:06:09 +0000

In this article, we will build a Serverless Next.js based TODO application. We will try our best to make it minimalist. It will not have any database connection. It will not have any extra dependency other than Next.js. It will not have any buttons. Besides, minimalism is cool and clean, I love it because I am a lazy developer :)

Why do we avoid database connections?

Next.js is a modern framework which enables the front-end developers to develop full stack applications. Serverless functions have an important role in simplifying backend development for Next.js developers. As you probably know, serverless functions do not like database connections due to their stateless nature. See here and here as examples of problems of database connections inside serverless functions.

REST is an answer

REST allows client and server to communicate with no session information. This statelessness and its simple nature makes REST a perfect communication protocol for serverless environments. We will access Upstash Redis with REST.

The Project Stack

Frontend: Next.js
Backend: Vercel functions
Database: Upstash Redis with REST API

See the demo: https://nextjs-todo-zeta.vercel.app/

See the code: https://github.com/upstash/examples/tree/master/nextjs-todo

The Project Setup

Create a Next.js app: npx create-next-app

Create an Upstash Redis database in AWS-US-EAST-1 region and copy the REST URL and token.

The project will be a single page application with 3 API endpoints:

pages/api/list.js: Lists the TODO items.
pages/api/add.js: Adds a TODO item.
pages/api/remove.js: Removes a TODO item.

The Code

Add pages/api/list.js as below:

export default async (req, res) => {
   const token = "REPLACE_YOUR_TOKEN";
   const url = "https://REPLACE_YOUR_ENDPOINT/lrange/todo/0/100?_token=" + token;

   return fetch(url)
       .then(r => r.json())
       .then(data => {
           let result = JSON.stringify(data.result)
           return res.status(200).json(result)
       })
}

Add pages/api/add.js as below:

export default async (req, res) => {
   if(!req.query.todo) {
       return res.status(400).send("todo parameter required.")
   }
   let todo = encodeURI(req.query.todo)

   const token = "REPLACE_YOUR_TOKEN";
   const url = "https://REPLACE_YOUR_ENDPOINT/lpush/todo/" + todo + "?_token=" + token;

   return fetch(url)
       .then(r => r.json())
       .then(data => {
           let result = JSON.stringify(data.result)
           return res.status(200).json(result)
       })
}

Add pages/api/remove.js as below:

export default async (req, res) => {
   if(!req.query.todo) {
       return res.status(400).send("todo parameter required.")
   }
   let todo = encodeURI(req.query.todo)

   const token = "REPLACE_YOUR_TOKEN";
   const url = "https://REPLACE_YOUR_ENDPOINT/lrem/todo/1/" + todo + "?_token=" + token;

   return fetch(url)
       .then(r => r.json())
       .then(data => {
           let result = JSON.stringify(data.result)
           return res.status(200).json(result)
       })
}

Update pages/index.js as below:

import Head from 'next/head'
import Image from 'next/image'
import styles from '../styles/Home.module.css'
import {useEffect, useState} from "react";

export default function Home() {
   const [data, setData] = useState([]);
   const [loading, setLoading] = useState(false);
   const [todo, setTodo] = useState("");
   let changeHandler = (event) => {
       setTodo(event.target.value)
   }

   let addTodo = (event) => {
       setLoading(true)
       event.preventDefault();
       fetch('/api/add?todo=' + todo)
           .then(res => res.json())
           .then(data => {
               loadTodos()
           })
   }

   let removeTodo = (rtodo) => {
       setLoading(true)
       fetch('/api/remove?todo=' + rtodo)
           .then(res => res.json())
           .then(data => {
               loadTodos()
           })
   }

   let loadTodos = () => {
       console.log("load todos")
       fetch('/api/list')
           .then(res => res.json())
           .then(data => {
                   setData(data)
                   setLoading(false)
               }
           )
   }

   useEffect(() => {
       setLoading(true)
       loadTodos()
   }, [])

   if (!data) return "Loading...";
   return (
       <div className={styles.container}>
           <Head>
               <title>Next.js TODO APP</title>
               <meta name="description" content="Generated by create next app"/>
               <link rel="icon" href="/favicon.ico"/>
           </Head>

           <main className={styles.main}>
               <div className={styles.grid}>
                   <h1 className={styles.title}>
                       TODO App with <a href="https://blog.upstash.com/nextjs-todo">Next.js!</a>
                       <br/>
                       <br/>
                   </h1>
                   {
                       loading ?
                           <a href="#" className={styles.card}>
                               <img src="/loader.gif"/>
                           </a>
                           :
                           <form className={styles.cardForm} onSubmit={addTodo}>
                               <input className={styles.cardInput} type="text"
                                      name="todo" onChange={changeHandler}
                                      placeholder="Enter your exciting TODO item!"/>
                           </form>
                   }

                   {data.map((item) =>
                       <a href="#" onClick={() => removeTodo(item)} className={styles.card}>
                           <p>{item}</p>
                       </a>)}

               </div>
           </main>

           <footer className={styles.footer}>
               <a
                   href="https://blog.upstash.com/nextjs-todo"
                   target="_blank"
                   rel="noopener noreferrer"
               >
                   Powered by{' '}
                   <span className={styles.logo}>
           <Image src="/logo.png" alt="Upstash Logo" width={87} height={25}/>
         </span>
               </a>
           </footer>
       </div>
   )
}

As you see, it is a basic React application which uses hooks. We have 3 methods which interact with APIs: addTodo, removeTodo and loadTodos.

And finally update the styles/Home.module.css file as here.

Run and Deploy

Run your project locally with npm run dev. If everything looks good, you can deploy your project by running vercel in the project folder. Vercel will create serverless functions for your API functions. The default region for Vercel functions is US-EAST-1, that’s why we created our database in the same region.

NOTES

It is safer to keep the database token in a Vercel environment variable.
It is best for performance to keep the serverless function and Redis database in the same region.
We could use Redis clients instead of REST API. But as I mentioned before, the database connections can cause issues inside serverless functions. Also note that we did not see a major performance difference between Upstash REST API and native API.

Session Management on Google Cloud Run with Serverless Redis

Enes Akar — Mon, 05 Jul 2021 13:12:18 +0000

Developers are moving their apps to serverless architectures and one of the most common questions is how to store user sessions. You need to keep your state and session data in an external data store because serverless environments are stateless by design. Unfortunately most of the databases are not serverless friendly. They do not support per-request pricing or they require heavy and persistent connections. These also explain the motivations why we built Upstash. Upstash is a serverless Redis database with per-request pricing, durable storage.

In this article I will write a basic web application which will run on Google Cloud Run and keep the user sessions in Upstash Redis. Google Cloud Run provides Serverless Container service which is also stateless. Cloud Run is more powerful than serverless functions (AWS Lambda, Cloud Functions) as you can run your own container. But you can not guarantee that the same container instance will process the requests of the same user. So you need to keep the user session in an external storage. Redis is the most popular choice to keep the session data thanks to its speed and simplicity. Upstash gives you the serverless Redis database which fits perfectly to your serverless stack.

If you want to store your session data manually on Redis, check here. But in this article I will use Express session middleware which can work with Redis for user session management.

Here is the live demo.

Here is the source code

The Stack

Serverless processing: Google Cloud Run

Serverless data: Upstash

Web framework: Express

Project Setup

Create a directory for your project:


mkdir cloud-run-sessions

cd cloud-run-sessions

Create a node project and install dependencies:


npm init

npm install express redis connect-redis express-session

Create a Redis DB from Upstash. In the database details page, click the Connect button, copy the connection code (Node.js node-redis).

If you do not have it already, install Google Cloud SDK as described here. Set the project and enable Google Run and Build services:


gcloud config set project cloud-run-sessions

gcloud services enable run.googleapis.com

gcloud services enable cloudbuild.googleapis.com

The Code

Create index.js and update as below:

var express = require('express')
var parseurl = require('parseurl')
var session = require('express-session')
const redis = require('redis')

var RedisStore = require('connect-redis')(session)
var client = redis.createClient ({
// REPLACE HERE
});

var app = express()

app.use(session({
store: new RedisStore({ client: client }),
secret: 'forest squirrel',
resave: false,
saveUninitialized: true
}))

app.use(function (req, res, next) {
if (!req.session.views) {
req.session.views = {}
}

// get the url pathname
var pathname = parseurl(req).pathname

// count the views
req.session.views[pathname] = (req.session.views[pathname] || 0) + 1
next()
})

app.get('/', function (req, res, next) {
res.send('you viewed this page ' + req.session.views['/'] + ' times')
})

app.get('/foo', function (req, res, next) {
res.send('you viewed this page ' + req.session.views['/foo'] + ' times')
})

app.get('/bar', function (req, res, next) {
res.send('you viewed this page ' + req.session.views['/bar'] + ' times')
})

app.listen(8080, function () {
console.log('Example app listening on port 8080!');
});

Run the app: node index.js

Check http://localhost:3000/foo in different browsers to validate it keeps the session.

Add the start script to your package.json:

"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "node index"
  }

Build

Create a Docker file (Dockerfile) in the project folder as below:

# Use the official lightweight Node.js 12 image.
# https://hub.docker.com/_/node
FROM node:12-slim

# Create and change to the app directory.
WORKDIR /usr/src/app

# Copy application dependency manifests to the container image.
# A wildcard is used to ensure both package.json AND package-lock.json are copied.
# Copying this separately prevents re-running npm install on every code change.
COPY package*.json ./

# Install dependencies.
RUN npm install

# Copy local code to the container image.
COPY . ./

# Run the web service on container startup.
CMD [ "npm", "start" ]

Build your container image:


gcloud builds submit --tag gcr.io/cloud-run-sessions/main

List your container images: gcloud container images list

Run the container locally:


gcloud auth configure-docker

docker run -d -p 8080:8080 gcr.io/cloud-run-sessions/main:v0.1

In case you have an issue on docker run, check here.

Deploy

Run:


gcloud run deploy cloud-run-sessions \

  --image gcr.io/cloud-run-sessions/main:v0.1 \

  --platform managed \

  --region us-central1 \

  --allow-unauthenticated

This command should give you the URL of your application as below:

Deploying container to Cloud Run service [cloud-run-sessions] in project [cloud-run-sessions] region [us-central1]

  ✓ Deploying... Done.                                                                                                                                 

  ✓ Creating Revision...                                                                                                                             

  ✓ Routing traffic...                                                                                                                               

  ✓ Setting IAM Policy...                                                                                                                            

Done.                                                                                                                                                

Service [cloud-run-sessions] revision [cloud-run-sessions-00006-dun] has been deployed and is serving 100 percent of traffic.

Service URL: https://cloud-run-sessions-dr7fcdmn3a-uc.a.run.app

Cloud Run vs Cloud Functions

I have developed two small prototypes with both. Here my impression:

Simplicity: Cloud functions are simpler to deploy as it does not require any container building step.
Portability: Cloud Run leverages your container, so anytime you can move your application to any containerized system. This is a plus for Cloud Run.
Cloud Run looks more powerful as it runs your own container with more configuration options. It also allows running longer tasks (can be extended to 60 minutes)
Cloud Run looks more testable as you can run the container locally. Cloud Functions require a simulated environment.

Personally, I see Cloud Functions as a pure serverless solution where Cloud Run is a hybrid solution. I would choose Cloud functions for simple, self contained tasks or event driven solutions. If my use case is more complex with portability/testability requirements, then I would choose Cloud Run.

Build a Serverless Leaderboard API At Edge using Cloudflare Workers and Redis

Enes Akar — Sat, 03 Jul 2021 08:52:51 +0000

With edge functions, it is possible to run your backend at the closest location to your users. Cloudflare Workers and Fastly Compute@Edge runs your function at the closest location to your user using their CDN infrastructure.

In this article we will implement a very common web use case at Edge. We will implement a leaderboard API without any backend servers, containers or even serverless functions. We will just use edge functions. Leaderboard will have the following APIs:

addScore: Adds a score with the player's name. This will write the score to the Upstash Redis directly from the Edge functions.
getLeaderBoard: Returns the list of score-player pairs. This call will first check the Edge cache. If the leaderboard does not exist at the Edge Cache then it will fetch it from the Upstash Redis.

Project Setup

In this tutorial, we will use Cloudflare Workers and Upstash. You can create a free database from Upstash Console. Then create a Workers project using Wrangler.

Install wrangler: npm install -g @cloudflare/wrangler

Authenticate: wrangler login or wrangler config

Then create a project: wrangler generate edge-leaderboard

Open wrangler.toml. Run wrangler whoami and copy/paste your account id to your wrangler.toml.

Find your REST token from database details page in the Upstash Console. Copy/paste your token to your wrangler toml as below:

name = "edge-leaderboard"
type = "javascript"

account_id = "REPLACE_YOUR_ACCOUNT_ID"
workers_dev = true
route = ""
zone_id = ""

[vars]
TOKEN = "REPLACE_YOUR_UPSTASH_REST_TOKEN"

The Code

The only file we need is the Workers Edge function. Update the index.js as below:

addEventListener("fetch", event => {
 event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
 if (request.method === "GET") {
   return getLeaderboard();
 } else if (request.method === "POST") {
   return addScore(request);
 } else {
   return new Response("Invalid Request!")
 }
}

async function getLeaderboard() {
 let url = "https://us1-full-bug-31874.upstash.io/zrevrange/scores/0/1000/WITHSCORES/?_token=" + TOKEN;
 let res = await fetch(new Request(url),
   {
     cf:
       {
         cacheTtl: 10,
         cacheEverything: true,
         cacheKey: url,
       },
   }
 )
 return res;
}

async function addScore(request) {
 const { searchParams } = new URL(request.url)
 let player = searchParams.get('player')
 let score = searchParams.get('score')
 let url = "https://us1-full-bug-31874.upstash.io/zadd/scores/" + score + "/"  + player + "?_token=" + TOKEN;
 let res = await fetch(url)
 return new Response(await res.text())
}

We route the request to two methods: if it is a GET, we return the leaderboard. If it is a POST, we read the query parameters and add a new score.

In the getLeaderboard() method, you will see we pass a cache configuration to the fetch() method. It caches the result of the request at the Edge for 10 seconds.

Test The API

In your project folder run wrangler dev. It will give you a local URL. You can test your API with curl:

Add new scores:

curl -X POST http://127.0.0.1:8787\?player\=messi\&score\=13

curl -X POST http://127.0.0.1:8787\?player\=ronaldo\&score\=17

curl -X POST http://127.0.0.1:8787\?player\=benzema\&score\=18

Get the leaderboard:

curl -w '\n Latency: %{time_total}s\n' http://127.0.0.1:8787

Call the “curl -w '\n Total: %{time_total}s\n' http://127.0.0.1:8787” multiple times. You will see the latency becomes very small with the next calls as the cached result comes from the edge.

If you wait more than 10 seconds then you will see the latency becomes higher as the cache is evicted and the function fetches the leaderboard from the Upstash Redis again.

Deploy The API

First change the type in the wrangler.toml to webpack

name = "edge-leaderboard"
type = "webpack"

Then, run wrangler publish. Wrangler will output the URL. If you want to deploy to a custom domain see here.

Coming Soon: Built in Edge Caching

In this example, we have used Cloudflare Cache to cache the Redis result at the edge. Soon, Upstash will provide a separate REST URL which will be cached at the Edge by default. So Upstash users will be able to access Edge caching in all environments.

Redis at the Edge with Cloudflare Workers

Enes Akar — Wed, 16 Jun 2021 04:05:52 +0000

Computing at the Edge is one of the most exciting capabilities in recent years. CDN allows you to keep your files closer to your users. Edge computing allows you to run your applications closer to your users. This helps developers to build globally distributed, performant applications.

Cloudflare Workers is the leading product in this space right now. It gives you a serverless processing environment without cold starts. You leverage Cloudflare's global network to minimize latency of your applications. You can write your functions in Javascript, Rust, C and C++.

Similar to Serverless functions (AWS Lambda etc.), Cloudflare Workers are stateless. As you can see in Cloudflare’s survey, developers are asking ways to connect their databases from Edge functions. Unfortunately, most databases are not designed for serverless environments, they require persistent connections. We developed the REST API over Redis to enable serverless edge functions to access Upstash in the simplest and fastest way possible.

Comparing with Cloudflare Workers KV

Cloudflare has a basic Key Value store that you can use to store the state of your Edge functions. Upstash Redis excels against Cloudflare KV in several aspects:

Cloudflare KV provides only basic get/set/delete functionality. Upstash gives you all Redis data structures where you can build much more sophisticated functionality (Hashes, Lists, SortedSets, ranges, appends, increments etc).
Cloudflare KV is designed to be accessible from the Cloudflare ecosystem while you can access and consume the Upstash Redis from anywhere as it supports both Redis and REST API. You can offload your data from Edge to Redis then process by any Redis client.
Cloudflare KV is optimized for read heavy applications. The writes can take 60 seconds to be replicated to other locations. The write latencies are in milliseconds for Upstash.

Now let’s write a simple example to showcase the power of Cloudflare+Redis combination.

Analytics at Edge

Web analytics is a very common need for all website owners. Google Analytics is powerful but many developers do not like sharing their traffic data with Google and injecting cookies to users’ browsers. As your website traffic comes through CDN, you can easily track your traffic at the Edge layer. Here we will implement a very simple example to showcase tracking user traffic from Cloudflare Workers. We will intercept the traffic in the Cloudflare Workers and save the user requests to Upstash Redis. Then we will write a basic standalone application which will analyse the requests and give me the following information on a selected day:

Page views
Unique visitors
Top countries with the most number of visitors
Most visited pages

Setup

If you do not have one, create a database following this guide. In the database page, click the button REST API and copy the REST URL. If you have a Cloudflare account, you can create a Workers function or you can use the playground without an account too.

Cloudflare Workers Code

Cloudflare Workers function accepts request as a parameter. Using the REST API of Upstash, I record the request to a Redis List. I use the current date as the key for the Redis List. So we record the requests per day in separate Lists.

Upstash REST API requires an endpoint and a token. After creating a database, you can copy the endpoint and token from the console clicking to the REST API button. Update your Cloudflare Workers function with the below code, replacing endpoint and token:

const endpoint = 'REPLACE_UPSTASH_REST_ENDPOINT'
const token = 'REPLACE_UPSTASH_REST_TOKEN'

async function recordRequest(request) {
let d = new Date();
let datestr = d.getFullYear() + "-" + (d.getMonth()+1) + "-" + d.getDate();
 let data = [["url", request.url], ...request.headers]
 let url = endpoint + '/lpush/' + datestr
const init = {
   body: JSON.stringify(data),
   method: "POST",
   headers: {
     "Authorization": "Bearer " + token
   },
 }
 return await fetch(url, init);
}

async function handleRequest(request) {
 recordRequest(request);
 return new Response("My Awesome Website"); 
}

addEventListener("fetch", (event) => {
 event.respondWith(
   handleRequest(event.request).catch(
     (err) => new Response(err.stack, { status: 500 })
   )
 );
});

Analytics Tool Code

Now let’s write a simple command line application which will take the date as an argument and return us analytics data. Create a folder and run npm init. Then install the Redis client with npm install ioredis. Copy .env.example as .env file and set your Redis URL (ioredis). Update the index.js with below:

const Redis = require("ioredis");
require('dotenv').config()
console.log("EDGE analytics with CloudFlare Workers and Upstash Redis.")
let redis = new Redis(process.env.REDIS_URL);
let dateArg = process.argv[2]
let datestr;
if (dateArg) {
   datestr = dateArg;
} else {
   let d = new Date();
   datestr = d.getFullYear() + "-" + (d.getMonth()+1) + "-" + d.getDate();
}

redis.lrange(datestr, "0", "-1", function (err, result) {
   let pageview = 0;
   let users = new Set();
   let countries = new Map();
   let paths = new Map();
   if (err) {
       console.log("Could not connect to Redis.")
       console.error(err);
   } else {
       console.log("Upstash Redis Connection Successful. Analyzing the access logs...")
       if (!result || result.length === 0) {
           console.log("Could not find any access logs for the date:" + datestr);
       } else {
           for (const elem of result) {
               let entries = JSON.parse(elem)
               for (let entry of entries) {
                   if (entry[0] === "accept") {
                       if (entry[1].startsWith("text"))
                           pageview++;
                   }
                   if (entry[0] === "cf-ipcountry") {
                       let temp = countries.get(entry[1]);
                       if (!temp) {
                           temp = 0
                       }
                       countries.set(entry[1], temp + 1);
                   }
                   if (entry[0] === "url") {
                       let temp = paths.get(entry[1]);
                       if (!temp) {
                           temp = 0
                       }
                       paths.set(entry[1], temp + 1);
                   }
                   if (entry[0] === "x-real-ip") {
                       users.add(entry[1]);
                   }

               }
           }
           countries = new Map([...countries.entries()].sort((a, b) =>
               b[1] - a[1]
           ));
           paths = new Map([...paths.entries()].sort((a, b) =>
               b[1] - a[1]
           ));
           console.log("\nDATE: " + datestr)
           console.log("\nPAGE VIEWS: " + pageview)
           console.log("\nUNIQUE VISITORS: " + users.size)
           logMap("TOP COUNTRIES", countries);
           logMap("TOP PAGES", paths);
       }
   }
});

function logMap(title, data) {
   console.log("\n" + title);
   console.log("----------------");
   console.log(mapEntriesToString(data))
}

function mapEntriesToString(entries) {
   return Array
       .from(entries, ([k, v]) => `${k} : ${v}\n`)
       .join("");
}

Now you can run your application with node index 2021-6-16 or just node index. The latter one will query for today.

You can think of this example as a starting point. You can develop a rich web application with charts and tables according to your analytics needs. You can use other Redis data structures for more powerful analysis.

Upstash Edge Roadmap

REST API is the first step in our Edge story. We are planning two important developments this year.

Edge Caching: Right now, all your REST requests come to your database region. We will support Edge Caching soon, so your REST requests will be cached at all edge locations globally. This will enable Upstash Redis to provide low latency all around the world like the Cloudflare KV.
Global Replicated Databases: Global (multi region) replication will replicate your data to multiple regions. So all requests (both Redis and REST API) will go to the closest location. This will give you low latency globally with the least sacrifice on consistency.

I am planning to write a blog post dedicated to our Edge roadmap. Stay tuned and follow us on twitter.

Forem: Enes Akar

Best Databases for Next.js

TLDR

PlanetScale

My Comments:

Useful Links:

Supabase

My Comments:

Useful Links:

Upstash Redis

My Comments:

Useful Links:

Fauna

My Comments:

Useful Links:

MongoDB Atlas

My Comments:

Useful Links:

DynamoDB

My Comments:

Useful Links:

Conclusion

Use Serverless Kafka as an Event Source For AWS Lambda

Create Upstash Kafka

Create AWS Lambda Function

Lambda Function Code

Create AWS Secret

Edit AWS Lambda Role

Create the Trigger

Testing

Build your own Waiting Room for your Web site with Cloudflare Workers and Serverless Redis

Why?

How?

Why Cloudflare Workers?

Why Upstash Redis?

Step by Step Implementation

1 Project Setup

2 Update wrangler.toml

3 index.js

4 Run Locally

5 Publish

Conclusion

Building a Serverless Notification API for Your Web Application with Redis

Backendless? How is that possible?

Requirements

Project Setup

Implementation

How to Add New Notification Messages

Conclusion

Serverless API with Java and Redis

Prerequisites

Project Setup

The Code

Deploy and Run

AWS Lambda vs Cloudflare Workers

Performance

Runtime & Language Support

Configurability and Limitations

Pricing

Tools and Resources

Ecosystem and Integrations

What about Lambda@Edge?

Conclusion

Best Databases for Serverless

What makes a database great for Serverless?

The best databases for Serverless?

Closing Words

5 ms Global Redis Latency with Edge Caching

Edge Caching

Use cases

Web/mobile (backendless) clients

Multi region serverless architectures

Edge functions

Get Started

Edge Caching vs Global Database

The Most Minimalist Next.js TODO app

Why do we avoid database connections?

REST is an answer

The Project Stack

The Project Setup

`1` Project Setup

`2` Update wrangler.toml

`3` index.js

`4` Run Locally

`5` Publish