Milestone: Your App Is Online

Before You Study (5 mins)

Lesson focus: Today is a milestone — not a new technology, but a verification ritual. Module B taught four things: containerize (Lesson 06), expose (Lesson 07), structure data (Lesson 08), call APIs (Lesson 09). Today you compose those four into one verifiable outcome: your Snake game runs in a container, is reachable from any phone in the world via a Cloudflare tunnel, reads its settings from JSON, and calls a real public API for live data. If all four are working, you have built and deployed a complete cloud-aware application — the same foundational stack a senior engineer ships when they ship anything to the public internet.

What you should have ready:

• Lesson 06's Docker image of your game (you can rebuild from your Dockerfile)
• Lesson 07's cloudflared install
• Lesson 08's config.json driving your game settings
• Lesson 09's fetch() call to a public API (quote, weather, joke — whatever you picked)
• About 60 minutes — half is verification, half is making the artefact share-worthy
• A friend or family member you can text the link to — the social verification matters

The Concept

Software-engineering milestones are not ceremonies. They are verification rituals — moments where you stop and ask "does the system actually work, end-to-end, the way I think it does?" Most learners skip this step and discover months later that something they assumed worked actually didn't. Senior engineers build verification rituals into their cadence: at the end of every meaningful sprint, every release, every refactor, you check the full path from input to output and confirm reality matches expectation.

Today's milestone has a specific shape. Module B was four lessons; the milestone tests the composition of those four lessons:

   ┌────────────┐    ┌────────────┐    ┌──────────────┐    ┌──────────────┐
   │  Lesson 06 │    │  Lesson 07 │    │   Lesson 08  │    │   Lesson 09  │
   │  Docker    │    │  Tunnel    │    │   JSON       │    │   APIs       │
   └─────┬──────┘    └─────┬──────┘    └──────┬───────┘    └──────┬───────┘
         │                 │                  │                   │
         ▼                 ▼                  ▼                   ▼
   container          public URL        config-driven         live data
   runs anywhere      reachable          settings              from internet
                      from world
                                  │
                                  ▼
                  ╔═══════════════════════════════════╗
                  ║   Milestone deliverable           ║
                  ║   A real link, in a real chat,    ║
                  ║   to a real friend, who plays a   ║
                  ║   real game running on your laptop║
                  ║   that pulls real data from a     ║
                  ║   real public API.                ║
                  ╚═══════════════════════════════════╝

Two of the four can fail silently in ways you won't notice unless you check:

• The tunnel can be running but the container can be stopped — the URL returns 502 Bad Gateway. You only see this when you try the URL from outside your network.
• The API call can be running on localhost and failing on the deployed URL because of CORS, missing API keys in the deployed environment, or a different network path. The same code runs differently in two contexts.

The way to catch these is always test the full path on a different network than your development machine. Today's verification routine — load the URL on mobile data, not WiFi — is the rehearsal for every production deploy you'll ever ship. Senior engineers test on a network they can't accidentally trust.

The other thing milestones do is make the work visible. The work you've done over the last five lessons exists, mostly, on your laptop and in your head. The milestone is the moment you turn it into a shareable artefact — a URL, a GitHub link, a screenshot — that someone else can experience without your help. This is also where the portfolio starts to grow.

Quick Concepts

What We Will Build

By the end of this lesson, you will have done these specific things:

1. Verified the Docker container runs: docker ps shows your game's container with status Up X seconds. If not, restart with docker run -d --name snake -p 3000:3000 snake-game.
2. Verified the tunnel is up: cloudflared tunnel --url http://localhost:3000 is running in a separate terminal, showing a *.trycloudflare.com URL.
3. Verified locally: load http://localhost:3000 in your browser. Game loads. The quote/weather/joke from your API call appears.
4. Verified externally: load the *.trycloudflare.com URL on your phone, with WiFi turned off (mobile data only). Game loads. The API call still appears with live data.
5. Verified config is wired: change a value in config.json (e.g., speed: 25), reload the page on your phone — observe the change live. (You may need to rebuild the Docker image if config.json is baked in; or mount it as a volume — both options are good practice.)
6. Verified API failure handling: stop your computer's WiFi for ten seconds while the game is loading on your phone. The game should still load (with the fallback message you wrote in Lesson 09's try/catch), not crash.
7. Sent the URL to one friend — through WhatsApp, Slack, email, whatever. Got back confirmation that it loaded for them. Asked them what they thought.
8. Captured a screenshot or short screen recording of the game running. This becomes a portfolio artefact you'll attach when you publish to GitHub in Module C, or when you eventually apply to a role.
9. Wrote a 100-word summary of what you built. Save it somewhere — MILESTONE.md in your repo is a good place. Future you, in three months, will not remember the details. Past-you should leave them written down.

