🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🚚 धडा 12 — Build, deploy आणि observe: फलक भिंतीवर लावणे

📍 तुम्ही इथे आहात: 12 पैकी धडा 12 — शेवटचा धडा! · मागील: lesson-11-talking-to-backends

📦 या ब्रँचमध्ये काय आहे

संपूर्ण कोर्स, आणि त्यासोबत शेवटचा टप्पा: build काय करतो, फलक deploy कसा होतो (त्या फक्त files असतात), लोकांना नवीन version दिसावे म्हणून cache busting, आणि खऱ्या users चे निरीक्षण — आणि त्यासोबत कळस-प्रकल्प (capstone).

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

फलक तुमच्या टेबलावर चालतो. सगळ्यांना दिसेल अशा भिंतीवर तो लावण्यासाठी तीन गोष्टी घडतात:

Build 🏗️ — files bundle आणि minify करा, आणि प्रत्येकीला तिच्या content चा hash असलेले नाव द्या: app.7f3c2a.js. (आपल्या फलकाला build अजिबात लागत नाही — तीन साध्या files — आणि छोट्या फलकासाठी हे पूर्णपणे योग्य उत्तर आहे.)
Deploy 🚚 — files static host वर copy करा आणि CDN ला वाचकांजवळ प्रती ठेवू द्या: GitHub Pages, S3 + CloudFront, Netlify, Cloudflare Pages. फलक म्हणजे फक्त files; चालवायला कोणताही server नाही.
Cache busting 🧊 — HTML थोडा वेळ cache होते, hashed files कायमच्या. नवीन build नवीन नावे बनवतो, म्हणून कोणालाच कधी अर्धा-जुना फलक दिसत नाही. (म्हणूनच धडा 09 मधले "वर्षभर cache करा" सुरक्षित आहे.)

मग तुम्ही लक्ष ठेवता 👀: खऱ्या browsers मधले JavaScript errors, खऱ्या phones वरच्या खऱ्या users चे Core Web Vitals, आणि काउंटरचे calls किती वेळा अयशस्वी होतात. कारण फलक तुमच्या मालकीच्या नसलेल्या हजार devices वर राहतो.

🗺️ आकृती

flowchart LR
    src["📁 ui/index.html · styles.css · app.js"]
    build["🏗️ build (optional here)<br/>minify · bundle · hash filenames"]
    host["🚚 static host + CDN<br/>GitHub Pages · S3+CloudFront · Netlify"]
    cache["🧊 HTML: short cache · hashed assets: 1 year, immutable"]
    obs["👀 observe<br/>JS errors · web vitals (RUM) · failed API calls"]
    src --> build --> host --> cache --> obs
    obs -->|"what real users hit"| src

❓ काय

Build काय करतो: modules bundle करतो, minify, tree-shake, जुन्या browsers साठी transpile करतो, critical CSS inline करतो, hashed filenames आणि एक manifest तयार करतो. Tools: Vite, esbuild, Parcel, Rollup.
Static hosting: server process नाही, patching नाही; CDN TLS, compression आणि edge caching सांभाळतो. SPA routing ला rewrite rule लागतो, म्हणजे deep links index.html देतात.
Cache रणनीती: index.html → no-cache (किंवा छोटा max-age); /assets/app.<hash>.js → max-age=31536000, immutable.
Environments: प्रत्येक pull request साठी preview deploys (CI/CD शाळेची फाटके), मग production. API base URL चा config build मधून येतो, आणि त्यात कोणतीही secrets नसतात (धडा 11).
Observability: window.onerror / unhandledrejection → एक error service; खऱ्या users कडून LCP/INP/CLS साठी PerformanceObserver (RUM); front-end आणि back-end logs जोडण्यासाठी प्रत्येक API call ला एक request id (API शाळेचा धडा 12).
Rollback: आधीचा build पुन्हा deploy करा — hashed assets मुळे दोन्ही versions सुरक्षितपणे एकत्र राहू शकतात.

🤔 का

कारण कोणालाच पोहोचता न येणारा फलक हा फलकच नाही, आणि कारण deploy चे दोन नेहमीचे bugs पूर्णपणे टाळता येतात: लोकांना शिळे पान दिसणे (चुकीचे cache headers) आणि कोणाच्याच लक्षात न आलेले मोडलेले release (error reporting नाही). दोन्ही हुशारीने नाही, तर settings ने सुटतात.

🔧 कसे (या repo मध्ये)

ही शाळाच याचे प्रात्यक्षिक आहे: प्रत्येक course site म्हणजे GitHub Pages वरच्या static files, push वर deploy होणाऱ्या. तुमचा फलकही तसाच लावता येतो — framework नाही, server नाही, एक command.

🧪 करून पाहा — कळस-प्रकल्प (capstone)

