DEV Community: Noah

Rate Limiting at Edge with Cloudflare Workers and Serverless Redis

Noah — Mon, 22 Aug 2022 16:37:31 +0000

In this tutorial, we will show how to rate limit your applications using Cloudflare Workers and Upstash Redis. We will use the rate limiting SDK which keeps data in Upstash Redis.

Redis Setup

Create one or more Redis databases using Upstash Console or Upstash CLI. Do not choose Global, instead create multiple databases in different regions where you expect traffic to your site. (Why? We will explain later) You will need the REST URL and TOKENs in the next steps.

Project Setup

We will use Wrangler 2 for deployment, so install (or upgrade) Wrangler 2.

Create a folder for your project and run wrangler init. Select ts:

 ⛅️ wrangler 2.0.7 (update available 2.0.26)
------------------------------------------------------
Using npm as package manager.
✨ Created wrangler.toml
No package.json found. Would you like to create one? (y/n)
✨ Created package.json
Would you like to use TypeScript? (y/n)
✨ Created tsconfig.json
Would you like to create a Worker at src/index.ts? (y/n)
✨ Created src/index.ts

The Code

Update Workers function as below:

import { Redis } from "@upstash/redis/cloudflare";
import { MultiRegionRatelimit } from "@upstash/ratelimit";

export interface Env {
}

const cache = new Map();

export default {
  async fetch(
    request: Request,
    env: Env,
    _ctx: ExecutionContext,
  ): Promise<Response> {
    if (new URL(request.url).pathname == "/favicon.ico") {
      return new Response(null, { status: 400 });
    }

    const ratelimit = new MultiRegionRatelimit({
      redis: [
        new Redis({
          url: "https://us1-cool-macaque-32148.upstash.io",
          token: "AASQgODM5ZjExZGEtMZDRjOWI4ZmVjNmE3ZDk3NDIxMmEwNmNkYjVmOGVmZTk5Mz",
        }),
        new Redis({
          url: "https://eu2-merry-caribou-31549.upstash.io",
          token: "AXe5ASQgNmM5YmFiYWEtMmV3N2E1ODFiMWExMDc5NNGFiYWEwMzk2ZjE4ZWQ3N2Y",
        })
      ],
      limiter: MultiRegionRatelimit.fixedWindow(5, "5 s"),
      ephermeralCache: cache,
    });

    const userIP: string = request.headers.get('CF-Connecting-IP') || "none";

    const data = await ratelimit.limit(userIP);
    if (data.success) {
      // if you use CF Workers to intercept another site, uncomment below
      // return await fetch(request);
      return new Response(JSON.stringify({ message: "Success, you are not rate limited.", ip: userIP, data }, null, 2), { status: 200 });
    } else {
      // show an error page for rate limited users
      return new Response(JSON.stringify({ message: "You are rate limited, try again later.", ip: userIP,  data }, null, 2), { status: 200 });
    }
  },
};

Replace the REST_URL and TOKENs for the Redis instances above. You can add more Redis databases in different regions (or set a single one) depending on your traffic.

Test and Deploy

You can test the function locally with wrangler dev.

Deploy your function to Cloudflare with wrangler publish

The endpoint of the function will be printed. e.g. https://cloudflare-workers-rate-limiting.upsdev.workers.dev/ When you refresh the page 5 times consecutively, you should see you are rate limited.

Ok, the tutorial is over (it was easy, right?), now let's get into some details.

Isn't it costly to make remote call for each request?

It might be if we did not use the ephemeral cache. The ephemeral cache is a map object defined outside the handler. The rate limiting SDK uses it to cache identifiers while the serverless function is active (hot). It is important to define it outside the handler, so it will be a global variable. Cloudflare Workers does not guarantee different invocations will use the same variable but still it helps much to cache it during peak traffic.

Why not Global Database?

Upstash Global databases replicates Redis data to multiple regions. It perfectly fits for many edge use cases. But for rate limiting, we do not need to replicate data in one region to all other regions. Rate limiting sessions have local scopes. We could still use a global database, but that would be unnecessarily costly as each update would be replicated to all over the world. That's why we chose to create multiple regional databases as the rate-limiting SDK recommends.

IP as the identifier

We have used the user's IP as the identifier for the rate-limiting function. This means we limit the rate for a single user. If you have a better identifier in your request (username, email etc), use it. You can set a constant string if you want to limit traffic in total. Or you can use region or country (request.cf.country) as identifier to limit traffic per geography.

Can I use self hosted Redis?

Cloudflare Workers runs on V8 isolates and it does not allow TCP connections. So you can not access to self hosted Redis, Redislabs or Elasticache unless you use a REST Proxy. Upstash Redis has a built-in REST API.

Integration to your existing website

You can rate limit your existing web applications/sites without touching their code. You just need to create a site in Cloudflare and set nameservers for your domain accordingly. So Cloudflare will be able to intercept the requests to your website and run the Workers function. Also uncomment the line XX, so your Workers function will forward the request to your website, if the request is not rate limited.

Get Started with Google Cloud Functions

Noah — Sun, 20 Jun 2021 19:14:23 +0000

Google Cloud Functions is the second most popular serverless execution platform. Similar to AWS Lambda it is stateless, namely you need to access external resources to read or write your applications state. In this post, we will introduce Redis as a database for your Google Cloud functions.

This tutorial shows how to build a serverless API with Redis on Google Cloud Functions. The API will simply count the page views and show it in JSON format.

See the demo: https://us-central1-functions-317005.cloudfunctions.net/helloGET

See the code: https://github.com/upstash/examples/tree/master/using-google-cloud-functions

The Stack

Serverless compute: Google Cloud Functions (Node.js)
Serverless data store: Redis via Upstash
Deployment tool: gcloud

Prerequisites:

A GCP account for Google Cloud functions.
Install Google Cloud SDK.
An Upstash account for Serverless Redis.

Step 1: Init the Project

Create a folder, then run npm init inside the folder.

Step 2: Install a Redis Client

Our only dependency is redis client. Install go-redis via npm install ioredis

Step 3: Create a Redis Database

Create a Redis database from Upstash console. Select the GCP US-Central-1 as the region. Free tier should be enough. It is pretty straight forward but if you need help, check getting started guide. In the database details page, click the Connect button. You will need the endpoint and password in the next step.

Step 4: The function Code

Create index.js as below:

var Redis = require("ioredis");

if (typeof client === 'undefined') {
    var client = new Redis("REPLACE_YOUR_UPSTASH_REDIS_URL");
}

exports.helloGET = async(req, res) => {
    let count = await client.incr("counter");
    res.send('Page view:' + count);
};

