Module 13: Creating a Facebook Clone
Up to this point the Facebook clone has been living on a mock server boundary. This lesson starts building the real backend behind that boundary, and it does so in the right order: architecture first, then the first entity.
The four-layer split in the lesson is still a strong way to explain the backend: web-service endpoints at the edge, service classes for business logic, DAO objects for transport, and JPA entities plus repositories for persistence. Even if the exact Spring stack evolves, that separation of concerns remains valuable because it keeps storage, transport, and business rules from collapsing into one class.
The best part of this approach is that it leaves room for change. A service method can later be exposed through a different transport without rewriting the business logic. A storage mechanism can later be swapped without forcing the client contract to change at the same rate. That is the real payoff of the structure, not just aesthetic cleanliness.
The User entity is the right place to begin because almost every feature built so far depends on it. Signup, login, profile rendering, friendships, avatars, and notifications all become easier to reason about once the server has a proper user model.
The discussion of IDs is also one of the more useful backend design points in the course. Exposing sequential numeric primary keys to the client is convenient at first, but it creates obvious problems. UUID-style external IDs make much more sense for a public-facing system where client-visible identifiers should not invite trivial enumeration.
The client and server user models are deliberately similar, and that is good. They represent the same domain concept. The server version can still carry extra concerns such as password hashing and security token handling, but the basic overlap is a strength, not a problem.