Note: Architectures illustrated are for educational purposes ONLY. They do no necessarily follow best practices and are NOT suitable for production.

• AWS account with programmatic access
• GitHub account with the frontend and backend application source repositories cloned
• A GitHub personal access token that provides access to the cloned repositories.

The WebSocket chat application developed here is a simplistic one. It allows isolated one-to-one communication between multiple users using the WebSocket protocol.

Multiple AWS resources are required to deploy and run this application.

The core application architecture consists of a backend deployment, API endpoints, and a frontend web application. The backend deployment is accessible via the API endpoints from the frontend web application.

The frontend web application is a Next.js application, with its source code located in the GitHub repository: Simple Websocket Chat App- Frontend. It is deployed using AWS Amplify. The backend logic is implemented in Go and its source code can be found in the GitHub repository: Simple HTTP Chat Application. It is packaged as a containerized deployment and deployed using AWS ECS. The API endpoints are deployed using AWS API Gateway services respectively.

The green lines signify deployment flows, while blue lines indicate the path through which application execution follows.

The source files for the terraform infrastructure module are located in the ./terraform sub-directory.

The following variables can be set for the infrastructure module:

github_access_token (required): GitHub personal access token

The only terraform provider used in the infrastructure module is the official aws provider from HashiCorp.

• Create sidecar container in task (because Fargate is being used)
• Add IAM permissions for writing to X-Ray to task role

• HTTP endpoint for WebSocket API in API Gateway: Integration requests have to be set up to deliver the connectionId to the backend endpoint
• Callback URL for WebSocket API must be configured for the Go SDK using an EndpointResolver

• IAM Service Role must be created for AWS API GW to write to CW Logs. See https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html
• Default integration response must be configured for WebSocket API routes that use integration (non-proxy) HTTP backend (otherwise nothing is returned).
• throttling_burst_limit and throttling_rate_limit must be set if route_settings is configured. Otherwise, weird "429 throttling limit exceeded error" on API endpoint.
• aws_api_gateway_account resource is needed to configure API Gateway's cloudwatch_role_arn
• aws_apigatewayv2_stage.default_route_settings holds default settings for all routes (not settings for the default route as stated in the docs: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/apigatewayv2_stage#default_route_settings)
• aws_amplify_branch adds webhooks on the destination GitHub repository and does not destroy them on terraform destroy
• aws_apigatewayv2_stage.invoke_url gives the WebSocket URL to invoke the API. The HTTP URL needed for @connections API is not provided. Had to be formed by manipulating the returned wss:// URL.
• The /message route requires the @connections API URL which is only available after creating the stage--hence, the deployment. To enable an automated deployment after adding the /message route, aws_apigatewayv2_stage.dev.auto_deploy is set true.

• Use stageVariables in aws_apigatewayv2_integration

• https://docs.amplify.aws/guides/hosting/nextjs/q/platform/js/#dynamic-routes