Replace the "REPLACE_YOUR_UPSTASH_REDIS_URL" with your database's ioredis url.

The code simply increments a counter in Redis database and returns its value in json format.

Step 5: Deployment

Now we are ready to deploy our API. Deploy via:

gcloud functions deploy helloGET \
--runtime nodejs14 --trigger-http --allow-unauthenticated

You will see the URL of your Cloud Function. Click to the URL to check if it is working properly.

httpsTrigger:
securityLevel: SECURE_OPTIONAL
url: https://us-central1-functions-317005.cloudfunctions.net/helloGET

In case of an issue, you can check the logs of your Cloud Function in the GCP console as below.

Deploy a Serverless API with AWS CDK and AWS Lambda

Noah — Fri, 21 May 2021 22:36:37 +0000

In this tutorial, we will implement a Serverless API using AWS Lambda and we will deploy it using AWS CDK. We will use Typescript as the CDK language. It will be a page view counter where we will keep the state in Redis.

Check the github repo for the source code.

What is AWS CDK?

AWS CDK is an interesting project which allows you to provision and deploy AWS infrastructure with code. Currently TypeScript, JavaScript, Python, Java, C#/.Net are supported. You can compare AWS CDK with following technologies:

AWS CloudFormation
AWS SAM
Serverless Framework

The above projects allows you to set up the infrastructure with configuration files (yaml, json) while with AWS CDK, you set up the resources with code. For more information about CDK see the related AWS Docs.

Project Setup

Install cdk with: npm install -g aws-cdk

Create a directory for your project. Inside the directory init cdk:

mkdir api-with-cdk

cd api-with-cdk

cdk init --language typescript

Counter Function Code

Create a directory for your API function

mkdir api

Inside the API folder, init and npm project and install ioredis.

cd api
npm init
npm install ioredis

In the api folder, create a file: counter.js

var Redis = require("ioredis");
    if (typeof client === 'undefined') {
        var client = new Redis(process.env.REDIS_URL);
    }

exports.main = async function (event, context) {
    try {
        const count = await client.incr('counter')
        return {
        statusCode: 200,
        headers: {},
        body: "View count:" + count
        };
    } catch (error) {
        var body = error.stack || JSON.stringify(error, null, 2);
        return {
        statusCode: 400,
        headers: {},
        body: JSON.stringify(body)
    }
  }
}

Counter Service

Go back to the top directory, install lambda and api-gateway libraries:

cd ..
npm install @aws-cdk/aws-apigateway @aws-cdk/aws-lambda

Inside the lib directory, create counter_service.ts:

import * as core from "@aws-cdk/core";
import * as apigateway from "@aws-cdk/aws-apigateway";
import * as lambda from "@aws-cdk/aws-lambda";

export class CounterService extends core.Construct {
constructor(scope: core.Construct, id: string) {
super(scope, id);

       const handler = new lambda.Function(this, "AppHandler", {
           runtime: lambda.Runtime.NODEJS_10_X,
           code: lambda.Code.fromAsset("api"),
           handler: "counter.main",
           environment: {
               REDIS_URL: "REPLACE_HERE"
           }
       });

       const api = new apigateway.RestApi(this, "counter-api", {
           restApiName: "Serverless Counter API",
           description: "This is a basic API."
       });

       const apiIntegration = new apigateway.LambdaIntegration(handler, {
           requestTemplates: { "application/json": '{ "statusCode": "200" }' }
       });

       api.root.addMethod("GET", apiIntegration);
}
}

You need to replace REPLACE_HERE with a proper Redis URL (ioredis format). You can create a Serverless Redis database in the Upstash for free. Copy the ioredis URL from Upstash console.

Update the Stack

Update lib/api-with-cdk-stack.ts:

import * as cdk from '@aws-cdk/core';
import * as counter_service from '../lib/counter_service';

export class ApiWithCdkStack extends cdk.Stack {
    constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
        super(scope, id, props);
        new counter_service.CounterService(this, 'CounterApi');
    }
}

Deploy

In the top folder:

cdk synth
cdk bootstrap
cdk deploy

Now you should see the command outputs the endpoint url. Click to the url, you should see the page counter.

https://h9zf2bdye0.execute-api.eu-west-1.amazonaws.com/prod/

Success 🎉

Speed up your Next.js application with Redis

Noah — Tue, 18 May 2021 00:43:38 +0000

Next.js is a very successful web framework which brings together server side rendering and static site generation. SSG speeds up your web site thanks to CDN caching meanwhile SSR helps you with SEO and dynamic data.

Server side rendering is a great feature which helps you to write full stack applications. But if you are not careful, the performance of your Next.js website can be affected easily. In this blog post, I will explain how to leverage Redis to speed up your Next.js API calls. Before that I will briefly mention a simpler way to improve your performance.

Use SWR on your API calls

SWR is a very smart data fetching library. It uses the HTTP cache invalidation strategy (stale-while-revalidate) described by HTTP RFC 5861. When you call an API with SWR, it instantly returns the cached data but asynchronously it fetches the current data and updates your UI. You can also set refreshInterval depending on your tolerance to staleness.

const { data: user } = useSWR('/api/user', { refreshInterval: 2000 })

In the above code, user API will be refreshed every 2 seconds.

Caching with Redis

SWR is very simple and effective. But there are cases you will need a server side caching:

Client side caching improves the performance for the clients. But if the number of clients is high, you can experience high load on the server side resources which will eventually affect the client side performance too.
If you are consuming an external API with a quota, you will want to control the API usage on the server side. Otherwise, too many clients will consume the API quickly.
If you have resources calculated, fetched or processed at the server side using dynamic inputs, client side caching will not be very useful.

Example Project: Covid Tracker

In this project, we will use Javier Aviles’ Covid API and find the top 10 countries with the most number of cases. Check the website and the source code.

We will use Redis to cache the responses from Covid API so:

The response will be much faster. If you check the website, you will see that calling the Covid API is hundreds of milliseconds while fetching from Redis is 1-2 milliseconds.
We will not overwhelm the Covid API with too many requests.

API Code

The code first checks if we have the API result cached in the Redis. If not, we will get the all country list from the Covid API and sort them by current day’s number of cases and save the top 10 to Redis. While saving to Redis, we set the "EX" 60 parameter which means that Redis will evict the entry in 60 seconds.

import Redis from 'ioredis'

let redis = new Redis(process.env.REDIS_URL)

