MSIT 9 Midterm Reviewer

Oct 16, 2026 · Engr. Chad Aga D. Abinguna

Coverage and cheat sheet

The midterm covers report Topics 2 to 5 of the MSIT 9 syllabus (SSU, Prof. Sweet Mercy F. Pacolor). The syllabus weights are 6, 6, 5 and 6 sessions, so budget your review time about equally, with Topic 4 slightly lighter. Topic 3 is drawn from your own report deck; Topics 2, 4 and 5 follow standard references (MDN, web.dev, Kubernetes and platform docs) because the classmates' decks are not in your folder.

Topic	Title	Weight	Core idea in one line
2	Modern Web Frontend Development and Progressive Web Applications	6	The browser renders HTML/CSS/JS; a PWA adds a manifest, a service worker and HTTPS to behave like an installed app.
3	Web Backend Development, APIs, Data Services, and Real-time Applications	6	The backend holds truth and rules; APIs are the contract; real-time escapes request–response.
4	Web Application Deployment, Cloud Services, and Distributed Architectures	5	Package once (containers), ship automatically (CI/CD), scale out behind a load balancer.
5	Mobile Application Development and Cross-Platform Architecture	6	Choose native, cross-platform, hybrid or PWA by performance, device access, team skills and budget.

Decision rules worth memorising

Static marketing page → SSG. Personalised, SEO-critical page → SSR. Logged-in dashboard → CSR.
Assets that rarely change → cache first. News or API data → network first. Avatars and feeds → stale-while-revalidate.
Client also sends → WebSocket. Server only → SSE. Audio/video → WebRTC. Rare updates → polling.
Relationships and correctness (grades, payments) → SQL. Shape varies or huge scale → NoSQL.
401 = I don't know you. 403 = I know you, and no. 4xx = your fault, 5xx = my fault.
You manage everything above the hardware → IaaS. Only code and data → PaaS. Only the function → FaaS. Only use the app → SaaS.
Zero-downtime with instant rollback → blue-green. Small % of users first → canary. Replace pods gradually → rolling.
Max performance and full device APIs → native. One codebase, near-native UI → Flutter / React Native. Web skills, light device needs → hybrid or PWA.

Topic 2 — Modern Web Frontend Development and PWAs

The frontend is everything that runs in the user's browser; a Progressive Web App (PWA) is a website that adds a web app manifest, a service worker and HTTPS so it can be installed, work offline and send notifications.

2.1 The three layers of the web

Layer	Job	Key ideas
HTML	Structure and meaning	Semantic elements (`header`, `nav`, `main`, `article`, `button`) give meaning to screen readers and search engines.
CSS	Presentation	Box model, Flexbox (one dimension), Grid (two dimensions), media queries, custom properties (variables).
JavaScript	Behaviour	DOM manipulation, events, `fetch()` for API calls, async/await, ES modules.

How a browser renders a page (critical rendering path): parse HTML into the DOM → parse CSS into the CSSOM → combine into the render tree → layout (compute sizes and positions) → paint → composite. CSS is render-blocking; synchronous JavaScript is parser-blocking, which is why scripts get defer or async.

2.2 Frameworks and the component model

A component is a reusable, self-contained piece of UI with its own markup, style and logic (a button, a card, a navbar).
React (library, JSX, virtual DOM), Vue (progressive framework, templates, reactivity), Angular (full framework, TypeScript, dependency injection), Svelte (compiler, no virtual DOM at runtime).
Virtual DOM: an in-memory copy of the UI; the library compares (diffs) the new and old copies and patches only what changed in the real DOM.
State = data that changes over time and drives what the UI shows. Props = data passed from parent to child. One-way data flow: data goes down, events go up.
SPA (single-page application): one HTML page; JavaScript swaps views without full reloads, using client-side routing.
Tooling: npm (packages), Vite / webpack (bundlers and dev servers), TypeScript (static types on JavaScript), Tailwind (utility-first CSS).

