Deployment on Vercel
Relevant source files
The following files were used as context for generating this wiki page:The Farm Siege application is deployed and hosted on the Vercel platform. Vercel manages the entire lifecycle of the application, from building the frontend assets to hosting the static site and running the backend serverless functions. This deployment strategy leverages Vercel's infrastructure to provide a scalable and performant experience for players.
The backend logic, specifically for managing high scores, is implemented as Vercel Edge Functions. These functions interact with an external Upstash Redis database to persist and retrieve score data. This architecture separates the frontend game client from the backend services, allowing for independent development and scaling.
Build Process
Vercel automatically triggers a build and deployment process upon code changes. The build process is defined by the build script in the project's package.json file.
Sources: package.json:10
"scripts": {
"dev": "vite",
"build": "vite build",
"lint": "eslint **/*.ts",
"format": "prettier --write ."
},
Sources: package.json:8-13
The vite build command uses Vite to bundle the TypeScript source code and assets into optimized static files for production. The Vite configuration in vite.config.js specifies that assets smaller than 150 KB should be inlined.
// vite.config.js
import { defineConfig } from 'vite';
export default defineConfig({
build: {
assetsInlineLimit: 150 * 1024
}
});
Sources: vite.config.js:1-7
Vercel Configuration
The vercel.json file provides specific configuration for the Vercel deployment. In this project, it is used to add a custom HTTP header to all responses.
{
"$schema": "https://openapi.vercel.sh/vercel.json",
"headers": [
{
"source": "/(.*)",
"headers": [
{
"key": "Feature-Policy",
"value": "autoplay 'self'"
}
]
}
]
}
Sources: vercel.json:1-12
This configuration adds the Feature-Policy header with the value autoplay 'self', which restricts the autoplay of media to the same origin. This is applied to all paths (/(.*)) served by the deployment.
Serverless Functions (API)
The backend API is built using Vercel Edge Functions located in the api/ directory. These functions handle high score submissions and retrieval. They are configured to run on Vercel's Edge Runtime for low-latency responses.
Sources: api/highscores.ts:2-4, api/submitScore.ts:3-5
Highscore System Architecture
The highscore system involves the game client, Vercel's Edge Functions, and an Upstash Redis database. The functions require UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN environment variables to authenticate with the Redis REST API.
The following diagram illustrates the overall architecture for handling high scores.
Sources: api/highscores.ts, api/submitScore.ts, README.md:6
GET /api/highscores
This endpoint retrieves the top 10 high scores from the Redis database.
- Path:
/api/highscores - Method:
GET - Runtime: Edge
The function sends a fetch request to the Upstash Redis REST API, executing the ZREVRANGE command to get the top 10 scores from the highscores sorted set. The results are then parsed and returned as a JSON array.
The sequence diagram below shows the interaction for a high score request.
Sources: api/highscores.ts:9-29
POST /api/submitScore
This endpoint handles the submission of a new score. It includes validation using zod and bot protection via Google reCAPTCHA.
- Path:
/api/submitScore - Method:
POST - Runtime: Edge
Request Body
The request body must conform to the following schema, which is validated using zod.
| Field | Type | Constraints | Description |
|---|---|---|---|
name | string | min(1), max(20) | The player's name. |
score | number | int, min(0) | The player's score. |
recaptcha | string | - | The reCAPTCHA v3 token from the client. |
Sources: api/submitScore.ts:28-33
Logic Flow
- The function first parses and validates the incoming JSON body against the
zodschema. - It then calls the
validateRecaptchahelper, which sends a request to Google'ssiteverifyendpoint to check the validity of the reCAPTCHA token. The submission is only accepted if the action is successful and the score is0.5or higher. - If validation passes, the function sends a
fetchrequest to the Upstash Redis REST API, executing aZADDcommand with theGToption. This command adds the new score only if it is greater than the member's current score (if the member already exists). - A success or failure message is returned to the client.
The following sequence diagram details the score submission process.
Sources: api/submitScore.ts:12-78
Frontend Hosting
Vercel serves the static frontend application, which is the output of the vite build process. The main entry point for the web application is index.html. This file loads the game's main script, stylesheets, and third-party scripts for analytics.
<!-- index.html -->
<!doctype html>
<html lang="en">
<head>
...
<script type="module" src="/src/main.ts" defer></script>
<link rel="stylesheet" href="/src/styles.css" />
<!-- Analytics -->
<script defer data-domain="farmsiege.wsky.dev" src="https://insights.wsky.dev/js/script.outbound-links.js"></script>
</head>
<body>
<div class="container">
<canvas id="canvas" style="width: 100%; height: auto"></canvas>
...
</div>
</body>
</html>
Sources: index.html:1-35
The game itself runs in a <canvas> element, and the entire user interface and game logic are managed by the JavaScript loaded via /src/main.ts.
Summary
The deployment on Vercel provides a robust and efficient solution for hosting the Farm Siege game. It combines static site hosting for the frontend, a serverless Edge Function-based API for the backend, and a straightforward build process managed by Vite. This setup allows for seamless continuous deployment and leverages modern cloud infrastructure to deliver a fast and reliable gaming experience.