export default async (req, res) => {
   let start = Date.now();
   let cache = await redis.get("cache")
   cache = JSON.parse(cache)
   let result = {}
   if (cache) {
       console.log("loading from cache")
       result.data = cache
       result.type = "redis"
       result.latency = Date.now() - start;
       return res.status(200).json(result)
   } else {
       console.log("loading from api")
       start = Date.now();
       return fetch('https://coronavirus-19-api.herokuapp.com/countries')
           .then(r => r.json())
           .then(data => {
               data.sort(function (a, b) {
                   return b.todayCases - a.todayCases;
               });
               result.data = data.splice(1, 11)
               result.type = "api"
               result.latency = Date.now() - start;
               redis.set("cache", JSON.stringify(result.data), "EX", 60)
               return res.status(200).json(result)
           })
   }
}

UI Code

The UI is a simple React code. We fetch the data from API using SWR.

export default function Home() {
   function refresh(e) {
       e.preventDefault();
       window.location.reload();
   }
   const {data, error} = useSWR("api/data", fetcher)
   if (error) return "An error has occurred.";
   if (!data) return "Loading...";
   return (
       <div className={styles.container}>
           <Head>
               <title>Covid Tracker</title>
               <meta name="description" content="Generated by create next app"/>
               <link rel="icon" href="/favicon.ico"/>
           </Head>

           <main className={styles.main}>
               <h1 className={styles.title}>
                   Covid Tracker
               </h1>

               <p className={styles.description}>
                   Top 10 countries with the most cases today
               </p>

               <div className={styles.grid}>
                   <div className={styles.card} onClick={refresh}>
                       <table className={styles.table}>
                           <thead>
                           <tr>
                               <th>Country</th>
                               <th>Today Cases</th>
                               <th>Today Deaths</th>
                           </tr>
                           </thead>
                           <tbody>
                           {data.data.map((item) =>
                               <tr>
                                   <td>{item.country}</td>
                                   <td>{item.todayCases}</td>
                                   <td>{item.todayDeaths}</td>
                               </tr>)}
                           </tbody>
                       </table>
                       <br/>
                       <em>Loaded from {data.type} in <b>{data.latency}</b> milliseconds. Click to reload.</em>
                   </div>
               </div>
           </main>

           <footer className={styles.footer}>
               This is a sample project for the blogpost &nbsp;
               <a
                   href="https://blog.upstash.com/nextjs-caching-with-redis"
                   target="_blank"
                   rel="noopener noreferrer"
               >
                   Speed up your Next.js application using Serverless Redis for caching.
               </a>
           </footer>
       </div>
   )
}

External Links

https://swr.vercel.app/docs/with-nextjs

https://brianlovin.com/writing/caching-api-routes-with-next-js

https://coronavirus-19-api.herokuapp.com/countries

https://github.com/javieraviles/covidAPI

Build a Serverless Histogram API with Redis

Noah — Wed, 28 Apr 2021 19:30:01 +0000

While developing the latency benchmark for the serverless databases (DynamoDB, FaunaDB, Upstash), I wished there was an API where I will record the latency numbers and get the histogram back. In this tutorial, I will build such an API where you can record your latency values from any application. It will be a REST API with following methods:

record: Records numeric values into the histogram.
get: Returns the histogram object.

Motivation

I will show how easy to develop a generic API using AWS Lambda and Serverless Redis.

See code.

`1` Create a Redis (Upstash) Database

Create a database as getting started

`2` Serverless Project Setup

If you do not have it already install serverless framework via:
npm install -g serverless

In any folder run serverless as below:

>> serverless

Serverless: No project detected. Do you want to create a new one? Yes
Serverless: What do you want to make? AWS Node.js
Serverless: What do you want to call this project? histogram-api

Project successfully created in 'histogram-api' folder.

You can monitor, troubleshoot, and test your new service with a free Serverless account.

Serverless: Would you like to enable this? No
You can run the “serverless” command again if you change your mind later.

Inside the project folder create a node project with the command:

npm init

Then install the redis client and histogram library with:

npm install ioredis

npm install hdr-histogram-js

Update the serverless.yml as below. Copy your Redis URL from console and replace below:

service: histogram-api
frameworkVersion: '2'

provider:
  name: aws
  runtime: nodejs12.x
  lambdaHashingVersion: 20201221
  environment:
    REDIS_URL: REPLACE_YOUR_URL_HERE

functions:
  record:
    handler: handler.record
    events:
      - httpApi:
          path: /record
          method: post
          cors: true
  get:
    handler: handler.get
    events:
      - httpApi:
          path: /get
          method: get
          cors: true

`3` Code

Edit handler.js as below.

const hdr = require("hdr-histogram-js");
const Redis = require("ioredis");
if (typeof client === 'undefined') {
    var client = new Redis(fixUrl(process.env.REDIS_URL));
}
const headers = {
    'Access-Control-Allow-Origin': '*',
    'Access-Control-Allow-Credentials': true,
};
const SIZE = 10000;

module.exports.get = async (event) => {
    if (!event.queryStringParameters || !event.queryStringParameters.name) {
        return {
            statusCode: 400,
            headers: headers,
            body: JSON.stringify(
                {
                    message: 'Invalid parameters. Name is needed.',
                }
            ),
        };
    }
    const name = event.queryStringParameters.name;
    const data = await client.lrange(name, 0, SIZE);
    const histogram = hdr.build();
    data.forEach(item => {
        histogram.recordValue(item);
    })

    return {
        statusCode: 200,
        body: JSON.stringify(
            {
                histogram: histogram
            }
        ),
    };
};

module.exports.record = async (event) => {
    let body = JSON.parse(event.body)
    if (!body || !body.name || !body.values) {
        return {
            statusCode: 400,
            headers: headers,
            body: JSON.stringify(
                {
                    message: 'Invalid parameters. Name and values are needed.',
                }
            ),
        };
    }
    const name = body.name;
    const values = body.values;
    await client.lpush(name, values)
    return {
        statusCode: 200,
        body: JSON.stringify(
            {
                message: 'Success',
                name: name
            }
        ),
    };
};


function fixUrl(url) {
    if (!url) {
        return ''
    }
    if (url.startsWith('redis://') && !url.startsWith('redis://:')) {
        return url.replace('redis://', 'redis://:')
    }
    if (url.startsWith('rediss://') && !url.startsWith('rediss://:')) {
        return url.replace('rediss://', 'rediss://:')
    }
    return url
}

We have two serverless functions above. get takes name as parameter and loads a list from Redis. Then builds a histogram using the values in the list.

The record function takes name and values as parameters. It adds the values to the Redis List with name name.

The get function calculates the histogram over the latest 10000 latency records. Update the SIZE parameter to change this number.

The fixUrl is a helper method which corrects the Redis url format.