Think About

Before studying, consider:

1. The first time anyone outside your home loads your game, something will surprise you. Maybe the API call fails. Maybe the styling is broken on mobile. Maybe the URL is too long to remember. Each surprise is an actual lesson — write it down.
2. Your laptop is currently the production server for this app. What happens when you close the lid? When the wifi disconnects? When you restart? Module C and beyond will graduate you to real hosting where the server stays up. But the disciplines you learn this week — checking the URL, testing on different networks, handling failure gracefully — are the disciplines that don't change.

By the End

After this lesson, you'll:

• ✅ Have verified all four Module B technologies are composing correctly
• ✅ Have proof — your URL, opened by someone outside your house, working
• ✅ Have at least one friend's confirmation that they could play the game
• ✅ Have a screenshot or screen recording as a portfolio artefact
• ✅ Have a 100-word MILESTONE.md summary of what was built
• ✅ Be ready for Module C — Full-Stack Systems, where the server moves out of your basement

Module B in three lines: you containerized, you tunneled, you connected. Tomorrow we go full-stack. 🎊

What We Learned

• A milestone is a verification ritual, not a ceremony. You test the full path end-to-end and prove the system works the way you think it does.
• The four Module B technologies compose into one cloud-aware application: containerize (Docker) → expose (Cloudflare Tunnel) → configure (JSON) → integrate (APIs).
• Always verify on a network you can't accidentally trust — mobile data, not WiFi. Reproduces the experience of an actual user, who is not in your house.
• Failure handling is part of the deliverable. A milestone that crashes when the wifi blips for ten seconds is not a milestone; it's a demo.
• Make the work visible. A URL, a screenshot, a MILESTONE.md — the artefacts that will be useful to future-you, hiring managers, and the next person you collaborate with.

Commands We Used

# Verify the container is running
docker ps                                          # should show your snake-game container "Up"

# Verify the tunnel is running
ps aux | grep cloudflared                          # should show the cloudflared process
# Or check the terminal where you ran:
# cloudflared tunnel --url http://localhost:3000

# Quick local verification
curl http://localhost:3000 | head                  # should return HTML
curl https://your-tunnel-url.trycloudflare.com | head  # same HTML, via tunnel

# Verify the API call is firing
curl https://your-tunnel-url.trycloudflare.com/    # follow logs in another terminal
docker logs -f snake                               # see your app's stdout

# Test API failure handling — stop the API the game depends on
# (e.g., temporarily block your machine from reaching the API)
# Game should fall back gracefully, not 500

A starter MILESTONE.md you can drop in your repo:

# Module B Milestone — Snake Game, Globally Reachable

**Date completed:** YYYY-MM-DD
**URL when written:** https://my-tunnel.trycloudflare.com (ephemeral)
**Stable URL (if named tunnel):** https://snake.<my-domain>.com
**GitHub:** https://github.com/<my-user>/snake-game

## What's deployed

- A Snake game built across Lessons 01-05 (Antigravity → VS Code → 3D → Terminal → GitHub)
- Containerized via Lesson 06's Dockerfile
- Tunneled to the public internet via Lesson 07's `cloudflared`
- Settings driven by `config.json` from Lesson 08
- Loading screen pulls a "quote of the day" from the public API at api.quotable.io (Lesson 09)

## What I verified

- [x] Container runs: `docker ps` shows snake-game "Up"
- [x] Tunnel is up: cloudflared running, public URL accessible
- [x] Loaded on mobile data (not WiFi) — confirmed external reachability
- [x] Friend X loaded the URL on their device, confirmed game playable
- [x] API failure path: turned off API connection, game still loads with fallback message

## What surprised me

