Module 13: Creating a Facebook Clone
Once the client data model exists, the next architectural step is to stop letting the UI imagine that data comes from nowhere. Even if the real backend is not ready yet, the app should already talk to an abstraction that looks like a server boundary.
That is what this lesson gets right. The mock ServerAPI is not just fake data for convenience. It is a way to force the UI to depend on application-level operations instead of hard-coded inline sample objects.
That decision pays off later because the UI can be written once against methods such as “fetch timeline posts” or “get current user,” and the implementation behind those methods can later switch from mock data to real network calls without rewriting every screen.
The mock data itself is also more intentional than a typical placeholder. It includes realistic users, timestamps, avatars, and simple relationships such as friends and suggestions. That makes the upcoming feed and friends UI feel like they are attached to a real product even before the server work is done.
The utility methods added alongside this abstraction are part of the same story. Formatting “just now” style timestamps and creating reusable separators may feel small, but they keep repeated UI logic out of the container classes where it would otherwise start to pile up.
This is exactly the right stage to introduce a server boundary. The app is complex enough to need one, but still small enough that putting it in place now will simplify everything that follows.