shivam2-tech/fullstack-learning-journey

This repository is a curated collection of independent learning projects, not a single unified application. The main architectural boundary is the folder-level separation: each subproject has its own entry point, assets, and runtime assumptions, and there is very little shared code across projects.

1. Top-level structure as progression

The repo is organized by learning stage: frontend basics, API-driven apps, DOM exercises, Node.js backend exercises, and React apps. A diagram should show these as parallel tracks rather than one dependency chain.

2. Static browser apps

The 01-api-projects, 02-mini-projects, and 03-dom-projects folders are mostly plain HTML/CSS/JavaScript apps. Each one runs directly in the browser, with index.html/script.js/style.css or similar as the whole application boundary.

3. API consumer apps

The API projects include Pokémon, Weather, and Movie apps. Their core flow is:

browser UI → JavaScript fetch logic → external public API → render results back into the DOM.

These projects are important because they introduce asynchronous data loading and API response handling, but they do not have their own backend.

4. Local state and browser persistence

Several mini-projects, especially to-do list variants, rely on browser-side state and likely localStorage for persistence. In architecture terms, the “database” is the browser storage layer, not an external service.

5. DOM-interaction exercises

The 03-dom-projects folder is centered on event handling and UI updates: clock, counter, and calculator. These are client-only apps with direct user interaction loops:

user event → JS state update → DOM re-render/update.

6. Node.js fundamentals

The 04-Node js/01-Basic, 02-file-system, 03-Modules, and 04-npm folders are backend/Node practice modules. They demonstrate server-side JavaScript primitives, filesystem access, module exports/imports, and package management, but they are not a single product service.

7. Express REST API layer

The 04-Node js/05-express-basics and 04-Node js/Movie API folders introduce an HTTP server boundary. Here the flow becomes:

client request → Express route → middleware/handler → JSON response.

This is the first real server-side API layer in the repo.

8. In-memory API service

04-Node js/Movie API uses a file-based data module (data/movies.js) rather than a database. The architecture is a classic REST API with route handlers and middleware for logging, validation, and error handling, but persistence is in-memory/static data.

9. MongoDB-backed backend apps

04-Node js/Movie-API-MongoDB and 04-Node js/Notes-API-MongoDB add a real persistence layer through MongoDB. These projects have a clearer backend architecture:

Express routes → middleware → Mongoose models → MongoDB.

Authentication is introduced in these versions through dedicated auth middleware and auth routes.

10. Backend cross-cutting concerns

Both MongoDB-backed services include middleware for auth, validation, logging, and error handling. These are shared architectural concerns that sit between incoming requests and the domain models/routes.

11. React frontend apps

The 05-React folder contains separate Vite-based React projects: health tracker, score keeper, to-do list, and username preview. Each has its own src/main.jsx, App.jsx, and styling entry point, so they should be diagrammed as standalone SPAs.

12. React component boundaries

These React projects are small component trees rather than multi-page systems. For example, score-keeper includes a reusable Player component, while others are mostly single-root App apps managing local component state.

13. Build/runtime tooling

The repo mixes runtime models: browser-only static files, Node.js scripts/servers, and Vite-bundled React apps. Package manifests and lockfiles appear only where npm-based tooling is needed, while plain HTML/JS exercises do not require a build step.

14. Overall architectural story

The repository is best represented as a learning portfolio of isolated apps that progressively evolve from:

static UI → DOM interaction → public API consumption → Node/Express servers → database-backed REST APIs → React component apps.

There is no central shared backend or monorepo orchestration layer.