Thefacebook 2004

Problem

A question on X stuck with me: no documentation, no tutorials, no AI - how did people build products like Facebook in 2004? Modern frameworks are useful, but they hide the system underneath. I wanted to see the real pieces: browser requests, cookies, authentication, relational data, SQL joins, file uploads, CORS, deployment, and the edge cases that connect them.

Approach

Rebuild the spirit of an early university network with as few abstractions as possible. The browser gets plain HTML, CSS and JavaScript. The server is a small FastAPI application with a router layer, a service layer holding business logic and raw SQL, and PostgreSQL underneath. No ORM, no component framework, no state library.

The core journey

1. 01University admission generates a student identity
2. 02Email plus one-time registration code
3. 03Account creation claims the student record
4. 04Password hashed with Argon2
5. 05SHA-256 of the session token stored in PostgreSQL
6. 06Raw token returned only as an HttpOnly cookie
7. 07Profile build, people search, friend graph, courses

Registration is tied to real data, not a form

Registration is not a plain insert-a-user endpoint. A request verifies the student record and the one-time code before anything is written, then marks that student claimed in the same transaction.

The session token is never stored in plaintext. PostgreSQL holds SHA-256 of the token; the raw value only ever exists in an HttpOnly cookie on the client.

A social graph with real states

Friend requests move through pending, accepted, rejected and removed rather than a boolean. Suggestions are built from university, profile compatibility and mutual friends, which turned into the most interesting SQL in the project.

People search filters on structured profile data - name, university, status, relationship, interests - instead of a single text match.

A deliberately small backend

The request path stays flat: router handles HTTP, validation and response status; the service layer holds business logic and SQL; PostgreSQL on Neon stores everything except profile images, which go to Cloudinary.

Outcome

Shipped and deployed. Students can get a university identity, register, build a profile, search the directory, manage friendships and join courses. It is the project where raw SQL and direct JavaScript-to-FastAPI wiring stopped being theory.

What it taught me

• An ORM is a convenience, not a requirement - writing joins by hand changed how I model data.
• Session handling has more edge cases than any tutorial implies.
• Removing the framework made the failure modes visible instead of absorbed.