Have you ever missed the best part of a movie because you were stuck in line at the food court? Or wandered around looking for an available washroom right before the picture started?
This exact problem inspired my latest full-stack project: Sync Sphere.
Sync Sphere is a simulated, real-time Venue Experience Optimization Dashboard designed for movie theaters and large venues. In this post, I want to walk through how I built it, the tech stack I used, and the major lessons I learned while deploying it to the cloud.
🛠️ The Tech Stack
To make the dashboard feel alive and responsive, I needed a modern tech stack. I chose:
Frontend: React, Vite, and Vanilla CSS (for a sleek, custom UI without the overhead of heavy component libraries).
Backend: Node.js, Express.
Deployment & Hosting: Google Cloud Platform (specifically, Google Cloud Run).
💡 Key Features of the Dashboard
Sync Sphere acts as a central hub for attendees. I focused on three main features:
Dynamic Movie Countdowns: Taking a static schedule and turning it into a live countdown clock so users know exactly exactly how many minutes they have left until trailers end and the main feature begins.
Live Wait-Time Polling: Using an Express API, the frontend polls the server every few seconds to fetch simulated line data for food stalls and washrooms.
Color-Coded Status UI: The UI dynamically shifts colors based on traffic. (e.g., Green for "Available Now", Yellow for "5 min wait", Red for "15 min wait").
🌩️ Deployment Challenges: The Google Cloud Run Experience
Building the app locally was a smooth experience, but transitioning from localhost to the cloud taught me some invaluable lessons about serverless deployments.
When trying to deploy the project using Google Cloud's Build packs (gcloud run deploy), the container would successfully build, but immediately crash upon routing traffic.
1. The Dynamic Port Issue
Locally, the Express server was hardcoded to listen on port 3000. However, in a serverless environment like Google Cloud Run, the port is assigned dynamically. To fix the crashes, I had to ensure the app respected the environment variables provided by GCP:
javascript
---
// Hardcoded - BAD for serverless
// const port = 3000;
// Dynamic - PERFECT for serverless
const port = process.env.PORT || 8080;
- ES Modules vs CommonJS Conflict Because I used Vite to scaffold the frontend, my package.json included "type": "module". This tells Node.js to use the new ES6 module syntax (import express from 'express').
However, my initial server file was written using older CommonJS syntax (const express = require('express')). The mismatch caused an immediate crash during the cloud build. Fixing this required rewriting the backend imports and creating a workaround for __dirname, which isn’t natively available in ES Modules:
javascript
---
import express from 'express';
import path from 'path';
import { fileURLToPath } from 'url';
const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);
🎯 Key Takeaways
The biggest lesson from this project? The jump from development to production is all about configuration.
Once I explicitly listed all my backend dependencies (express, cors) in package.json, aligned my module types, and configured my start scripts, Google Cloud Run handled the rest beautifully. The container fired up seamlessly.
Building Sync Sphere reinforced my understanding of full-stack data flow and took my cloud deployment skills to the next level.
Links
🚀 Live Demo: [(https://sync-sphere-xrnrwp2hva-uc.a.run.app/)]
💻 GitHub Repo: [(https://github.com/bhardwajvinayak/syns-sphere.git)]
If you have any questions about deploying Node/React apps to Google Cloud Run, feel free to drop them in the comments below!
Top comments (0)