`4` Deploy and Try the API

Deploy your functions with:

serverless deploy

The command will deploy two functions and output two endpoints. Try the endpoints with setting parameters as below:

Record latency numbers to perf-test-1:

curl --header "Content-Type: application/json" -d "{\"name\":\"perf-test-1\", \"values\": [90,80,34,97,93,45,49,57,99,12]}" https://v7xx4aa2ib.execute-api.us-east-1.amazonaws.com/record

Get the histogram for perf-test-1:

curl https://v7xx4aa2ib.execute-api.us-east-1.amazonaws.com/get?name=perf-test-1

Batching

It can be costly to call a remote function each time for latency calculation. In your application, you should keep an array or queue as a buffer for the latency numbers, then submit them in batches to the API when the array reaches the batch size. Something like below:

let records = [];
let batchSize = 1000;
function recordLatency(value) {
    records.push(value);
   if(records.length >= batchSize) {
       // the below submits the records to the API then empties the records array.
       submitToAPI(records);
   } 
}

Backendless Coin Price List with GraphQL API, Serverless Redis and Next.JS

Noah — Tue, 20 Apr 2021 18:16:59 +0000

In this tutorial, we will develop a simple coin price list using GraphQL API of Upstash. You can call the application backendless because we will access the database directly from the client (javascript).
See the code.

Motivation

We want to give a use case where you can use the GraphQL API without any backend code. The use case is publicly available read only data for web applications where you need low latency. The data is updated frequently by another backend application, you want your users to see the last updated data. Examples: Leaderboards, news list, blog list, product list, top N items in the homepages.

`1` Project Setup:

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

Install Apollo GraphQL client: npm i @apollo/client

`2` Database Setup

If you do not have one, create a database following this guide.
Connect your database via Redis CLI and run:

rpush coins '{ "name" : "Bitcoin", "price": 56819, "image": "https://s2.coinmarketcap.com/static/img/coins/64x64/1.png"}' '{ "name" : "Ethereum", "price": 2130, "image": "https://s2.coinmarketcap.com/static/img/coins/64x64/1027.png"}' '{ "name" : "Cardano", "price": 1.2, "image": "https://s2.coinmarketcap.com/static/img/coins/64x64/2010.png"}' '{ "name" : "Polkadot", "price": 35.96, "image": "https://s2.coinmarketcap.com/static/img/coins/64x64/6636.png"}' '{ "name" : "Stellar", "price": 0.506, "image": "https://s2.coinmarketcap.com/static/img/coins/64x64/512.png"}'

`3` Code

In the Upstash console, copy the read only access key in your API configuration page (GraphQL Explorer > Configure API). In the _app.js create the Apollo client and replace the your access key as below:

:::caution
You need to use Read Only Access Key, because the key will be accessible publicly.
:::

import '../styles/globals.css'
import {
  ApolloClient,
  ApolloProvider, createHttpLink, InMemoryCache,
} from "@apollo/client";

const link = createHttpLink({
  uri: "https://graphql-us-east-1.upstash.io/",
  headers: {
    Authorization: "Bearer YOUR_ACCESS_TOKEN",
  },
});
const client = new ApolloClient({
  uri: "https://graphql-us-east-1.upstash.io/",
  cache: new InMemoryCache(),
  link,
});

function MyApp({ Component, pageProps }) {
  return <ApolloProvider client={client}><Component {...pageProps} /> </ApolloProvider>
}

export default MyApp

Edit index.js as below:

import Head from 'next/head'
import styles from '../styles/Home.module.css'
import {
    gql, useQuery,
} from "@apollo/client";
import React from "react";


const GET_COIN_LIST = gql`
    query {
        redisLRange(key : "coins", start: 0, stop: 6)
    }
`;

export default function Home() {
    let coins = []
    const {loading, error, data} = useQuery(GET_COIN_LIST);

    if (!loading && !error) {
        for(let x of data.redisLRange) {
            let dd = JSON.parse(x);
            coins.push(dd)
        }
    }

    return (
        <div className={styles.container}>
            <Head>
                <title>Create Next App</title>
                <link rel="icon" href="/favicon.ico"/>
            </Head>

            <main className={styles.main}>
                <h3 className={styles.title}>
                    Coin Price List
                </h3>

                <div className={styles.grid}>
                    <table className={styles.coins}>
                        <tbody>
                        {!loading ? (
                            coins.map((item, ind) => (
                                <tr key={ind}>
                                    <td>
                                        <img src={item.image}
                                             width="25"/>
                                    </td>
                                    <td>
                                        {item.name}
                                    </td>
                                    <td className={styles.price}>
                                        ${item.price}
                                    </td>
                                </tr>
                            ))
                        ) : (
                            <tr>
                                <td>
                                    <img src="/loader.gif"/>
                                </td>
                            </tr>
                        )}
                        </tbody>
                    </table>

                </div>
            </main>

            <footer className={styles.footer}>
                <p className={styles.description}>
                    <a href="https://docs.upstash.com"> Click for the tutorial </a>
                </p>

            </footer>
        </div>
    )
}

`4` Run

Run your application locally:
npm run dev

`5` Live!

Go to http://localhost:3000/ 🎉

Latency Comparison Among Serverless Databases: DynamoDB vs FaunaDB vs Redis

Noah — Sat, 17 Apr 2021 05:16:57 +0000

In this article, I will compare the latencies of three serverless databases DynamoDB, FaunaDB, Upstash (Redis) for a common web use case.

I created a sample news website and I am recording database related latency with each request to the website. Check the website and the source code.

I have inserted 7001 NY Times articles into each database. The articles are collected from New York Times Archive API(all articles of January 2021). I randomly scored each article. At each page request, I query top 10 articles under the World section from each database.

I use serverless functions (AWS Lambda) to load the articles from each database. Response time of fetching 10 articles is being recorded as latency inside the lambda function. Note that the recorded latency is only between the lambda function and the database. It is not the latency between your browser and the server.

After each read request, I update the scores randomly to simulate dynamic data. But I exclude this part from the latency calculation.

First we will examine the application, then we will look at the results:

AWS Lambda Setup

Region: US-West-1

Memory: 1024Mb

Runtime: nodejs14.x

DynamoDB Setup

I created a DynamoDB table in US-West-1 with the read and write capacity 50 (the default value was 5).

My index is GSI with partition key section (String) and sort key view_count (Number).

FaunaDB Setup

FaunaDB is a globally replicated database, afaik there is no way to select a region. I used FQL, assuming GraphQL API may have some overhead.

I created an index with terms section and values view_count, ref as below. I made it non-serialized hoping to improve the performance.