# 1) deploy the board (5 minutes, free):
#    - copy ui/ into docs/app/ of your fork, commit and push
#    - GitHub → Settings → Pages → Source: main /docs
#    - open https://<you>.github.io/<repo>/app/  → your board, on the internet
#    (the counter is local-only, so point API at a deployed one or ship a static fallback list)
# 2) see caching in action: DevTools → Network, reload twice — the second load shows "(disk cache)" for styles.css
# 3) add crash reporting in 6 lines, in app.js:
#      window.addEventListener('error', e => navigator.sendBeacon('/api/log', JSON.stringify({msg: e.message, src: e.filename, line: e.lineno})));
#      window.addEventListener('unhandledrejection', e => console.warn('unhandled', e.reason));
# 4) measure a real vital in the browser:
#      new PerformanceObserver(l => l.getEntries().forEach(e => console.log('LCP', Math.round(e.startTime), 'ms'))).observe({type:'largest-contentful-paint', buffered:true});
# 5) 🏆 THE CAPSTONE — add a homework list to the board, end to end:
#      HTML section with a heading and a list (L02) · layout in the grid (L03) · state.homework + a component + render (L04–05)
#      · labels, live region, keyboard pass (L06) · tokens only, works in dark mode (L08) · lazy/sized images if you add any (L09)
#      · three new smoke checks (L10) · fetch from /api/homework with loading and error faces, textContent only (L11) · deployed (L12)

✅ तपासा — तुम्हाला काय दिसायला हवे

तुमचा फलक सार्वजनिक URL वर उत्तर देतो. दुसऱ्या reload ला CSS disk cache मधून येते. Console मध्ये काही throw केले की error listener चालतो, आणि observer milliseconds मध्ये LCP छापतो. Capstone फलक smoke_test.py pass करतो — तुमच्या तीन नवीन तपासण्यांसह — आणि homework यादी दोन्ही themes मध्ये आणि फक्त keyboard वरूनही चालते.

🏁 तुम्ही आत्ताच काय सिद्ध केले

तुमच्या laptop वरच्या तीन files पासून तुम्ही फलक एका सार्वजनिक, cache होणाऱ्या, निरीक्षणाखालच्या URL पर्यंत नेलात — आणि कोर्सच्या प्रत्येक थरातून एक संपूर्ण feature जोडले.

⚠️ नेहमीच्या चुका

index.html बराच काळ cache करणे (नवीन build कोणालाच दिसत नाही)
लांब cache वेळेसह hash नसलेली asset नावे (ताज्या HTML सह शिळी JS — सगळ्यात वाईट जोडी)
build config मध्ये secrets (ती प्रत्येक visitor ला पाठवली जातात)
error reporting नाही — मोडतोड तुम्हाला users कडून कळते
rollback योजनेशिवाय deploy करणे; hashed assets सह जुना build ठेवणे फुकट आहे

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: कंपनी करते त्यातले सगळ्यात वारंवार deploys म्हणजे front-end deploys. Static hosting, hashed assets आणि real-user monitoring ही कंटाळवाणी रचनाच त्यांना घटनाविरहित बनवते.

🎓 फलक तुमचा आहे

सूचना फलक → semantic सांगाडा → वाकणारी मांडणी → events → सत्याचा एकच स्रोत → प्रत्येकजण तो वाचू शकतो → frameworks, समजलेले → गणवेश → जलद → test केलेला → काउंटरशी सुरक्षितपणे बोलणारा → भिंतीवर लावलेला आणि लक्ष ठेवलेला. तुम्ही फक्त UI शिकला नाहीत — तुम्ही एक फलक चालवता. 📌🎓

संपूर्ण शाळा, सुरुवातीपासून शेवटपर्यंत: Database शाळा सत्य जपते, API शाळा चिठ्ठ्यांना उत्तर देते, हा फलक ते लोकांना दाखवतो, आणि CI/CD शाळा प्रत्येक push वर तो भिंतीवर लावते.

git checkout main
python3 ui/mock_api.py     # one last look at the board

🚚 Lesson 12 — Build, deploy & observe: pinning the board up

📍 You are here: Lesson 12 of 12 — the final lesson! · Previous: lesson-11-talking-to-backends

📦 What's in this branch

The complete course, plus the last mile: what a build does, how a board is deployed (it is just files), cache busting so people see the new version, and observing real users — plus the capstone.

🧒 Explain like I'm 5

The board works on your desk. To put it on the wall where everyone can see it, three things happen:

