Replace Mock Boundaries with Application Boundaries

The starter’s mock data is useful for building the interface, but we do not want mock objects scattered throughout the application forever.

Before introducing PostgreSQL, make the boundary between UI and data explicit.

Task

Identify the places where Readly currently consumes mock data and organize those inputs so the later database implementation can replace them without rewriting the entire UI.

The Boundary We Want

The application should move conceptually from:

UI component
   ↓
hard-coded mock object

toward:

UI component
   ↓
application data boundary
   ↓
database

For example:

Mock books
    ↓
Book data
    ↓
PostgreSQL later

and:

Mock progress
    ↓
ReadingProgress data
    ↓
PostgreSQL later

The same principle will apply to:

• bookmarks
• highlights
• notes
• reader preferences

Implementation

Use the existing project structure to keep temporary mock data in a deliberate location.

Do not build the database yet.

Do not create fake API routes just to make the architecture look complete.

The goal is simply to make the existing UI consume mock data through a clear boundary.

Test

Run the application and verify that the visible product has not changed.

Check:

• Home
• My Library
• Reader
• Highlights
• Notes

The mock data should still render.

Checkpoint

You are done when the UI still behaves as before, but you can clearly point to:

temporary mock data
        ↓
application data boundary
        ↓
future persistent implementation

That is the handoff to Module 2.

Module Complete

At this point you have not added a database yet.

You have done something more important for the next step: you have a clean application foundation from which the real data layer can grow.

In Module 2, we replace the first part of the mock foundation with PostgreSQL and Prisma.