https://github.com/stacktape/starter-socketio-websocket-api-redis
Stacktape starter project
https://github.com/stacktape/starter-socketio-websocket-api-redis
Last synced: 5 months ago
JSON representation
Stacktape starter project
- Host: GitHub
- URL: https://github.com/stacktape/starter-socketio-websocket-api-redis
- Owner: stacktape
- Created: 2023-08-16T12:52:34.000Z (over 2 years ago)
- Default Branch: master
- Last Pushed: 2025-01-20T01:56:38.000Z (about 1 year ago)
- Last Synced: 2025-01-20T02:41:45.768Z (about 1 year ago)
- Language: TypeScript
- Homepage: https://stacktape.com
- Size: 7.81 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Websocket API with Socket.io
> [!TIP]
> To deploy this project using **GUI-based flow**, navigate to [console](https://console.stacktape.com/create-new-project/git-project-using-console?name=my-stacktape-app&repositoryType=public&repositoryUrl=https://github.com/stacktape/starter-socketio-websocket-api-redis)
- simple Websocket API built using [Socket.io](https://socket.io/).
- The application runs in a
[container workload](https://docs.stacktape.com/compute-resources/multi-container-workloads/) and uses
[Upstash redis](https://docs.stacktape.com/resources/upstash-redis-databases/) to store the session data. The requests
are routed using [Application Load Balancer](https://docs.stacktape.com/resources/application-load-balancers/).
- This project includes a pre-configured [stacktape.yml configuration](stacktape.yml).
The configured infrastructure is described in the [stack description section](#stack-description)
## Pricing
- Fixed price resources:
- **Container workload** (~$0.012/hour, ~$9/month)
- There are also other resources that might incur costs (with pay-per-use pricing). If your load won't get high, these costs will be close to $0.
## Prerequisites
1. **AWS account**. If you don't have one, [create new account here](https://portal.aws.amazon.com/billing/signup).
2. **Stacktape account**. If you don't have one, [create new account here](https://console.stacktape.com/sign-up).
3. **Stacktape installed**.
Install on Windows (Powershell)
```bash
iwr https://installs.stacktape.com/windows.ps1 -useb | iex
```
Install on Linux
```bash
curl -L https://installs.stacktape.com/linux.sh | sh
```
Install on MacOS
```bash
curl -L https://installs.stacktape.com/macos.sh | sh
```
Install on MacOS ARM (Apple silicon)
```bash
curl -L https://installs.stacktape.com/macos-arm.sh | sh
```
4. **Upstash account**. If you don't have one, [create new account here](https://console.upstash.com/login).
## 1. Generate your project
To initialize the project, use
```bash
stacktape init --starterId socketio-websocket-api-redis
```
## 2. Before deploy
- Fill in your Upstash credentials in the `providerConfig.upstash` section of the stacktape.yml config file. You can get your API key in the [Upstash console](https://console.upstash.com/account/api).
## 3. Deploy your stack
The deployment will take ~5-15 minutes. Subsequent deploys will be significantly faster.
Deploy from local machine
The deployment from local machine will build and deploy the application from your system. This means you also need to have:
- Docker. To install Docker on your system, you can follow [this guide](https://docs.docker.com/get-docker/).- Node.js installed.
To perform the deployment, use the following command:
```bash
stacktape deploy --projectName <> --stage <> --region <>
```
`stage` is an arbitrary name of your environment (for example **staging**, **production** or **dev-john**)
`region` is the AWS region, where your stack will be deployed to. All the available regions are listed below.
`projectName` is the name of your project. You can create it in the console or interactively using CLI.
| Region name & Location | code |
| -------------------------- | -------------- |
| Europe (Ireland) | eu-west-1 |
| Europe (London) | eu-west-2 |
| Europe (Frankfurt) | eu-central-1 |
| Europe (Milan) | eu-south-1 |
| Europe (Paris) | eu-west-3 |
| Europe (Stockholm) | eu-north-1 |
| US East (Ohio) | us-east-2 |
| US East (N. Virginia) | us-east-1 |
| US West (N. California) | us-west-1 |
| US West (Oregon) | us-west-2 |
| Canada (Central) | ca-central-1 |
| Africa (Cape Town) | af-south-1 |
| Asia Pacific (Hong Kong) | ap-east-1 |
| Asia Pacific (Mumbai) | ap-south-1 |
| Asia Pacific (Osaka-Local) | ap-northeast-3 |
| Asia Pacific (Seoul) | ap-northeast-2 |
| Asia Pacific (Singapore) | ap-southeast-1 |
| Asia Pacific (Sydney) | ap-southeast-2 |
| Asia Pacific (Tokyo) | ap-northeast-1 |
| China (Beijing) | cn-north-1 |
| China (Ningxia) | cn-northwest-1 |
| Middle East (Bahrain) | me-south-1 |
| South America (São Paulo) | sa-east-1 |
Deploy using AWS CodeBuild pipeline
Deployment using AWS CodeBuild will build and deploy your application inside [AWS CodeBuild pipeline](https://aws.amazon.com/codebuild/). To perform the deployment, use
```bash
stacktape codebuild:deploy --stage <> --region <> --projectName <>
```
`stage` is an arbitrary name of your environment (for example **staging**, **production** or **dev-john**)
`region` is the AWS region, where your stack will be deployed to. All the available regions are listed below.
`projectName` is the name of your project. You can create it in the console or interactively using CLI.
| Region name & Location | code |
| -------------------------- | -------------- |
| Europe (Ireland) | eu-west-1 |
| Europe (London) | eu-west-2 |
| Europe (Frankfurt) | eu-central-1 |
| Europe (Milan) | eu-south-1 |
| Europe (Paris) | eu-west-3 |
| Europe (Stockholm) | eu-north-1 |
| US East (Ohio) | us-east-2 |
| US East (N. Virginia) | us-east-1 |
| US West (N. California) | us-west-1 |
| US West (Oregon) | us-west-2 |
| Canada (Central) | ca-central-1 |
| Africa (Cape Town) | af-south-1 |
| Asia Pacific (Hong Kong) | ap-east-1 |
| Asia Pacific (Mumbai) | ap-south-1 |
| Asia Pacific (Osaka-Local) | ap-northeast-3 |
| Asia Pacific (Seoul) | ap-northeast-2 |
| Asia Pacific (Singapore) | ap-southeast-1 |
| Asia Pacific (Sydney) | ap-southeast-2 |
| Asia Pacific (Tokyo) | ap-northeast-1 |
| China (Beijing) | cn-north-1 |
| China (Ningxia) | cn-northwest-1 |
| Middle East (Bahrain) | me-south-1 |
| South America (São Paulo) | sa-east-1 |
Deploy using Github actions CI/CD pipeline
1. If you don't have one, create a new repository at https://github.com/new
2. Create Github repository secrets: https://docs.stacktape.com/user-guides/ci-cd/#2-create-github-repository-secrets
3. Replace `<>` and `<>` in the .github/workflows/deploy.yml file.
4. `git init --initial-branch=main`
5. `git add .`
6. `git commit -m "setup stacktape project"`
7. `git remote add origin git@github.com:<>/<>.git`
8. `git push -u origin main`
9. To monitor the deployment progress, navigate to your github project and select the Actions tab
`stage` is an arbitrary name of your environment (for example **staging**, **production** or **dev-john**)
`region` is the AWS region, where your stack will be deployed to. All the available regions are listed below.
`projectName` is the name of your project. You can create it in the console or interactively using CLI.
| Region name & Location | code |
| -------------------------- | -------------- |
| Europe (Ireland) | eu-west-1 |
| Europe (London) | eu-west-2 |
| Europe (Frankfurt) | eu-central-1 |
| Europe (Milan) | eu-south-1 |
| Europe (Paris) | eu-west-3 |
| Europe (Stockholm) | eu-north-1 |
| US East (Ohio) | us-east-2 |
| US East (N. Virginia) | us-east-1 |
| US West (N. California) | us-west-1 |
| US West (Oregon) | us-west-2 |
| Canada (Central) | ca-central-1 |
| Africa (Cape Town) | af-south-1 |
| Asia Pacific (Hong Kong) | ap-east-1 |
| Asia Pacific (Mumbai) | ap-south-1 |
| Asia Pacific (Osaka-Local) | ap-northeast-3 |
| Asia Pacific (Seoul) | ap-northeast-2 |
| Asia Pacific (Singapore) | ap-southeast-1 |
| Asia Pacific (Sydney) | ap-southeast-2 |
| Asia Pacific (Tokyo) | ap-northeast-1 |
| China (Beijing) | cn-north-1 |
| China (Ningxia) | cn-northwest-1 |
| Middle East (Bahrain) | me-south-1 |
| South America (São Paulo) | sa-east-1 |
Deploy using Gitlab CI pipeline
1. If you don't have one, create a new repository at https://gitlab.com/projects/new
2. Create Gitlab repository secrets: https://docs.stacktape.com/user-guides/ci-cd/#2-create-gitlab-repository-secrets
3. replace `<>` and `<>` in the .gitlab-ci.yml file.
4. `git init --initial-branch=main`
5. `git add .`
6. `git commit -m "setup stacktape project"`
7. `git remote add origin git@gitlab.com:<>/<>.git`
8. `git push -u origin main`
9. `To monitor the deployment progress, navigate to your gitlab project and select CI/CD->jobs`
`stage` is an arbitrary name of your environment (for example **staging**, **production** or **dev-john**)
`region` is the AWS region, where your stack will be deployed to. All the available regions are listed below.
`projectName` is the name of your project. You can create it in the console or interactively using CLI.
| Region name & Location | code |
| -------------------------- | -------------- |
| Europe (Ireland) | eu-west-1 |
| Europe (London) | eu-west-2 |
| Europe (Frankfurt) | eu-central-1 |
| Europe (Milan) | eu-south-1 |
| Europe (Paris) | eu-west-3 |
| Europe (Stockholm) | eu-north-1 |
| US East (Ohio) | us-east-2 |
| US East (N. Virginia) | us-east-1 |
| US West (N. California) | us-west-1 |
| US West (Oregon) | us-west-2 |
| Canada (Central) | ca-central-1 |
| Africa (Cape Town) | af-south-1 |
| Asia Pacific (Hong Kong) | ap-east-1 |
| Asia Pacific (Mumbai) | ap-south-1 |
| Asia Pacific (Osaka-Local) | ap-northeast-3 |
| Asia Pacific (Seoul) | ap-northeast-2 |
| Asia Pacific (Singapore) | ap-southeast-1 |
| Asia Pacific (Sydney) | ap-southeast-2 |
| Asia Pacific (Tokyo) | ap-northeast-1 |
| China (Beijing) | cn-north-1 |
| China (Ningxia) | cn-northwest-1 |
| Middle East (Bahrain) | me-south-1 |
| South America (São Paulo) | sa-east-1 |
## 4. Test your application
After a successful deployment, some information about the stack will be printed to the terminal (**URLs** of the deployed services, links to **logs**, **metrics**, etc.).
- This project includes a pre-made test script that creates 100 websocket connections and emits a message to all of
them. To run it, use
```bash
stacktape script:run --scriptName broadcastTest --stage <> --region <>
```
## 5. Run the application in development mode
To run a container in the development mode (locally on your machine), you can use the
[dev command](https://docs.stacktape.com/cli/commands/dev/).
```bash
stacktape dev --region <> --stage <> --resourceName websocketServer --container socketio-server
```
Stacktape runs the container as closely to the deployed version as possible:
- Maps all of the container ports specified in the `events` section to the host machine.
- Injects parameters referenced in the environment variables by `$ResourceParam` and `$Secret` directives to the
running container.
- Injects credentials of the [assumed role](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) to
the container. This means that your locally running container will have the exact same IAM permissions as the deployed
version.
- Pretty-prints logs (stdout/stderr) produced by the container to the terminal.
The container is rebuilt and restarted, when you either:
- type `rs + enter` to the terminal
- use the `--watch` option and one of your source code files changes
## 6. Hotswap deploys
- Stacktape deployments use [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) under the hood. It
brings a lot of guarantees and convenience, but can be slow for certain use-cases.
- To speed up the deployment, you can use the `--hotSwap` flag which avoids using Cloudformation.
- Hotswap deployments work only for source code changes (for lambda function, containers and batch jobs) and for content uploads to buckets.
- If the update deployment is not hot-swappable, Stacktape will automatically fall back to using a Cloudformation deployment.
```bash
stacktape deploy --hotSwap --stage <> --region <> --projectName <>
```
## 7. Delete your stack
- If you no longer want to use your stack, you can delete it.
- Stacktape will automatically delete every infrastructure resource and deployment artifact associated with your stack.
```bash
stacktape delete --stage <> --region <>
```
# Stack description
Stacktape uses a simple `stacktape.yml` configuration file to describe infrastructure resources, packaging, deployment
pipeline and other aspects of your project.
You can deploy your project to multiple environments (stages) - for
example `production`, `staging` or `dev-john`. A stack is a running instance of an project. It consists of your application
code (if any) and the infrastructure resources required to run it.
The configuration for this project is described below.
## 1. Resources
- Every resource must have an arbitrary, alphanumeric name (A-z0-9).
- Stacktape resources consist of multiple underlying AWS or 3rd party resources.
### 1.1 Application load balancer
The application load balancer is responsible for maintaining and balancing websocket connections established between
clients and the containers.
If there are multiple containers(i.e your workload scales) load balancer distributes connections evenly among these
containers.
You can configure [more properties](https://docs.stacktape.com/resources/application-load-balancers/) on your load
balancer, including using custom domain names or enabling TLS. In this example, we are using the default setup.
```yml
resources:
mainLoadBalancer:
type: application-load-balancer
```
### 1.2 Upstash Redis database
The application uses Upstash serverless Redis database. It is used by
[Socket.IO adapter](https://socket.io/docs/v4/redis-adapter/) to synchronize when scaling to multiple Socket.IO
container instances.
In this example, we are configuring redis to use `tls`. You can also configure
[other properties](https://docs.stacktape.com/resources/upstash-redis-databases/) if desired.
```yml
redis:
type: upstash-redis
properties:
enableTls: true
```
### 1.3 Container workload
Socket.IO server runs inside a container workload with a single container. The workload is configured as follows:
- [Container](https://docs.stacktape.com/compute-resources/multi-container-workloads/#containers). This container
workload uses only a single container: `socketio-server`. The container is configured as follows:
- **Packaging** - determines how the Docker container image is built. The easiest and most optimized way to build the
image for a Typescript application is using `stacktape-image-buildpack`. We only need to configure `entryfilePath`.
Stacktape automatically transpiles and builds the application code with all of its dependencies, builds the Docker
image, and pushes it to a pre-created image repository on AWS. You can also use
[other types of packaging](https://docs.stacktape.com/configuration/packaging/#packaging-multi-container-workloads).
- **ConnectTo list** - we are adding redis database `redis` into `connectTo` list. By doing this, Stacktape will
automatically inject relevant environment variables into the compute resource's runtime (such as redis connection
url required for connecting to database)
- Events that reach the container. Load balancer event is configured to forward all incoming connections with path
`/`(used for load balancer healthcheck) or `/websockets*`(used for websocket connection) to the container's port
`3000`.
- [Resources](https://docs.stacktape.com/compute-resources/multi-container-workloads#resources). Resources are shared
between containers of container workload (in this case, we only have one container). The cheapest available resource
configuration is `0.25` of virtual CPU and `512` MB of RAM.
- [Scaling](https://docs.stacktape.com/compute-resources/multi-container-workloads#scaling). For the purposes of this
tutorial we are scaling the workload to two (parallel) instances, to showcase the "synchronization" through redis. I.e
that all websocket clients receive messages even if they are connected to different containers.
```yml
websocketServer:
type: multi-container-workload
properties:
resources:
cpu: 0.25
memory: 512
connectTo:
- redis
containers:
- name: socketio-server
packaging:
type: stacktape-image-buildpack
properties:
entryfilePath: src/server/index.ts
environment:
- name: PORT
value: 3000
events:
- type: application-load-balancer
properties:
containerPort: 3000
loadBalancerName: mainLoadBalancer
priority: 2
paths:
- "/"
- "/websockets*"
scaling:
minInstances: 2
maxInstances: 2
```
## 2. Test script
To simplify testing of the websocket app, the stacktape config also contains `broadcastTest`
[script](https://docs.stacktape.com/configuration/scripts/).
The purpose of this script is to create multiple websocket client connections (connections are balanced between the 2
socket.io containers):
- One of the clients sends a message.
- After rest of the websockets receive the message, they gracefully disconnect and script exits.
```yml
scripts:
broadcastTest:
executeScript: scripts/broadcast-test.ts
environment:
- name: LOAD_BALANCER_DOMAIN
value: $ResourceParam('loadBalancer', 'domain')
```
You can execute the test script after the deploy using
```bash
stp script:run --scriptName broadcastTet --stage <> --region <>
```