Tuiter
Twitter-style social app · two-repo course build
Runs in your browser. Nothing is sent anywhere; refresh and the feed resets. Ctrl+Enter also posts.
@maya_runs2h
Long run done before sunrise. The river path was all fog and herons today.
@dev_tomas5h
Shipped the fix, broke two tests, learned a lesson about mocking the clock.
@quiet_quinn9h
Reread my favorite novel and the ending changed because I did.
Synthetic preview. The three seeded tuits and accounts are fictional; no real data, and nothing leaves this page. The audited course build pairs static HTML screens with an Express API doing CRUD on /api/tuits over seeded in-memory arrays; this mini feed keeps the same contract (280-character tuits, like toggles, newest first) in browser memory instead.
Synthetic preview. Runs in your browser; nothing is sent anywhere.
Tuiter is the staple full-stack build from a web-development course, split across two public repos that show each layer plainly. The linked client repo is a Create React App shell whose implemented UI is fourteen hand-coded static HTML screens of a Twitter-style interface: home, explore, notifications, messages, bookmarks, lists, profile and edit-profile, plus the tuit, reply, retuit, like and share flows. Its README points to the companion Node/Express server repo, a REST API with full CRUD on tuits (POST/GET/PUT/DELETE on /api/tuits), a users resource split into controller and DAO layers, and session-based auth (register with duplicate-username rejection, login, profile, logout) on express-session, with credentialed CORS and secure SameSite=None cookies configured for cross-origin deployment. Persistence is seeded in-memory arrays, the course's stepping stone before a database, and the card claims exactly that: REST conventions, a controller/DAO split, and session-based auth on express-session (the login lookup bug is called out below).
- HTML/CSS
- JavaScript
- Create React App
- Node/Express
- express-session
- REST API
- Client
- CRA shell + 14 static HTML screens
- Server
- Express CRUD + session auth (in-memory)
What I'd improve
The candid gap is the React layer: the client repo's src is still the untouched CRA scaffold, with the actual UI living as static HTML, so the next step is porting those screens into real React components wired to the API. After that, swap the seeded in-memory arrays for a real database, fix the broken credential lookup in the users DAO (users.findIndex.find is not a function), and move the hard-coded session secret out of source into the environment.