Repository files navigation

Park website visitors in a virtual queue to reduce the demand on your origins during peak times.

For more details about other starter kits for Fastly Compute, see theFastly Documentation Hub

• Park visitors in a queue to limit the amount of active users on the website ⏳
• Ship queue analytics tolog endpoints 🔎
• Allow certain requests such as robots.txt, favicon to bypass the queue 🤖
• No client-side scripting required ⚡️

1. If you haven't already,sign up for Upstash and create a Redis service.
2. Create a new directory for your application and switch to it. Initialize a Compute project using this starter kit.

   npm create @fastly/compute@latest -- --language=javascript --starter-kit=queue

3. Create theupstash backend, changing the default hostname to the one provided in the Upstash console.
4. Create theprotected_content backend by accepting the default example host or setting your own.
5. Populate theconfig config store by following the prompts to configure Upstash and set a secret for signing cookies.
6. Runnpm run deploy to deploy your queue to your Fastly account.

This starter is fully-featured, and requires some dependencies on top of the@fastly/js-compute npm package. The following is a list of the dependencies used:

• @upstash/redis - a REST-based Redis client for storing queue state. You could easily swap this for your own storage backend.
• jws - a library for generating and validatingJSON Web Tokens.

The starter will require a backend to be configured to send requests to once visitors have made it through the queue. For demonstration, the default is a public S3 bucket with some assets and an index page.

The template uses webpack to bundleindex.js and its imports into a single JS file,bin/index.js, which is then wrapped into a.wasm file,bin/index.wasm using thejs-compute-runtime CLI tool bundled with the@fastly/js-compute npm package, and bundled into a.tar.gz file ready for deployment to Compute.

When a visitor makes a request for the first time, we generate a signed JWT containing theirposition in the queue, which is determined by fetching the current queuelength from Redis (INCR queue:length). This signed JWT is sent back to the visitor as an HTTP cookie.

On a regular basis, the current queuecursor is updated in Redis (INCR queue:cursor). This effectively lets a user in. To show a visitor how many others are in front of them in the queue, we subtract the current queuecursor from theposition saved in their JWT.

On subsequent requests, when a JWT is supplied, we verify the signature and extract theposition from the JWT. If the current queuecursor is higher than the user's signedposition, they will be allowed in.

Please see ourSECURITY.md for guidance on reporting security-related issues.