2024/Fullstack/course

Katalog Restoran PWA

This delivery focused on reliability under unstable network conditions by combining Workbox-powered caching, installability, and repeatable Jest plus CodeceptJS checks.

Domain
Fullstack
Role
Frontend Engineer
Output
Web App
Category
PWA Engineering
Project Framing

A source-backed case study built for recruiter review

This reading path makes the problem choice, evidence quality, user framing, execution decisions, and proof trail visible without overstating what the sources support.

Project Type
course

IDCamp intermediate project that turned a restaurant catalog into an installable offline-first PWA with service-worker caching, performance optimization, and automated testing.

Orientation
Tech

Improved user-experience reliability through offline support and repeatable quality checks.

Core Stack
Vanilla JavaScript · Webpack · Workbox · Jest

Modular JavaScript frontend bundled with Webpack, Workbox service-worker layer, and test pipeline for regressions.

Why This Problem Mattered

Problem framing before execution

The case-study layer starts with why this problem was selected and how the context justified investment.

Problem Framing Map

Issue

Content-heavy web apps lose reliability when unstable networks, caching strategy, and offline behavior are not treated as first-class product concerns.

Context

Katalog Restoran PWA was built as an intermediate frontend project where installability, caching, and test-backed reliability mattered as much as the restaurant catalog UI itself.

Why Selected

It is a strong Wave 5 candidate because it adds explicit offline-first and PWA-delivery thinking to the portfolio with a clear source-backed implementation story.

Problem statement

The content-heavy web app needed resilient behavior under unstable network conditions.

Solution thesis

Implemented service-worker caching, installability, performance optimization, and automated quality checks.

Research and Evidence

What supports the narrative

Evidence is surfaced with its source type and credibility note so the recruiter can quickly see what is directly backed versus intentionally constrained.

Offline-first scope
local

The project explicitly combines service-worker caching, installability, and reliability under unstable network conditions.

Credibility: Backed by the detail intro, problem statement, architecture, and visual snapshot already present in the project record.
Quality guardrails
local

Unit and end-to-end test layers are documented as part of the product baseline.

Credibility: Supported by the metrics, responsibilities, stack decisions, and visual evidence in the current record.

Credibility Notes

  • The project is framed as an offline-first PWA engineering artefact, not as a scaled restaurant platform with verified user metrics.
  • No retention, install-rate, or production traffic claim is added beyond the documented technical evidence.
Who The User Was

User framing stays explicit

When formal research artefacts are not available, the page still explains who the work served and why that user framing is justified by the existing sources.

Primary user
Users who need a restaurant-browsing experience that remains usable even under unstable connectivity.

The strongest product value comes from resilience and installable access rather than from broad domain complexity.

Reviewer stakeholder
Reviewers assessing whether frontend reliability is supported by real caching, PWA, and test discipline.

The project’s clearest proof points are its service-worker strategy and repeatable validation layers.

Decision Flow

How design thinking translated into decisions

The goal is to show the trace from research and insight to concrete product or system decisions, then to the outcomes those decisions supported.

Design Thinking Flow

Each step keeps the movement from evidence to action explicit before the rationale expands it.

  1. Step 1
    Reliability-first framing

    Defined the app around resilient access under unstable networks rather than only visible feature screens.

    Signal: Offline support and installability became the core product promise.
  2. Step 2
    Caching and validation pairing

    Connected Workbox-powered caching with unit and e2e checks so reliability remained reviewable.

    Signal: Performance and correctness were treated as one delivery surface.
  3. Step 3
    PWA-focused packaging

    Turned the restaurant catalog into an installable app experience rather than a standard browser-only site.

    Signal: The project reads as a product-quality upgrade, not only a frontend refactor.

Decision Rationale

Each decision keeps the path from insight to execution visible before ending on the outcome signal.

Service-worker baseline
Insight

Restaurant catalog usability drops sharply when connectivity becomes unreliable.

Decision

Used service-worker caching and installability as core delivery requirements.

Outcome

The app stays more resilient and product-complete under weaker network conditions.

Tests as reliability proof
Insight

PWA behavior is harder to trust when caching and interaction changes are not protected by repeatable checks.

Decision

Combined Jest and CodeceptJS validation layers with the PWA delivery flow.

Outcome

The project demonstrates frontend reliability thinking beyond visible UI polish.

Solution and System Execution

Execution choices and delivery details

This section preserves the technical and operational substance: architecture, responsibilities, trade-offs, and implementation quality signals.

System Design

Modular JavaScript frontend bundled with Webpack, Workbox service-worker layer, and test pipeline for regressions.

Source-backed Impact

Improved user-experience reliability through offline support and repeatable quality checks.

Responsibilities

  • Implemented PWA enhancement strategy
  • Built caching and offline behavior
  • Set up and maintained testing modules

Stack Decisions

  • Used Workbox to accelerate robust caching implementation
  • Used test tooling to protect feature refactors

Trade-offs

  • Increased build complexity in exchange for reliability gains

Challenges

  • Balancing caching freshness vs offline resilience
Execution Visuals

Architecture and outcome snapshot

This visual layer keeps execution readable: how the system or delivery flow was structured and which source-backed outcomes mattered most.

Execution Flow

  1. Step 1
    PWA Foundation

    Added service-worker and caching behavior to keep the app usable in unstable network conditions.

    Signal: Offline-first access and installability became core delivery goals
  2. Step 2
    Quality Guardrail

    Combined unit and end-to-end tests to protect core user journeys during refactors.

    Signal: Jest and CodeceptJS used as repeatable validation layers
  3. Step 3
    Performance Optimization

    Optimized bundle and asset delivery with build tooling and caching strategy improvements.

    Signal: Faster repeat loads supported by Webpack + Workbox pipeline

Outcome Snapshot

  • Core Capability
    Installable offline-first PWA

    Service-worker caching keeps app shell available

  • Quality Scope
    Unit + E2E test coverage

    Automated checks back key browsing and interaction flows

  • Performance Signal
    Optimized asset delivery

    Bundling and caching improvements reduce reload friction

Outcomes and Proof

What was delivered and what can be verified

Outcome claims remain conservative and source-backed, while proof records and recruiter-safe links surface the strongest verification trail available.

Validation Signals

  • PWA capability with offline accessibility is documented in the project record.
  • Automated test integration using Jest and CodeceptJS is preserved as part of the evidence surface.

Source-backed Outcomes

  • PWA capability with offline accessibility
  • Automated test integration using Jest and CodeceptJS
Retrospective and Limits

What the project proves, and what it does not

Strong case studies show both what was learned and where the current evidence stops.

Retrospective

A follow-up should add runtime monitoring for cache-hit quality and stale-content handling.

Evidence Limits

  • Current sources do not support production install metrics, real user behavior, or monitored cache-performance outcomes.
  • The project should remain framed as offline-first PWA engineering and reliability proof.

Lessons

  • PWA reliability requires deliberate cache invalidation strategy