CreateIndex({

name: "section_by_view_count",

unique: false,

serialized: false,

source: Collection("news"),

terms: [

{ field: ["data", "section"] }

],

values: [

{ field: ["data", "view_count"], reverse: true },

{ field: ["ref"] }

]

})

Redis Setup

I created a Standard type database in the US-West-1 region in Upstash. I used a Sorted Set per each news category. So all World news articles will be in the Sorted Set with key World.

Initialize Databases

I downloaded the 7001 news articles as a JSON file from NYTimes API site, then created a NodeJS script per each database which reads the JSON and inserts the news record to the database. See the files: initDynamo.js, initFauna.js, initRedis.js

Query DynamoDB

I used AWS SDK to connect to DynamoDB. To minimize the latency, I am keeping the DynamoDB connection alive. I have used the perf_hooks library to measure the response time. I record the current time just before querying the DynamoDB for the top 10 articles. I calculated the latency as soon as I got the response from DynamoDB. Then I randomly score the articles and insert the latency number to a Redis sorted set but these parts are outside the latency calculation part. See the code below:

var AWS = require("aws-sdk");
AWS.config.update({
   region: "us-west-1"
});
const https = require('https');
const agent = new https.Agent({
   keepAlive: true,
   maxSockets: Infinity
});

AWS.config.update({
   httpOptions: {
       agent
   }
});

const Redis = require("ioredis");
const { performance } = require("perf_hooks");
const tableName = "news";
var params = {
   TableName: tableName,
   IndexName: "section-view_count-index",
   KeyConditionExpression: "#sect = :section",
   ExpressionAttributeNames: {
       "#sect": "section"
   },
   ExpressionAttributeValues: {
       ":section": process.env.SECTION
   },
   Limit: 10,
   ScanIndexForward: false,
};
const docClient = new AWS.DynamoDB.DocumentClient();

module.exports.load =  (event, context, callback) => {
   let start = performance.now();
   docClient.query(params, (err, result) => {
       if (err) {
           console.error("Unable to scan the table. Error JSON:", JSON.stringify(err, null, 2));
       } else {
           // response is ready so we can set the latency
           let latency = performance.now() - start;
           let response = {
               statusCode: 200,
               headers: {
                   'Access-Control-Allow-Origin': '*',
                   'Access-Control-Allow-Credentials': true,
               },
               body: JSON.stringify(
                   {
                       latency: latency,
                       data: result,
                   }
               )
           };
           // we are setting random score to top-10 items to simulate real time dynamic data
           result.Items.forEach(item =>{
               let view_count = Math.floor(Math.random() * 1000);
               var params2 = {
                   TableName:tableName,
                   Key:{
                       "id": item.id,
                   },
                   UpdateExpression: "set view_count = :r",
                   ExpressionAttributeValues:{
                       ":r":view_count
                   },
               };
               docClient.update(params2, function(err, data) {
                   if (err) {
                       console.error("Unable to update item. Error JSON:", JSON.stringify(err, null, 2));
                   }
               });
           } );
           // pushing the latency to the histogram
           const client = new Redis(process.env.LATENCY_REDIS_URL);
           client.lpush("histogram-dynamo", latency, (resp) => {
               client.quit();
               callback(null, response)
           })
       }
   });
};

Query FaunaDB

I used the faunadb library to connect and query FaunaDB. The remaining part is very similar to DynamoDB code. To minimize the latency, I am keeping the connection alive. I have used the perf_hooks library to measure the response time. I record the current time just before querying the FaunaDB for the top 10 articles. I calculated the latency as soon as I got the response from FaunaDB. Then I randomly score the articles and send the latency number to a Redis sorted set but these parts are outside the latency calculation part. See the code below:

const faunadb = require("faunadb");
const Redis = require("ioredis");
const { performance } = require("perf_hooks");
const q = faunadb.query
const client = new faunadb.Client({
   secret: process.env.FAUNA_SECRET,
   keepAlive: true
})
const section = process.env.SECTION;

module.exports.load = async (event) => {
   let start = performance.now();
   let ret = await client.query(
       // the below is Fauna API for "select from news where section = 'world' order by view_count limit 10"
       q.Map(q.Paginate(q.Match(q.Index('section_by_view_count'), section), {size: 10}), q.Lambda(["view_count", "X"], q.Get(q.Var("X"))))
   ).catch((err) => console.error('Error: %s', err))
   console.log(ret)
   // response is ready so we can set the latency
   let latency = performance.now() - start;
   const rclient = new Redis(process.env.LATENCY_REDIS_URL);
   await rclient.lpush("histogram-fauna", latency)
   await rclient.quit();

   let result = [];
   for (let i = 0; i < ret.data.length; i++) {
       result.push(ret.data[i].data)
   }

   // we are setting random scores to top-10 items asynchronously to simulate real time dynamic data
   ret.data.forEach((item) => {
       let view_count = Math.floor(Math.random() * 1000);
       client.query(
           q.Update(
               q.Ref(q.Collection('news'), item["ref"].id),
               {data: {view_count}},
           )
       ).catch((err) => console.error('Error: %s', err))
   })

   return {
       statusCode: 200,
       headers: {
           'Access-Control-Allow-Origin': '*',
           'Access-Control-Allow-Credentials': true,
       },
       body: JSON.stringify({
           latency: latency,
           data: {
               Items: result
           },
       })
   };
};

Query Redis

I used the ioredis library to connect and read from Redis in Upstash. I used the ZREVRANGE command to load data from Sorted Set. To minimize the latency, I reused the connection creating the Redis client outside the function. Similar to DynamoDB and FaunaDB, I am updating the scores and sending the latency number to another Redis DB for histogram calculation. See the code:

const Redis = require("ioredis");
const { performance } = require("perf_hooks");
const client = new Redis(process.env.REDIS_URL);
module.exports.load = async (event) => {
   let section = process.env.SECTION;
   let start = performance.now();
   let data = await client.zrevrange(section, 0, 9)
   let items = []
   for(let i = 0; i < data.length; i++) {
       items.push(JSON.parse(data[i]));
   }
   // response is ready so we can set the latency
   let latency = performance.now() - start;
   // we are setting random scores to top-10 items to simulate real time dynamic data
   for(let i = 0; i < data.length; i++) {
       let view_count = Math.floor(Math.random() * 1000);
       await client.zadd(section, view_count, data[i]);
   }
   // await client.quit();
   // pushing the latency to the histogram
   const client2 = new Redis(process.env.LATENCY_REDIS_URL);
   await client2.lpush("histogram-redis", latency)
   await client2.quit();
   return {
       statusCode: 200,
       headers: {
           'Access-Control-Allow-Origin': '*',
           'Access-Control-Allow-Credentials': true,
       },
       body: JSON.stringify( {
           latency: latency,
           data: {
               Items: items
           },
       })
   };
};

