LOADING

0 %
avatar
Gregory Paul Rothstein
Software and Web Developer
IT Specialist
  • Bootstrap
  • MaterialUI
  • TailwindCSS
  • Angular
  • React
  • NextJS
  • Laravel
  • Wordpress
  • Git workflow knowledge
  • Design patterns knowledge
  • CI/CD Knowledge
  • Automation knowledge
  • Containers
  • Docker
  • Kubernetes
  • Python
  • Bash scripting
Download Resume

Card Game Engine

Deployment, Design, Software Project, Web Project

SITUATION:

My initial objective was to develop a robust card game engine, specifically focusing on the game of "Asshole (Presidents)." Once the core game logic and rules were established within this engine, the subsequent challenge was to integrate it into a comprehensive full-stack web application. This required designing a scalable API layer to expose game functionalities and building an intuitive frontend UI to allow users to interact with the game engine, all while ensuring seamless deployment on cloud infrastructure.

TASK:

My primary task evolved to seamlessly integrate the developed card game engine into a scalable full-stack architecture. This involved:

  1. Exposing the game engine's functionality via a Python Flask API, containerized for consistent deployment.
  2. Developing a responsive React frontend to manage game lobbies, display game state, and interact with the API.
  3. Establishing automated CI/CD pipelines for both the frontend (AWS Amplify Hosting) and the backend (AWS App Runner) from separate GitHub repositories.
  4. Meticulously troubleshooting complex deployment, environment variable injection, and cross-origin resource sharing (CORS) issues to ensure robust inter-service communication in the cloud environment.