2.3 Rendering strategies

Strategy	Where HTML is built	When	Best for	Trade-off
CSR — client-side rendering	Browser	On every visit, after JS loads	Dashboards, apps behind a login	Slow first paint, weaker SEO
SSR — server-side rendering	Server	On every request	Personalised pages that need SEO (product pages, feeds)	Server cost per request
SSG — static site generation	Build server	Once, at build time	Blogs, docs, marketing sites	Content stale until rebuilt
ISR — incremental static regeneration	Build server, then in the background	At build, then re-generated after a set interval	Large catalogues that change occasionally	Briefly stale pages

Hydration = the browser attaches JavaScript event handlers to HTML that the server already rendered. Meta-frameworks bundle these choices: Next.js (React), Nuxt (Vue), SvelteKit, Astro (islands architecture — ship JS only for interactive parts).

2.4 Responsive and accessible UI

Responsive design = one layout that adapts to any screen: fluid grids, flexible images, media queries, and the viewport meta tag <meta name="viewport" content="width=device-width, initial-scale=1">.
Mobile-first = write the small-screen CSS first, then add min-width media queries for larger screens.
Breakpoints are where the layout changes; relative units (rem, %, vw) scale better than fixed px.
Accessibility (a11y) follows WCAG 2.2, built on POUR: Perceivable, Operable, Understandable, Robust. Levels A, AA (the usual legal target), AAA.
Practical checks: alt text on images, colour contrast at least 4.5:1 for body text, every function reachable by keyboard, visible focus, form labels, semantic HTML first and ARIA only to fill gaps ("no ARIA is better than bad ARIA").

2.5 Performance — Core Web Vitals

Metric	Measures	Good
LCP — Largest Contentful Paint	Loading: when the main content appears	≤ 2.5 s
INP — Interaction to Next Paint	Responsiveness to clicks and taps (replaced FID in March 2024)	≤ 200 ms
CLS — Cumulative Layout Shift	Visual stability: how much content jumps	≤ 0.1

Techniques: code splitting and lazy loading, image optimisation (WebP/AVIF, srcset, loading="lazy"), minification and compression, caching, a CDN, and reserving space for images to avoid layout shift. Tool: Lighthouse in Chrome DevTools audits Performance, Accessibility, Best Practices, SEO and PWA.

2.6 Progressive Web Apps

A PWA has three technical requirements:

HTTPS — service workers only run on secure origins (localhost is allowed for development).
Web app manifest (manifest.json) — name, short_name, icons, start_url, display (standalone, fullscreen, minimal-ui, browser), theme_color, background_color. It makes the app installable.
Service worker — a JavaScript file that runs in the background, separate from the page, acting as a programmable network proxy. It has no DOM access.

Service worker lifecycle: register → install (pre-cache the app shell) → activate (clean old caches) → idle / fetch (intercept requests) → terminated when idle. A new version waits until all tabs using the old one close, unless skipWaiting() is called.

App shell model: cache the minimal HTML, CSS and JS for the UI frame so it loads instantly, then fill content from the network.

Caching strategy	How it works	Use for
Cache first	Serve from cache; go to network only on a miss	Fonts, icons, app shell, versioned assets
Network first	Try network; fall back to cache when offline	News, API data that must be fresh
Stale-while-revalidate	Serve cache now, update cache from network in background	Avatars, feeds, non-critical data
Cache only	Never touch the network	Pre-cached static assets
Network only	Never cache	Payments, analytics, login

Other PWA capabilities: Push API + Notifications API (server-sent push even when the tab is closed), Background Sync (retry failed requests when connectivity returns), Cache Storage API and IndexedDB (offline data), Web Share, Badging. Workbox is Google's library for writing service-worker caching rules. Limits: iOS supports installed PWAs and web push (since iOS 16.4) but with fewer APIs than Android, and PWAs cannot reach every native API (e.g., full Bluetooth or background location).