Histogram Calculation

I used hdr-histogram-js library to calculate the histogram. This is a js implementation of Gil Tene’s hdr-histogram library. See the code of the lambda function which receives the latency numbers and calculates the histogram.

const Redis = require("ioredis");
const hdr = require("hdr-histogram-js");

module.exports.load = async (event) => {
   const client = new Redis(process.env.LATENCY_REDIS_URL);
   let dataRedis = await client.lrange("histogram-redis", 0, 10000)
   let dataDynamo = await client.lrange("histogram-dynamo", 0, 10000)
   let dataFauna = await client.lrange("histogram-fauna", 0, 10000)
   const hredis = hdr.build();
   const hdynamo = hdr.build();
   const hfauna = hdr.build();
   dataRedis.forEach(item => {
       hredis.recordValue(item);
   })
   dataDynamo.forEach(item => {
       hdynamo.recordValue(item);
   })
   dataFauna.forEach(item => {
       hfauna.recordValue(item);
   })
   await client.quit();
   return {
       statusCode: 200,
       headers: {
           'Access-Control-Allow-Origin': '*',
           'Access-Control-Allow-Credentials': true,
       },
       body: JSON.stringify(
           {
               redis_min: hredis.minNonZeroValue,
               dynamo_min: hdynamo.minNonZeroValue,
               fauna_min: hfauna.minNonZeroValue,
               redis_mean: hredis.mean,
               dynamo_mean: hdynamo.mean,
               fauna_mean: hfauna.mean,
               redis_histogram: hredis,
               dynamo_histogram: hdynamo,
               fauna_histogram: hfauna,
           },
           null,
           2
       )
   };
};

The Results

Check the website for the latest results. You can also reach the latest histogram data. As long as the website is up and running, we will continue to collect the data and update the histogram. Results as of today (Apr, 12, 2021) shows that Upstash has the lowest latency (~50ms at 99th percentile) where FaunaDB has the highest latency (~900ms at 99th percentile). DynamoDB has (~200ms at 99th percentile)

Cold Start Effect

Although we measure the latency only for the query part, the cold start still has an effect. We optimize our code by reusing the client connections. We benefit from this as long as the Lambda container is hot and running. When AWS kills the container (cold start), the code re-creates the client, this is an overhead. In the application website, if you refresh the page; you will see the latency numbers decrease down to ~1ms for Upstash ; and ~7ms for DynamoDB.

Why is FaunaDB slow (in this benchmark)?

In FaunaDB’s status page, you will see latency numbers in hundreds. So I assume my configuration does not have big flaws. There can be two reasons behind this latency difference:

Strong consistency:
By default, both DynamoDB and Upstash provide eventual consistency for reads. FaunaDB provides Calvin based strong consistency and isolation. Strong consistency comes with performance overhead.

Global replication:
For both Upstash and DynamoDB, we are able to configure the database and the lambda function to be in the same AWS region. In FaunaDB, your data is replicated all around the world; so you do not have an option to pick your region. If your database clients are located around the world then this can be an advantage. But if you deploy your backend to a specific region, then this causes extra latency.

Redis gives sub millisecond latency. Why is it not the case here?

Creating a new Redis connection in the AWS Lambda function causes a notable overhead. As the application does not get a stable traffic, AWS Lambda re-creates the connection (cold start) most of the time. So the majority of the latency numbers in the histogram includes connection creation time. We run a job which fetches the website every 15 seconds; we saw that latency for Upstash has decreased to ~1ms. If you refresh the page, you will see a similar effect. See our blog post for how to optimize your serverless applications for low latency.

Coming Soon

Upstash will soon release the Premium product where the data is replicated to multiple availability zones. I will add it to see the effect of zone replication.

Let us know your feedback on Twitter or Discord.

Update

There was an active discussion on HackerNews about the my banchmark and performance of the Fauna. I applied the suggestions and restarted FaunaDB application. That’s why, the number of FaunaDB records in the histogram is less than others.

Challenge of Serverless: Database Connections

Noah — Fri, 09 Apr 2021 00:00:15 +0000

Designing a database for serverless, the biggest challenge in our mind was to build an infrastructure which supports per request pricing in a profitable way. We believe Upstash has achieved this. After we launched the product, we saw that there was another major challenge: Database connections!

As you know, Serverless Functions scale from 0 to infinity. This means when your functions get a lot of traffic, the cloud provider creates new containers (lambda functions) in parallel and scales out your backend. If you create a new database connection within the function then you can rapidly reach the connection limit of your database.

If you try to cache the connection outside the lambda functions then another problem occurs. When AWS freezes your Lambda function, it does not close the connection. So you may end up with many idle/zombie connections which can still threaten.

This problem is not specific to Redis, it applies to all databases which rely on TCP connections (Mysql, Postgre, MongoDB etc). You can see the serverless community is creating solutions like serverless-mysql. These are client-side solutions. As Upstash, we have the advantage of implementing and maintaining the server-side. So we decided to mitigate the problem by monitoring the connections and evicting the idle ones. So here the algorithm: As max-concurrent-connection, we have two limits for a database, soft-limit and hard-limit. When a database reaches the soft-limit we start to terminate the idle connections. We continue to accept new connection requests until the hard-limit is reached. If the database reaches the hard limit then we start rejecting new connections.

Connection Eviction Algorithm

if( current_connection_count < SOFT_LIMIT ) {
    ACCEPT_NEW_CONNECTIONS
}

if( current_connection_count > SOFT_LIMIT && current_connection_count < HARD_LIMIT ) {
    ACCEPT_NEW_CONNECTIONS
    START_EVICTING_IDLE_CONNECTIONS
}

if( current_connection_count > HARD_LIMIT ) {
    REJECT_NEW_CONNECTIONS
}

Note that the max concurrent connection limits listed in the Upstash docs are the soft limits.

Ephemeral Connections

After deploying the above algorithm, we have seen a great decrease in the number of rejected connections in all regions. But still if you want to be on the safe side, you can solve the problem on your side too. Instead of reusing the connection, you can open the Redis connection inside the function but also close them whenever you are done with Redis as below:

exports.handler = async (event) => {
    const client = new Redis(process.env.REDIS_URL);
    /*
    do stuff with redis
    */
    await client.quit();
    /*
    do other stuff
    */
    return {
        response: "response"
    };
};