ACTION:

  1. Application Development: Designed and built the interactive React frontend for game lobbies and user interfaces, and developed a Flask API backend to manage game rooms and API requests, containerizing it with Docker.
  2. Initial Cloud Deployment: Configured separate GitHub repositories for the frontend and backend, integrating them with AWS Amplify Hosting for automatic frontend deployments and AWS App Runner for automated backend deployments via Docker image builds.
  3. Dependency & Build Environment Resolution: Addressed initial npm create amplify setup issues, including ERESOLVE peer dependency conflicts, by employing --force and --legacy-peer-deps for robust package installation.
  4. Backend Deployment Troubleshooting: Systematically debugged App Runner build failures, identifying and correcting case-sensitivity issues in requirements.txt and ensuring the Dockerfile correctly configured gunicorn to serve the Flask application.
  5. Critical Frontend-Backend Communication Diagnosis: Faced persistent net::ERR_CONNECTION_REFUSED errors to http://127.0.0.1:5000 on the deployed frontend.
    • Utilized amplify.yml build logs and console.log statements in the React application to confirm REACT_APP_API_BASE_URL was not being correctly injected as an environment variable during the frontend build.
    • Identified a crucial hardcoded http://127.0.0.1:5000 URL in a specific frontend fetch call, which was bypassing the environment variable entirely.
    • Implemented echo "REACT_APP_TEST_VARIABLE=$REACT_APP_TEST_VARIABLE" >> .env directly within amplify.yml to force environment variable injection for the React build process.
    • Executed aggressive cache-clearing and forced redeployments on Amplify Hosting to ensure the updated code was served.
  6. CORS Policy Resolution: After establishing initial communication, encountered CORS policy blocked errors (No Access-Control-Allow-Origin header).
    • Analyzed browser console logs to pinpoint the exact Origin (https://play.gregsgames.social) and Resource (https://api.gregsgames.social/rooms) mismatch.
    • Corrected the Flask backend's frontend_origins list in api.py by meticulously removing incorrect backend URLs, eliminating trailing slashes from valid frontend origins, and ensuring http://localhost:3000, Amplify's default domain, and the custom frontend domain were precisely listed.
    • Triggered a new App Runner deployment for the backend to apply the CORS configuration changes.

RESULT:

Successfully deployed a fully operational full-stack web application, Greg's Games Social, with the "Asshole (Presidents)" card game engine at its core, featuring a React frontend communicating seamlessly with a Flask API backend. This project significantly enhanced my skills in designing game logic, cloud deployment (AWS Amplify, AWS App Runner), containerization (Docker), and advanced troubleshooting of inter-service communication issues, including environment variable injection and complex CORS configurations. I established robust and automated CI/CD pipelines, demonstrating the ability to take a project from initial game engine development to a production-ready, scalable solution.

Project Details

This project involved building and deploying a scalable, real-time-ready full-stack web application, featuring a React-based frontend and a containerized Python Flask API backend. The infrastructure leverages cutting-edge AWS services for modern cloud deployment and continuous delivery.

Overview & Goal

The primary goal was to create an interactive social gaming platform capable of managing game lobbies and serving real-time game state, with the flexibility of a Python backend for complex game logic. This required integrating separate frontend and backend codebases, hosted and managed by AWS cloud services.

Key Technologies Used

  • Frontend:
    • React.js: Modern JavaScript library for building user interfaces.
    • AWS Amplify Hosting: Fully managed platform for hosting modern web applications, providing CI/CD directly from GitHub.
  • Backend:
    • Python Flask: Lightweight web framework for building the API endpoints.
    • Gunicorn: WSGI HTTP Server for Python web applications, used for serving Flask in production.
    • Docker: Containerization platform for packaging the Flask application and its dependencies into a portable image.
  • Backend Deployment & Infrastructure:
    • AWS App Runner: Fully managed service for deploying containerized web applications directly from source code repositories, handling infrastructure, scaling, and load balancing automatically.
    • AWS IAM: Managed user permissions and roles for secure access.
    • AWS ECR (Elastic Container Registry): Used by App Runner to store the built Docker images.
    • AWS API Gateway: (Implicitly used by App Runner for custom domains, or by Amplify for traditional API Gateway/Lambda setups, though App Runner provides its own default domain).
  • Version Control & CI/CD:
    • GitHub: Separate repositories for frontend and backend codebases.
    • Automatic Deployments: Configured continuous integration/continuous deployment (CI/CD) pipelines via Amplify Hosting and App Runner for automatic redeployment on Git pushes.

Architectural Highlights

  • Separated Frontend & Backend: Maintained distinct codebases and deployment pipelines for the React UI and the Flask API, promoting modularity and independent scaling.
  • Containerized Backend: The Flask API was Dockerized, ensuring consistent environments from development to production and simplifying deployment onto container services like App Runner.
  • Managed Serverless-like Backend: Leveraging AWS App Runner eliminated the need for manual server provisioning, patching, and scaling, allowing focus on application logic.
  • Automated CI/CD: Integrated GitHub with Amplify Hosting and App Runner to enable automatic builds and deployments upon code commits to respective repositories, streamlining development workflow.

Key Challenges & Solutions

  1. Initial AWS Amplify CLI Setup (ERESOLVE errors): Encountered persistent ERESOLVE peer dependency conflicts during npm create amplify / ampx create due to react-scripts and typescript incompatibilities.
    • Solution: Employed npm install --force and npm install --legacy-peer-deps for initial project setup and dependency management, ensuring a stable local environment.
  2. AWS Amplify Gen 2 CLI (ampx) Complexities: Initially navigated the ampx CLI's "code-first" approach, encountering environment not found and IAM AccessDeniedException issues.
    • Solution: Pivoted to a more direct and console-driven deployment of the backend using AWS App Runner, simplifying the CI/CD pipeline while retaining container benefits. Configured IAM policies to grant necessary SSM permissions for bootstrapping.
  3. Frontend-Backend Communication & Environment Variables: The React frontend was unable to connect to the deployed Flask API, falling back to a local URL.
    • Root Cause 1: A hardcoded http://127.0.0.1:5000 URL in a specific fetch call in the React frontend, bypassing the environment variable mechanism.
    • Root Cause 2: The REACT_APP_API_BASE_URL environment variable was not being correctly injected into the React application's JavaScript bundle during the Amplify Hosting build process.
    • Solution 1: Modified the React frontend code to use the api.js utility and process.env.REACT_APP_API_BASE_URL for all API calls.
    • Solution 2: Ensured correct configuration in Amplify Console (REACT_APP_API_BASE_URL with no trailing slash) and, as a robust measure, explicitly used echo "REACT_APP_TEST_VARIABLE=$REACT_APP_TEST_VARIABLE" >> .env within the amplify.yml build commands to guarantee injection into the build environment. Forced repeated, clean redeployments.
  4. Dockerfile & App Runner Build Failures: Initial App Runner deployments failed due to "Failed to execute 'build' command."
    • Root Cause 1: Misspelling of requirements.txt (e.g., Requirements.txt) leading to case-sensitivity issues in the Linux-based App Runner build environment.
    • Root Cause 2: Confusion around App Runner's "Build command" vs. Dockerfile's CMD for dependency installation.
    • Solution 1: Corrected the filename to requirements.txt in the GitHub repository.
    • Solution 2: Ensured the Dockerfile's RUN pip install command was robust and correctly placed. Provided gunicorn ... as the explicit "Start command" in App Runner when required by the console, relying on Dockerfile's WORKDIR and COPY instructions.
  5. CORS Policy Blocking: After successful connection, the browser blocked requests due to a missing Access-Control-Allow-Origin header.
    • Root Cause: The frontend_origins list in the Flask backend's CORS configuration was incorrect, including backend URLs and potentially misformatted frontend URLs (e.g., with trailing slashes, or using os.environ.get('AMPLIFY_FRONTEND_URL') which resolves to None in App Runner).
    • Solution: Precisely configured the frontend_origins list in Flask to include only the exact URLs of the frontend deployments (Amplify Hosting URL, custom frontend domain, localhost), without trailing slashes.

Outcome & Impact

Successfully launched a fully functional, cloud-deployed full-stack web application. The project demonstrates strong proficiency in:

  • Modern web development (React, Flask, Docker).
  • Cloud deployment strategies (AWS Amplify Hosting, AWS App Runner).
  • Troubleshooting complex integration issues across frontend, backend, and cloud environments.
  • Implementing robust CI/CD pipelines from GitHub.

This project provided invaluable experience in building and maintaining a scalable web application in a professional cloud setting.

Ready to chat?

Let's chat!
Contact Me For Details
Previous project
All projects
© 2024 All Rights Reserved.
Email: me@gregorypaulrothstein.dev