Full-Stack E-Commerce Website

A full-stack e-commerce application:

• client — React + Vite, built and served via nginx
• api — Node.js / Express
• mongo — MongoDB

A Helm chart (chart/) is included so the app can be deployed to any Kubernetes cluster, with or without ArgoCD.

Deploying on your own Kubernetes cluster

Prerequisites

• A running Kubernetes cluster and kubectl configured against it
• Helm 3
• A container registry (Docker Hub, GHCR, etc.) you can push images to
• (Optional) ArgoCD if you want GitOps-style auto-sync

1. Build and push the images

docker build -t <registry>/<repo>:client-latest ./client
docker push <registry>/<repo>:client-latest

docker build -t <registry>/<repo>:api-latest ./api
docker push <registry>/<repo>:api-latest

If you fork this repo and add DOCKERHUB_USERNAME / DOCKERHUB_TOKEN as GitHub Actions secrets, .github/workflows/cd.yml does this automatically on every push to main and bumps chart/values.yaml with the new image tags.

2. Create the API secret

The API reads its sensitive config from a Kubernetes Secret that the chart does not create for you (so credentials never end up in git). Create it once per cluster/namespace:

kubectl create secret generic api-secret \
  --from-literal=CONNECTION_STRING="mongodb://<release-name>-mongo:27017/<db-name>" \
  --from-literal=JWT_SECRET="<your-secret>" \
  --from-literal=STRIPE_SECRET_KEY="<your-stripe-key>"
  # optional, for real email delivery instead of the Ethereal test inbox:
  # --from-literal=SMTP_HOST=... --from-literal=SMTP_PORT=... \
  # --from-literal=SMTP_USER=... --from-literal=SMTP_PASS=... --from-literal=SMTP_FROM=...

<release-name>-mongo is the mongo Service the chart creates (e.g. tech-website-mongo if you install the release as tech-website).

3. Point the chart at your images

Edit chart/values.yaml (or pass --set) so client.image.* and api.image.* reference the registry/tags you pushed in step 1. api.existingSecret defaults to api-secret — change it if you named the secret differently.

4a. Install directly with Helm

helm install tech-website ./chart -n <namespace> --create-namespace

4b. Or deploy via ArgoCD (GitOps)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tech-website
  namespace: <argocd-namespace>
spec:
  project: default
  source:
    repoURL: <your fork's git URL>
    targetRevision: HEAD
    path: chart
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

With this in place, every push to main that changes the chart (including the automated tag bump from cd.yml) gets picked up and synced automatically.

5. Access the app

The chart's Services are ClusterIP, so forward them locally to try it out:

kubectl port-forward svc/tech-website-client 5173:80 -n <namespace>
kubectl port-forward svc/tech-website-api 3000:3000 -n <namespace>

Then open http://localhost:5173.

Note: the client currently hardcodes http://localhost:3000 as its API base URL, and the API's CORS whitelist only allows http://localhost:5173 / 5174 (api/app.js). Use those exact local ports when testing. For a real domain/ingress, both of these need to become environment-driven instead of hardcoded.

Local development (no Kubernetes)

Prerequisites

• Node.js and npm
• A local MongoDB instance (MongoDB Compass is handy for inspecting data)

Setup

# in both client/ and api/
npm install

# in api/ only
npm install dotenv

Create a .env file inside the api/ folder with the required configuration (ask a maintainer for the values).

Run the frontend

cd client
npm run dev

Run the backend

cd api
npm start

Git workflow

• Everyone works on their own branch before making changes, and pushes that branch when done.
• After pushing, open a pull request on GitHub. Once it's reviewed and checks pass, it gets merged into main.