(Write down 1-3 things you learned during the verification ritual that you didn't expect.)

## What I'd do differently

(Write down 1-2 changes you'd make if starting fresh, with hindsight.)

## Next: Module C — Full-Stack Systems

Why It Matters

The disciplines you practiced today — check the full path, test on a different network, write down what was built, handle failure gracefully — are not specific to Module B. They are the disciplines that separate engineers who ship reliable systems from engineers who ship "it worked when I wrote it." Production engineering is mostly verification rituals dressed up as workflows.

The milestone artefacts you produced today are also genuinely useful for the next chapters of your career. Three concrete benefits:

1. The URL is a portfolio link. Until today, your work existed only on your laptop. Now it has a public face. When you apply to roles in Lesson 20, this matters.
2. The MILESTONE.md is documentation muscle memory. In Module C, your apps will get more complex; the habit of leaving a short written record of what was built and verified scales with the complexity.
3. The friend's feedback is your first user research. Most engineers go years without watching someone else use their software. The faster you start, the better the engineer you become.

What this lesson glossed over but you'll meet in Module C:

• Real hosting. Your laptop is the production server today. In Module C and beyond, the server moves to Cloudflare Pages / Workers / a managed VPS / a Kubernetes cluster — the disciplines transfer; the persistence and scale grow.
• CI/CD pipelines. Today you deploy by running commands locally. The next step is a GitHub Action that builds and deploys on every push to main. Lesson 14 hints at this; the full pattern lands in Module D.
• Custom domains. The bonus from Lesson 07 — pointing your own domain at a named tunnel — is the right next step the moment you want a permanent shareable link.
• Observability. A real production system needs logs, metrics, and alerts. Today you used docker logs; production systems use centralized logging, dashboards, and on-call rotations.

The single most valuable habit you'll carry forward from this lesson: never call something done until you've watched someone else use it on a network you don't control. That is the milestone discipline.

Checklist

• My Docker container is running (docker ps shows "Up")
• My Cloudflare tunnel is up and a public URL exists
• I loaded the URL on mobile data (not WiFi) and the game worked
• My config.json settings are reflected in the running game
• My API call returns live data on the loaded page
• My API failure path is graceful (try/catch + fallback message)
• I sent the URL to a friend and got confirmation it worked for them
• I captured a screenshot/recording of the running game
• I wrote a MILESTONE.md with what was built, what was verified, and what surprised me

Quick Quiz

Q1: What is a milestone in software engineering?

• A) A celebration after a deadline
• B) A verification ritual that confirms the full system works end-to-end ✓
• C) A type of project management tool

Q2: Why test your tunneled URL on mobile data, not WiFi?

• A) Mobile data is faster
• B) Mobile data is on a different network — it reproduces what an external user experiences ✓
• C) WiFi blocks Cloudflare

Q3: A 502 Bad Gateway from your tunnel means what?

• A) Cloudflare is down
• B) The tunnel is up, but the container behind it is unreachable (probably stopped) ✓
• C) Your password is wrong

Q4: Why write a MILESTONE.md?

• A) Required for course completion
• B) Future-you will not remember the details; the artefact captures them ✓
• C) It's required by GitHub

Q5: What is the core discipline this lesson reinforces?

• A) Always test on a network you don't fully control before declaring done ✓
• B) Always write code in TypeScript
• C) Always use Docker for everything

Bonus Challenge

Post a 60-second screen recording of your game running on your phone (over mobile data) to LinkedIn or Twitter. Tag #ABCsteps and link your GitHub repo. Frame it honestly — "this is my Module B milestone for the ABCsteps AI Engineering Course; built from zero in 10 days" — not as marketing, as a real share with people who care about engineering education in India and elsewhere. The first time someone outside your immediate circle replies, you'll feel why visible work compounds.

Next Lesson — opening Module C

Lesson 11: AI Products Are API Systems — The ChatGPT Secret Revealed

Module B is complete. You have a frontend that runs anywhere, talks to public APIs, and is reachable from the world. Module C — Full-Stack Systems (Lessons 11-15) takes you from API consumer to API provider — your own server, your own routes, your own database.

You've called other people's APIs. You've seen JSON come back. You've handled failure. Lesson 11 starts the deconstruction: how AI products themselves — ChatGPT, Claude, Gemini — are built on the same primitives you just practiced. The "magic" of LLM apps is mostly architecture, and once you see it, you start building your own.

Module B complete. You shipped to the world. Five down, fifteen to go. 🎊