Build 🏗️ — bundle and minify the files, and give each one a name containing a hash of its contents: app.7f3c2a.js. (Our board needs no build at all — three plain files — which is a perfectly good answer for a small board.)
Deploy 🚚 — copy the files to a static host and let a CDN keep copies near readers: GitHub Pages, S3 + CloudFront, Netlify, Cloudflare Pages. A board is just files; there is no server to run.
Cache busting 🧊 — the HTML is cached briefly, the hashed files forever. A new build makes new names, so nobody ever sees a half-old board. (This is why lesson 09's "cache for a year" is safe.)

Then you watch 👀: JavaScript errors from real browsers, the Core Web Vitals of real users on real phones, and how often the counter's calls fail. Because the board lives on a thousand devices you do not own.

🗺️ Diagram

flowchart LR
    src["📁 ui/index.html · styles.css · app.js"]
    build["🏗️ build (optional here)<br/>minify · bundle · hash filenames"]
    host["🚚 static host + CDN<br/>GitHub Pages · S3+CloudFront · Netlify"]
    cache["🧊 HTML: short cache · hashed assets: 1 year, immutable"]
    obs["👀 observe<br/>JS errors · web vitals (RUM) · failed API calls"]
    src --> build --> host --> cache --> obs
    obs -->|"what real users hit"| src

❓ What

What a build does: bundle modules, minify, tree-shake, transpile for older browsers, inline critical CSS, emit hashed filenames and a manifest. Tools: Vite, esbuild, Parcel, Rollup.
Static hosting: no server process, no patching; the CDN handles TLS, compression and edge caching. SPA routing needs a rewrite rule so deep links serve index.html.
Cache strategy: index.html → no-cache (or a short max-age); /assets/app.<hash>.js → max-age=31536000, immutable.
Environments: preview deploys per pull request (the CI/CD school's gates), then production. Config for the API base URL comes from the build, and contains no secrets (lesson 11).
Observability: window.onerror / unhandledrejection → an error service; PerformanceObserver for LCP/INP/CLS from real users (RUM); a request id per API call to join front-end and back-end logs (API school lesson 12).
Rollback: redeploy the previous build — with hashed assets, both versions can coexist safely.

🤔 Why

Because a board nobody can reach is not a board, and because the two classic deploy bugs are entirely preventable: people seeing a stale page (bad cache headers) and a broken release nobody noticed (no error reporting). Both are solved with settings, not cleverness.

🔧 How (in this repo)

This very School is the demonstration: every course site is static files on GitHub Pages, deployed on push. Your board can go up the same way — no framework, no server, one command.

🧪 Try it — the capstone

# 1) deploy the board (5 minutes, free):
#    - copy ui/ into docs/app/ of your fork, commit and push
#    - GitHub → Settings → Pages → Source: main /docs
#    - open https://<you>.github.io/<repo>/app/  → your board, on the internet
#    (the counter is local-only, so point API at a deployed one or ship a static fallback list)
# 2) see caching in action: DevTools → Network, reload twice — the second load shows "(disk cache)" for styles.css
# 3) add crash reporting in 6 lines, in app.js:
#      window.addEventListener('error', e => navigator.sendBeacon('/api/log', JSON.stringify({msg: e.message, src: e.filename, line: e.lineno})));
#      window.addEventListener('unhandledrejection', e => console.warn('unhandled', e.reason));
# 4) measure a real vital in the browser:
#      new PerformanceObserver(l => l.getEntries().forEach(e => console.log('LCP', Math.round(e.startTime), 'ms'))).observe({type:'largest-contentful-paint', buffered:true});
# 5) 🏆 THE CAPSTONE — add a homework list to the board, end to end:
#      HTML section with a heading and a list (L02) · layout in the grid (L03) · state.homework + a component + render (L04–05)
#      · labels, live region, keyboard pass (L06) · tokens only, works in dark mode (L08) · lazy/sized images if you add any (L09)
#      · three new smoke checks (L10) · fetch from /api/homework with loading and error faces, textContent only (L11) · deployed (L12)

✅ Verify — what you should see

Your board answers on a public URL. The second reload serves CSS from the disk cache. The error listener fires when you throw something in the console, and the observer prints an LCP in milliseconds. The capstone board passes smoke_test.py — including your three new checks — with the homework list working in both themes and from the keyboard alone.

🏁 What you just proved

You took a board from three files on your laptop to a public, cached, observed URL — and added a whole feature through every layer of the course.

⚠️ Common mistakes

caching index.html for a long time (nobody sees the new build)
unhashed asset names with long cache times (stale JS with fresh HTML — the worst combination)
secrets in the build config (they ship to every visitor)
no error reporting — you learn about breakage from users
deploying without a rollback plan; with hashed assets, keeping the old build is free

🏭 Why this matters in production: front-end deploys are the most frequent deploys a company does. Static hosting plus hashed assets plus real-user monitoring is the boring setup that makes them uneventful.

🎓 The board is yours

The notice board → semantic skeleton → layout that bends → events → one source of truth → everyone can read it → frameworks, understood → the uniform → fast → tested → talking safely to the counter → pinned up and watched. You didn't just learn UI — you run a board. 📌🎓

The whole school, end to end: the Database school keeps the truth, the API school answers the slips, this board shows it to people, and the CI/CD school pins it up on every push.

git checkout main
python3 ui/mock_api.py     # one last look at the board

← Previoustalking to backends Finished! Take the quiz →check what stuck

This page is the lesson's README from the lesson-12-build-deploy-observe branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.