The above code helps you to minimize the concurrent connection count. People ask about the latency overhead of new connections. Redis connections are known to be very lightweight.

Are Redis Connections Really Lightweight?

We have run a benchmark test to see how lightweight the Redis connections are. In this test we compare the latency numbers of two approaches:

1- EPHEMERAL CONNECTIONS: We do not reuse the connection. Instead we create a new connection for each command and close the connection immediately. We record the latency of client creation, ping() and client.quit() together. See the benchEphemeral() method in the code section below.

2- REUSE CONNECTIONS: We create a connection once and reuse the same connection for all commands. Here, we record the latency of ping() operation. See the benchReuse() method below.

async function benchReuse() {
    const client = new Redis(options);
    const hist = hdr.build();
    for (let index = 0; index < total; index++) {
        let start = performance.now() * 1000 // to μs
        client.ping()
        let end = performance.now() * 1000 // to μs
        hist.recordValue(end-start)
        await delay(10)
    }
    client.quit()
    console.log(hist.outputPercentileDistribution(1, 1));
}

async function benchEphemeral() {
    const hist = hdr.build();
    for (let index = 0; index < total; index++) {
        let start = performance.now() * 1000 // to μs
        const client = new Redis(options);
        client.ping()
        client.quit()
        let end = performance.now() * 1000 // to μs
        hist.recordValue(end-start)
        await delay(10)
    }
    console.log(hist.outputPercentileDistribution(1, 1));
}

See the repo, if you want to run the benchmark yourself.

We ran this benchmark code in AWS EU-WEST-1 region in two different setups. The first setup is SAME ZONE where the client and database are in the same availability zone. The second setup is INTER ZONE where the client runs in a different availability zone than the database. We have used Upstash Standard type as database servers.

We have seen the overhead of creating and closing a new connection (ephemeral approach) is only 75 microseconds (99th percentile). The overhead is very similar in the interzone setup (80 microseconds).

Then we decided to repeat the same test inside AWS Lambda functions. The results were different. Especially when we set the memory of Lambda function low (128Mb), we have seen bigger overhead of Redis connections. We have seen latency overhead up to 6-7 msec inside AWS Lambda functions.

Our conclusions about the Redis connections:

Redis connections are really lightweight on a system with a reasonable amount of CPU power. Even on t2.micro.
CPU power with the default AWS Lambda configuration is very poor, which significantly increases the cost of TCP connections with respect to total execution time of the Lambda function.
If you use Lambda functions with the default/minimum memory, then you would better cache the Redis connection outside the function.

Frozen Container => Zombie Connection

After realizing that connection can have notable overhead in some AWS Lambda setups, we decided to make further tests on reusing connection in AWS Lambda. We have detected another issue. This was an edge case no one has reported yet.

Here the timeline how it happens:

STEP1 - timer-0sec: We send a request, caching the connection outside the lambda function.

if (typeof client === 'undefined') {
    var client = new Redis("REDIS_URL");
}

module.exports.hello = async(event) => {
    let response = await client.get("foo");
    return {response : response + "-" + time}
};

STEP2 - timer-5sec: AWS freezes the container after a short time.

STEP3 - time-60sec: Upstash has a timeout of 60 seconds for idle connections. So it kills the connection, but can not get ACK from the client as it is frozen. So server connection goes into state FIN_WAIT_2.

STEP4 - time-90sec: Upstash server kills the connection completely, exiting from FIN_WAIT_2 state.

STEP5 - time-95sec: Client sends the same request and gets ETIMEDOUT exception. Because the client assumes the connection is open but it is not. 🤦🏻 🤦🏻 🤦🏻

STEP6 - time-396sec: 5 minutes after the last request, AWS kills the container completely.

STEP7 - time-400sec: Client sends the same request this time it works well because the container is created from scratch so the initialization step is not skipped. A new connection is created.

As you can see above, AWS thaws a container and reuses the connection. But the connection has been closed from the server side and it could not be communicated because the function was frozen. So there is a synchronization problem between Upstash evicting an idle connection and AWS handling an idle function. So if we kill an idle connection only after AWS terminates a function then there will not be any issue.

We changed Upstash connection timeout to 310 seconds assuming that AWS terminates an idle function in 300 seconds. After this change, the problem disappeared. The problem here is AWS is not transparent when they terminate idle functions. So we need to continue testing and try to detect if the issue happens again.

This issue is quite similar to the issue seen on serverless-mysql library. In the comments, it has been suggested to retry the request upon the ETIMEDOUT exception. But retrying has two drawbacks. First you may retry a write request which might have been processed and timed out with a real network problem. The second problem is the extra latency of the failed request.

GraphQL Helps Too

One way to get rid of connection issues to have connectionless API. Upstash supports GraphQL API in addition to Redis protocol. GraphQL is HTTP based so it does not have the connection limit issue. Check the docs for supported commands. Beware that GraphQL API has a latency overhead (about 5msec) over Redis protocol.

Conclusion

We customize Upstash databases for a smooth experience for serverless applications. Our new server-side algorithm removes inactive connections that AWS Lambda creates in abundance. You can minimize the number of connections by opening/closing your Redis client inside the Lambda function but this can have latency overhead if your function memory is less than 1GB.

As a conclusion, our recommendation for the serverless use cases:

If your use case is latency sensitive (e.g. 6msec is big for you) then reuse the Redis client.
If you experience a very high number of concurrent clients (over 1000) then reuse the Redis client.
If your use case is not latency sensitive then open/close the Redis client inside the function.
If your function has at least 1GB memory then open/close the Redis client inside the function.

Autocomplete API with Serverless Redis

Noah — Wed, 07 Apr 2021 21:09:45 +0000

This tutorial implements an autocomplete API powered by serverless Redis. See the demo and API endpoint and the source code.

We will keep country names in a Redis Sorted set. In Redis sorted set, elements with the same score are sorted lexicographically. So in our case, all country names will have the same score, 0. We keep all prefixes of country and use ZRANK to find the terms to suggest. See this blog post for the details of the algorithm.

Step 1: Project Setup

I will use Serverless framework for this tutorial. You can also use AWS SAM

If you do not have it already install serverless framework via: npm install -g serverless

In any folder run serverless as below:

>> serverless

Serverless: No project detected. Do you want to create a new one? Yes
Serverless: What do you want to make? AWS Node.js
Serverless: What do you want to call this project? test-upstash

Project successfully created in 'test-upstash' folder.

You can monitor, troubleshoot, and test your new service with a free Serverless account.

Serverless: Would you like to enable this? No
You can run the “serverless” command again if you change your mind later.

Inside the project folder create a node project with the command:

npm init