PWA vs native in one line: a PWA is one codebase, no app-store gatekeeping and instant updates, but has weaker device access and discoverability inside app stores.

Topic 3 — Web Backend, APIs, Data Services, and Real-time Applications

The backend is where truth and rules live; an API is the contract the frontend uses to reach it; real-time techniques exist to escape the request–response limit that the server cannot speak first. (Source: your 60-slide report deck and its Word copy.)

3.1 The backend

Definition: the server-side layer responsible for business logic, data persistence, authentication, integration with external systems, and serving data to clients over a network.
Reinstall test: if data survives an app reinstall or appears on another phone with the same account, it lives in the backend.
Request–response cycle: the client asks, the server answers. Nothing happens until someone asks.
Three-part picture: client → server (code + API) → database, with supporting services (cache, file storage, SMS/email, payment gateway, push service). The client never talks to the database directly — the server is the bouncer.
Five jobs of a backend: (1) routing, (2) business logic, (3) data persistence, (4) authentication and authorization, (5) integration. Never trust the client.
Frameworks: Express/NestJS (JS/TS), Django/FastAPI/Flask (Python), Laravel (PHP), Spring Boot (Java), ASP.NET Core (C#), Gin/Fiber (Go), Rails (Ruby). No "best" — pick what the team can maintain and the host supports.
Monolith (sari-sari store: one program does everything; simple, cheap, one bug can take all down) vs microservices (mall: many small services over a network; independent scaling, much harder to operate). Start with a monolith.
Serverless = you do not manage the server; pay per execution (AWS Lambda, Cloud Functions, Vercel, Cloudflare Workers). Trade-off: cold start (1–3 s on first call after idle). Edge = run code in a data centre near the user.

3.2 Authentication and authorization

AuthN = WHO are you (login). AuthZ = WHAT may you do (permissions).
Mechanisms: session + cookie (server remembers you), JWT (signed token sent as Authorization: Bearer <token>; server stays stateless), OAuth 2.0 ("Sign in with Google" — delegated, you never give the app your password).
Passwords are hashed (bcrypt, Argon2), never stored as plain text or MD5.
Login flow: POST /auth/login over HTTPS → find user → hash and compare → issue JWT (e.g., 1-hour expiry) → 200 OK. Failure → 401 with "invalid email or password" (do not reveal which half was wrong).

3.3 APIs

API = a defined contract of endpoints, methods, parameters and response formats through which one system requests services or data from another. Analogies: the waiter; the power outlet (stable interface hiding a changing plant).
Anatomy of a request: method, URL (endpoint), headers, body (GET has no body).

CRUD	HTTP method	Example
Create	POST	POST /students
Read	GET	GET /students/12
Update	PUT (replace whole) / PATCH (change some fields)	PATCH /students/12
Delete	DELETE	DELETE /students/12

GET must never change data (crawlers follow links).

Status family	Meaning	Common codes
2xx	Success	200 OK, 201 Created, 204 No Content
3xx	Redirect	301 Moved Permanently, 304 Not Modified
4xx	Client error — your fault	400, 401 Unauthorized, 403 Forbidden, 404, 429 Too Many Requests
5xx	Server error — my fault	500, 502 Bad Gateway, 503 Service Unavailable

REST (REpresentational State Transfer, Roy Fielding, 2000): resources with addresses, standard verbs, stateless, nouns not verbs (/students, never /getStudentList), uniform interface, cacheable. Weakness: over-fetching and under-fetching.
JSON: six building blocks — string, number, boolean, null, array, object. Replaced XML: shorter, lighter, native to JavaScript.
GraphQL: one endpoint (/graphql); the client chooses the exact fields; strongly typed schema. Costs: harder HTTP caching, N+1 risk. Analogy: build-your-own bowl vs REST's fixed combo meal.
gRPC: Google's service-to-service framework; Protocol Buffers (binary), HTTP/2, bidirectional streaming; needs a proxy in browsers.
Webhooks: "don't call us, we'll call you" — the provider calls your URL when an event happens (e.g., payment cleared).
Mature answer: REST for public APIs, GraphQL for your own app screens, gRPC between internal services.
API good practice: documentation (OpenAPI/Swagger), versioning (/v1/), rate limiting (429), API keys/tokens, HTTPS only, validate every input, pagination (?page=2&limit=50).

3.4 Data services

Data layer ≠ just the database: database, cache, object storage, CDN, search service, message queue.
SQL (relational): tables, fixed columns, keys, joins, ACID (Atomicity, Consistency, Isolation, Durability). MySQL/MariaDB, PostgreSQL, SQL Server, Oracle.
NoSQL: document (MongoDB, Firestore), key-value (Redis), graph (Neo4j), wide-column (Cassandra). Trades some consistency for flexibility and scale.
Default for school and enterprise systems: SQL. Most real systems use both.
ORM (Object-Relational Mapper: Prisma, Django ORM, SQLAlchemy, Eloquent, Hibernate) — faster development, injection protection, migrations. Trap: N+1 query problem (100 students → 101 queries).
Caching (Redis: <1 ms vs about 200 ms DB). Hard part = invalidation; use a TTL and clear on update.
Object storage (S3, R2, MinIO) for files; store the link in the DB. CDN for global copies. Signed URLs let the phone upload straight to storage.
BaaS (Firebase, Supabase, Appwrite, PocketBase): fast for prototypes; watch for lock-in and cost at scale.
Queues and background jobs (RabbitMQ, Celery, BullMQ, Laravel Queues): reply "we're working on it" immediately, let a worker do the slow job.

3.5 Real-time applications

Real-time = data delivered within milliseconds of an event, usually over a persistent connection, without the client asking.
Plain HTTP is request–response and stateless — the server cannot speak first.

Technique	Direction	Protocol	Use for
Short polling	Client asks every N s	HTTP	Simple, infrequent updates
Long polling	Server holds the request until data arrives	HTTP	Fallback when WebSockets are blocked
SSE (Server-Sent Events)	Server → client	HTTP, `EventSource`, auto-reconnect	Notifications, feeds, AI token streaming
WebSocket	Both ways, full-duplex	HTTP upgrade to `ws://` / `wss://`	Chat, games, collaboration
WebRTC	Peer ↔ peer	UDP/SRTP, needs signaling + STUN/TURN	Video, voice, screen share

SSE limit: about 6 connections per domain on HTTP/1.1 (lifted by HTTP/2). WebSocket gap: no built-in reconnection.
Patterns: rooms/channels, pub/sub (Redis, MQTT, Kafka), presence (online dot, "typing…"), optimistic UI, offline queue.
Scaling WebSockets: connections are stateful → shared pub/sub backplane (Redis) + sticky sessions at the load balancer, or a managed service (Pusher, Ably, Firebase, Supabase Realtime).

3.6 Security checklist (10 items)

HTTPS everywhere · hash passwords (bcrypt/Argon2) · validate input on the server · parameterised queries or ORM · least privilege for DB accounts · secrets in environment variables, not the repo · short-lived tokens + refresh tokens · rate-limit login · log security events but never passwords or tokens · comply with the Data Privacy Act of 2012 (RA 10173).

Topic 4 — Web Application Deployment, Cloud Services, and Distributed Architectures

Deployment is getting code from a developer's machine to users reliably and repeatedly: package it once (containers), ship it automatically (CI/CD), run it on rented infrastructure (cloud), and spread it across many machines so it survives failures and load (distributed architecture).

4.1 Hosting options and cloud service models

Hosting ladder: shared hosting → VPS (virtual private server) → dedicated server → cloud (on-demand, pay as you go).
NIST definition of cloud computing — five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service.

Model	You manage	Provider manages	Examples
IaaS — Infrastructure as a Service	OS, runtime, app, data	Hardware, network, virtualisation	AWS EC2, Google Compute Engine, Azure VMs
PaaS — Platform as a Service	App code and data	Everything below the app	Heroku, Google App Engine, Render, Azure App Service
FaaS — Function as a Service (serverless)	Individual functions	Servers, scaling, runtime	AWS Lambda, Cloud Functions, Vercel Functions
SaaS — Software as a Service	Only your settings and data	The whole application	Gmail, Google Workspace, Microsoft 365

Deployment models: public cloud, private cloud, hybrid cloud (mix of on-premises and public), multi-cloud (several providers), community cloud.
Shared responsibility model: the provider secures the cloud (hardware, facilities); the customer secures what they put in it (data, identities, configuration).
Big three providers: AWS, Microsoft Azure, Google Cloud. Others: DigitalOcean, Cloudflare, Vercel, Netlify (frontend/JAMstack hosting).

4.2 Containers and orchestration

Virtual machine = a full guest OS on a hypervisor; heavy, boots in minutes. Container = the app plus its dependencies sharing the host OS kernel; light, starts in seconds. Solves "it works on my machine."
Docker vocabulary: Dockerfile (recipe) → image (read-only template) → container (running instance). Registry stores images (Docker Hub, GHCR). Docker Compose runs multi-container apps from one YAML file (app + database + cache).
Kubernetes (K8s) orchestrates containers across a cluster: pod (smallest unit, one or more containers), node (worker machine), deployment (desired number of pod replicas, rolling updates), service (stable network address and load balancing to pods), ingress (HTTP routing from outside), ConfigMap/Secret (configuration), Horizontal Pod Autoscaler. It self-heals by restarting failed pods.

4.3 CI/CD and DevOps

Continuous Integration (CI): every push is built and tested automatically, so integration problems surface early.
Continuous Delivery: every passing build is ready to release; a human presses the button. Continuous Deployment: every passing build goes to production automatically.
Typical pipeline: commit → build → unit tests → security/lint scans → package image → deploy to staging → integration tests → deploy to production → monitor.
Tools: GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure DevOps.
Infrastructure as Code (IaC): servers and networks described in version-controlled files (Terraform, Ansible, CloudFormation, Pulumi) so environments are repeatable.
Environments: development → testing/staging → production. Configuration through environment variables (the Twelve-Factor App principle: store config in the environment).
GitOps: the Git repository is the single source of truth for what runs in the cluster.

4.4 Deployment strategies

Strategy	How it works	Strength	Cost
Recreate (big bang)	Stop old version, start new	Simple	Downtime
Rolling	Replace instances a few at a time	No downtime, no extra fleet	Two versions live at once; slower rollback
Blue-green	Two identical environments; switch traffic from blue (old) to green (new)	Instant switch and instant rollback	Double infrastructure
Canary	Send a small % of users to the new version, then widen	Limits blast radius; real-user testing	Needs good monitoring
A/B testing	Split users to compare features or designs	Business experiment	Not a safety mechanism
Feature flags	Ship code dark; toggle features at runtime	Decouples deploy from release	Flag debt

4.5 Scaling and distributed architecture

Vertical scaling (scale up): a bigger machine — simple, but has a ceiling and a single point of failure. Horizontal scaling (scale out): more machines behind a load balancer — needs stateless servers.
Load balancer: spreads requests across servers. Algorithms: round robin, least connections, IP hash (sticky sessions), weighted. Layer 4 (TCP) vs Layer 7 (HTTP, path-based routing). Health checks remove failed nodes. Examples: Nginx, HAProxy, AWS ELB.
Reverse proxy (Nginx, Caddy, Traefik): sits in front of servers for TLS termination, caching, compression and routing. API gateway: a reverse proxy specialised for APIs (auth, rate limiting, routing to microservices).
Auto-scaling: add or remove instances by CPU, memory or request rate. Elasticity = scaling with demand automatically.
High availability: redundancy across availability zones and regions; eliminate single points of failure; measured as uptime (99.9% ≈ 8.76 hours of downtime per year; 99.99% ≈ 52.6 minutes).
CDN: caches static content at edge locations near users (Cloudflare, Akamai, CloudFront).
Database scaling: read replicas (primary handles writes, replicas serve reads), sharding (split data across servers by a key), connection pooling, caching.
CAP theorem (Brewer): in a network partition, a distributed data store must choose Consistency or Availability; Partition tolerance is mandatory over a real network. CP systems (e.g., HBase, MongoDB default) refuse some requests to stay consistent; AP systems (Cassandra, DynamoDB) stay up and reconcile later — eventual consistency. BASE (Basically Available, Soft state, Eventual consistency) is the NoSQL counterpart to ACID.
Architectural styles: monolith, SOA (service-oriented architecture, often with an enterprise service bus), microservices, event-driven architecture (services react to events via a broker such as Kafka or RabbitMQ), serverless. Supporting patterns: service discovery, circuit breaker (stop calling a failing service), saga (distributed transaction as a chain of local transactions with compensations), CQRS (separate read and write models).
Observability (preview of Topic 9): logs, metrics, traces; tools such as Prometheus, Grafana, ELK, OpenTelemetry.

Topic 5 — Mobile Application Development and Cross-Platform Architecture

Mobile development is a choice among four approaches — native, cross-platform, hybrid and PWA — traded off on performance, device access, development cost and team skills; every approach still talks to the same backend through APIs.

5.1 Platforms

	Android	iOS / iPadOS
Owner	Google (open-source AOSP base)	Apple (closed)
Native languages	Kotlin (preferred), Java	Swift (preferred), Objective-C
Official IDE	Android Studio	Xcode (macOS only)
Modern UI toolkit	Jetpack Compose (declarative)	SwiftUI (declarative)
Older UI toolkit	XML layouts / Views	UIKit (storyboards)
Package format	APK, AAB (Android App Bundle, required on Play)	IPA
Store	Google Play (plus sideloading)	Apple App Store (review required; TestFlight for betas)
Market (PH)	Large majority of phones	Minority, higher-spend users

5.2 The four development approaches

Approach	How it works	Examples	Strengths	Weaknesses
Native	Separate app per platform in the platform language	Kotlin/Compose, Swift/SwiftUI	Best performance, full device APIs, platform look	Two codebases, two teams, higher cost
Cross-platform (native-compiled or native-rendered)	One codebase compiled or bridged to native	Flutter (Dart), React Native (JS/TS), .NET MAUI (C#), Kotlin Multiplatform	About 1 codebase, near-native performance	Framework lag on new OS features; larger app size
Hybrid (WebView)	Web app (HTML/CSS/JS) wrapped in a native shell; plugins reach device APIs	Ionic + Capacitor, Apache Cordova	Reuses web skills and code	Slower, less native feel
PWA	Website installed from the browser	Any web stack + manifest + service worker	No store, instant updates, one codebase	Limited device APIs, weaker on iOS

How the cross-platform frameworks differ

Flutter (Google, Dart): draws every pixel with its own rendering engine (Skia, now Impeller); everything is a widget; hot reload; compiled ahead-of-time to native ARM code. Same UI on all platforms.
React Native (Meta, JavaScript/TypeScript): renders real native UI components; the New Architecture replaces the old asynchronous bridge with JSI (JavaScript Interface), Fabric (renderer) and TurboModules; JS engine Hermes; Expo simplifies tooling and builds.
Kotlin Multiplatform (KMP): share business logic in Kotlin; UI can stay native or use Compose Multiplatform.
.NET MAUI: C#/XAML successor to Xamarin.Forms.

5.3 App architecture inside a mobile app

Layers: presentation (UI) → domain (business rules, use cases) → data (repositories, API clients, local database). This is Clean Architecture: dependencies point inward.
MVC (Model-View-Controller): controller handles input; in iOS often becomes a "massive view controller."
MVP (Model-View-Presenter): presenter holds the logic; view is passive.
MVVM (Model-View-ViewModel): the ViewModel exposes observable state; the view binds to it. Google's recommended pattern for Android (with Jetpack ViewModel) and natural for SwiftUI.
MVI / unidirectional data flow: state flows down, user intents (events) flow up; one source of truth.
Repository pattern: one class decides whether data comes from the network or the local cache — the basis of offline-first apps.
State management (cross-platform): Flutter — Provider, Riverpod, BLoC; React Native — Redux, Zustand, Context, React Query.
Local storage: key-value (SharedPreferences / UserDefaults / AsyncStorage), SQLite and wrappers (Room on Android, Core Data / SwiftData on iOS), secure storage for tokens (Android Keystore, iOS Keychain).

5.4 App lifecycle and device features

Android Activity lifecycle: onCreate → onStart → onResume (running) → onPause → onStop → onDestroy (onRestart when returning). Rotation destroys and recreates the Activity unless state is kept in a ViewModel.
iOS app states: not running, inactive, active (foreground), background, suspended.
The OS can kill background apps at any time, so save state early.
Permissions: declared in AndroidManifest.xml / Info.plist and requested at runtime for sensitive items (camera, location, contacts, notifications); follow least privilege.
Device features: camera, GPS/location, accelerometer and gyroscope, biometrics (fingerprint, Face ID), NFC, Bluetooth, local notifications, push notifications via FCM (Firebase Cloud Messaging, Android and iOS) and APNs (Apple Push Notification service).
Deep links: a URL opens a specific screen (Android App Links, iOS Universal Links).

5.5 Building, testing and distributing

Emulator (Android) / simulator (iOS) for development; test on real low-end devices and real mobile data.
Signing: Android keystore; Apple certificates and provisioning profiles (paid Apple Developer Program).
Release: Google Play Console (internal, closed, open testing tracks; staged rollout), App Store Connect (TestFlight, App Review).
Over-the-air (OTA) updates: React Native/Expo can push JS bundle updates without a store release, within store rules.
Mobile CI/CD: Fastlane, Codemagic, Bitrise, GitHub Actions; crash reporting: Firebase Crashlytics, Sentry.
Mobile UX: touch targets about 48×48 dp (Android) / 44×44 pt (iOS); follow Material Design and Apple's Human Interface Guidelines; design for intermittent connectivity.

5.6 Choosing an approach — decision factors

Performance needs (games, AR, heavy graphics → native) · device API depth · time to market and budget (one codebase → cross-platform) · team skills (web team → React Native, Ionic or PWA; Dart learners → Flutter) · UI consistency vs platform look · offline needs · store presence · long-term maintenance. For a school system with a web admin panel and a student-facing app, one shared REST API with a Flutter or React Native client (or a PWA) is the usual defensible choice.

Commonly confused pairs

Pair	The difference
SSR vs SSG	SSR builds HTML on every request; SSG builds it once at build time.
CSR vs hydration	CSR builds the whole page in the browser; hydration attaches JS to HTML the server already sent.
Service worker vs web worker	Both run off the main thread; only the service worker intercepts network requests and survives the page closing.
Manifest vs service worker	Manifest makes the app installable (looks); service worker makes it work offline (behaviour).
LCP vs INP vs CLS	Loading vs responsiveness vs visual stability.
Authentication vs authorization	Who you are vs what you may do.
401 vs 403	Not identified vs identified but forbidden.
PUT vs PATCH	Replace the whole record vs change only the sent fields.
REST vs GraphQL	Server decides the shape, many endpoints vs client decides the shape, one endpoint.
API call vs webhook	You ask them vs they call you when an event happens.
SSE vs WebSocket	One-way server → client over HTTP with auto-reconnect vs two-way over an upgraded connection.
ACID vs BASE	Strict transactional correctness vs availability with eventual consistency.
Vertical vs horizontal scaling	Bigger machine vs more machines.
Continuous delivery vs continuous deployment	Human approves the release vs every green build ships automatically.
Blue-green vs canary	Switch all traffic between two environments vs send a small slice of users first.
Image vs container	Read-only template vs running instance of it.
VM vs container	Own guest OS on a hypervisor vs shares the host kernel.
PaaS vs FaaS	You deploy an app that runs continuously vs a function that runs per event.
Hybrid vs cross-platform	WebView wrapping web code vs native-compiled or native-rendered UI from one codebase.
Flutter vs React Native	Draws its own widgets (Dart) vs renders real native components (JavaScript).
MVVM vs MVC	View binds to observable ViewModel state vs controller pushes updates to the view.
FCM vs APNs	Google's push service (Android and cross-platform) vs Apple's push service (iOS).

Practice set (answers below)

Which rendering strategy builds HTML once at build time? (a) CSR (b) SSR (c) SSG (d) Hydration
Which file makes a PWA installable? (a) service worker (b) web app manifest (c) robots.txt (d) package.json
A news API should stay fresh but still work offline. Best caching strategy? (a) cache first (b) network first (c) cache only (d) network only
Which Core Web Vital replaced FID in 2024? (a) LCP (b) CLS (c) TTFB (d) INP
WCAG's four principles spell: (a) CRUD (b) POUR (c) ACID (d) SOLID
A logged-in student opens the payroll page. Correct status code? (a) 400 (b) 401 (c) 403 (d) 404
Which API style lets the client request exactly the fields it needs? (a) REST (b) GraphQL (c) SOAP (d) webhook
A projector shows a live attendance count and never sends data back. Best choice? (a) WebRTC (b) WebSocket (c) SSE (d) gRPC
Fetching 100 students fires 101 queries. This is the: (a) cold start (b) N+1 problem (c) race condition (d) cache stampede
Which ACID property means a transaction completes fully or not at all? (a) Atomicity (b) Consistency (c) Isolation (d) Durability
You manage only your app code and data; the provider runs OS and runtime. This is: (a) IaaS (b) PaaS (c) SaaS (d) on-premises
Two identical environments, traffic switched at once, instant rollback: (a) rolling (b) canary (c) blue-green (d) recreate
The smallest deployable unit in Kubernetes: (a) node (b) pod (c) service (d) cluster
Under a network partition, CAP says you must choose between: (a) cost and speed (b) consistency and availability (c) SQL and NoSQL (d) latency and throughput
Adding more servers behind a load balancer is: (a) vertical scaling (b) horizontal scaling (c) sharding (d) caching
Which framework draws its own UI with its own rendering engine? (a) React Native (b) Ionic (c) Flutter (d) Cordova
An Ionic + Capacitor app is an example of: (a) native (b) hybrid (c) PWA only (d) Kotlin Multiplatform
Google's recommended Android architecture pattern: (a) MVC (b) MVVM (c) MVP (d) VIPER
Apple's push notification service: (a) FCM (b) APNs (c) SSE (d) MQTT
Android's preferred native language today: (a) Java (b) Dart (c) Kotlin (d) Swift

Answer key: 1 c · 2 b · 3 b · 4 d · 5 b · 6 c · 7 b · 8 c · 9 b · 10 a · 11 b · 12 c · 13 b · 14 b · 15 b · 16 c · 17 b · 18 b · 19 b · 20 c

Sources

Abinguna, C. A. D. (2026). Web Backend Development, APIs, Data Services, and Real-time Applications — MSIT 9 report deck and Word copy (Topic 3).
Samar State University. (2026). MSIT 9 Advanced Web Development and Mobile Technology — Orientation (topic list and weights).
MDN Web Docs — Progressive web apps · web.dev — Core Web Vitals · W3C — WCAG 2.2
Kubernetes documentation — Concepts · NIST SP 800-145 — Definition of Cloud Computing
Android Developers — Guide to app architecture · Flutter documentation · React Native — New Architecture