Then install the redis client with:

npm install ioredis

Step 2: API Implementation

Edit handler.js file as below.
See the blog post for the details of the algorithm.

var Redis = require("ioredis");
if (typeof client === 'undefined') {
    var client = new Redis(process.env.REDIS_URL);
}
const headers = {
    'Access-Control-Allow-Origin': '*',
    'Access-Control-Allow-Credentials': true,
};

module.exports.query = async (event, context, callback) => {
    if (!event.queryStringParameters || !event.queryStringParameters.term) {
        return {
            statusCode: 400,
            headers: headers,
            body: JSON.stringify(
                {
                    message: 'Invalid parameters. Term needed as query param.',
                }
            ),
        };
    }
    let term = event.queryStringParameters.term.toUpperCase();
    let res = []
    let rank = await client.zrank("terms", term)
    if (rank != null) {
        let temp = await client.zrange("terms", rank, rank + 100)
        for (const el of temp) {
            if (!el.startsWith(term)) {
                break;
            }
            if (el.endsWith("*")) {
                res.push(el.substring(0, el.length - 1));
            }
        }
    }
    return {
        statusCode: 200,
        headers: headers,
        body: JSON.stringify(
            {
                message: 'Query:' + event.queryStringParameters.term,
                result: res,
            }
        ),
    };
};

Step 3: Create database on Upstash

If you do not have one, create a database following this guide. Copy the Redis URL by clicking Redis Connect button inside database page. Copy the URL for ioredis as we use ioredis in our application. Create .env file and paste your Redis URL:

REDIS_URL=YOUR_REDIS_URL

The URL format of ioredis is different than other clients. There is a colon before the password.

Step 4: Initialize Database

We will initialize the database with country names. Copy and run initdb.js script from here.

We simply put the country names and all their prefixes to the sorted set.

require('dotenv').config()
var Redis = require("ioredis");

var countries = [
    {"name": "Afghanistan", "code": "AF"},
    {"name": "Åland Islands", "code": "AX"},
    {"name": "Albania", "code": "AL"},
    {"name": "Algeria", "code": "DZ"},
    ...
]
var client = new Redis(process.env.REDIS_URL);

for (const country of countries) {
    let term = country.name.toUpperCase();
    let terms = [];

    for (let i = 1; i < term.length; i++) {
        terms.push(0);
        terms.push(term.substring(0, i));
    }
    terms.push(0);
    terms.push(term + "*");
    (async () => {
        await client.zadd("terms", ...terms)
    })();
}

Step 5: Deploy Your Function

Edit serverless.yml as below and replace your Redis URL:

service: auto-complete-api
# add this if you set REDIS_URL in .env
useDotenv: true
frameworkVersion: '2'

provider:
  name: aws
  runtime: nodejs14.x
  lambdaHashingVersion: 20201221
  environment:
    REDIS_URL: REPLACE_YOUR_REDIS_URL

functions:
  query:
    handler: handler.query
    events:
      - httpApi:
          path: /query
          method: get
          cors: true

In the project folder run:

serverless deploy

Now you can run your function with:

serverless invoke -f query -d '{ "queryStringParameters": {"term":"ca"}}'

It should give the following output:

 {
  "statusCode": 200,
  "headers": {
    "Access-Control-Allow-Origin": "*",
    "Access-Control-Allow-Credentials": true
  },
  "body": "{\"message\":\"Query:ca\",\"result\":[\"CAMBODIA\",\"CAMEROON\",\"CANADA\",\"CAPE VERDE\",\"CAYMAN ISLANDS\"]}"
}

You can also test your function using AWS console. In your AWS Lambda section, click on your function. Scroll down to the code sections and click on the Test button on the top right. Use { "queryStringParameters": {"term":"ar"}} as your event data.

Step 6: Run Your Function Locally

In your project folder run:

 serverless invoke local -f query -d '{ "queryStringParameters": {"term":"ca"}}'

It should give the following output:

 {
  "statusCode": 200,
  "headers": {
    "Access-Control-Allow-Origin": "*",
    "Access-Control-Allow-Credentials": true
  },
  "body": "{\"message\":\"Query:ca\",\"result\":[\"CAMBODIA\",\"CAMEROON\",\"CANADA\",\"CAPE VERDE\",\"CAYMAN ISLANDS\"]}"
}

DEV Community: Noah

Rate Limiting at Edge with Cloudflare Workers and Serverless Redis

Redis Setup

Project Setup

The Code

Test and Deploy

Isn't it costly to make remote call for each request?

Why not Global Database?

IP as the identifier

Can I use self hosted Redis?

Integration to your existing website

Get Started with Google Cloud Functions

The Stack

Prerequisites:

Step 1: Init the Project

Step 2: Install a Redis Client

Step 3: Create a Redis Database

Step 4: The function Code

Step 5: Deployment

Deploy a Serverless API with AWS CDK and AWS Lambda

What is AWS CDK?

Project Setup

Counter Function Code

Counter Service

Update the Stack

Deploy

Speed up your Next.js application with Redis

Use SWR on your API calls

Caching with Redis

Example Project: Covid Tracker

API Code

UI Code

External Links

Build a Serverless Histogram API with Redis

Motivation

1 Create a Redis (Upstash) Database

2 Serverless Project Setup

3 Code

4 Deploy and Try the API

Batching

Backendless Coin Price List with GraphQL API, Serverless Redis and Next.JS

Motivation

1 Project Setup:

2 Database Setup

3 Code

4 Run

5 Live!

Latency Comparison Among Serverless Databases: DynamoDB vs FaunaDB vs Redis

AWS Lambda Setup

DynamoDB Setup

FaunaDB Setup

Redis Setup

Initialize Databases

Query DynamoDB

Query FaunaDB

Query Redis

Histogram Calculation

The Results

Cold Start Effect

Why is FaunaDB slow (in this benchmark)?

Redis gives sub millisecond latency. Why is it not the case here?

Coming Soon

Update

Challenge of Serverless: Database Connections

Connection Eviction Algorithm

Ephemeral Connections

Are Redis Connections Really Lightweight?

Frozen Container => Zombie Connection

GraphQL Helps Too

Conclusion

Autocomplete API with Serverless Redis

Step 1: Project Setup

Step 2: API Implementation

Step 3: Create database on Upstash

Step 4: Initialize Database

Step 5: Deploy Your Function

Step 6: Run Your Function Locally

`1` Create a Redis (Upstash) Database

`2` Serverless Project Setup

`3` Code

`4` Deploy and Try the API

`1` Project Setup:

`2` Database Setup

`3` Code

`4` Run

`5` Live!