How mithunkrishh/bright-tech-solutions works
1. High-level shape
- This repo is a multi-page company website with a static frontend and a small Node.js/Express backend.
- The current architecture is mostly presentation-driven: pages, shared styling, shared client-side behavior, and a minimal API layer.
2. Frontend composition
- Everything under client/ is the user-facing site.
- The site is split into separate HTML pages such as index.html, website.html, services.html, admissions.html, career-guidance.html, college-finder.html, and abacus.html.
- This suggests a traditional multi-page website rather than a SPA.
3. Shared presentation layer
- client/css/style.css is the central shared stylesheet for the whole site.
- client/assets/ contains icons and images used across pages.
- These shared assets form the common visual system for all sections of the site.
4. Client-side behavior
- client/js/main.js appears to hold the shared browser-side logic.
- Based on the file layout, this is likely where global interactions, navigation behavior, and any page-specific enhancements are implemented.
5. Local data used by the frontend
- client/data/colleges.json is the only structured data file visible in the tree.
- This indicates at least one client-side feature, likely the college-finder page, reads from local JSON rather than a backend database.
6. Backend role
- server/ contains an Express application that exposes API endpoints.
- server/index.js is the entry point and likely sets up the HTTP server, middleware, and route registration.
7. API surface
- The only documented endpoint in the README is GET /api/v1/health.
- server/routes/apiRoutes.js and server/controllers/healthController.js implement this health check, which is typically used for uptime checks, deployment validation, or monitoring.
8. Cross-cutting server concerns
- server/middleware/rateLimiter.js adds request throttling.
- server/middleware/notFound.js handles unmatched routes.
- server/middleware/errorHandler.js centralizes API error responses.
- These are standard Express boundaries around the controller layer.
9. Subsystem boundaries
- The frontend and backend are loosely coupled: the frontend is mostly static content, while the backend currently provides only a small API.
- There is no visible server-side rendering or shared application state between the two.
10. Data/storage implications
- The README mentions MongoDB, but there is no database layer, model directory, or connection code in the tree.
- So, from the repository structure alone, the practical runtime architecture is static content + small Express API, with local JSON data on the client side.
11. Runtime and dev setup
- package.json/npm run dev starts the Node/Express server on port 5000.
- The app is meant to be opened at http://localhost:5000, implying the server either serves the client files or fronts them during development.
12. What to show in an architecture diagram
- Draw a browser/client tier containing the HTML pages, shared CSS/JS, assets, and local college JSON.
- Draw a separate Express server tier containing the API routes, health controller, and middleware.
- Show the client reading static files locally, and the browser hitting /api/v1/health for backend verification.
Main entry points: index.js Server entry · college-finder.html College finder · main.js Shared script · apiRoutes.js API routes
Components 12
Client tier
Static multi-page website and shared browser-side resources.
- Site pages · Multi-page company site: home and content pages under client/.
- College finder · Page that likely consumes local college data for search or filtering.
client/college-finder.html - Shared styles · Central stylesheet for the whole site.
client/css/style.css - Shared script · Global client-side behavior and page enhancements.
client/js/main.js - Media assets · Shared visual assets used across pages.
client/assets - College data · Local structured data used by the frontend.
client/data/colleges.json
Server tier
Small Express API and cross-cutting middleware.
- Server entry · Node.js entry point that starts the HTTP server and wires middleware/routes.
server/index.js - API routes · Express route registration for the API surface.
server/routes/apiRoutes.js - Health check · Implements GET /api/v1/health.
server/controllers/healthController.js - Rate limiter · Throttles incoming requests.
server/middleware/rateLimiter.js - Not found · Handles unmatched routes.
server/middleware/notFound.js - Error handler · Centralized API error responses.
server/middleware/errorHandler.js
Connections 12
- Site pages → Shared styles: uses · All pages share the central stylesheet.
- Site pages → Shared script: loads · Pages load common browser-side logic.
- Site pages → Media assets: embeds · Pages reference shared icons and images.
- College finder → College data: reads · Finder page uses local college JSON.
- College finder → Shared script: loads · Finder page uses shared client behavior.
- College finder → Shared styles: uses · Finder page uses the common stylesheet.
- Server entry → API routes: mounts · Main server registers API routes.
- Server entry → Rate limiter: applies · Server installs request throttling.
- Server entry → Not found: applies · Server installs unmatched-route handling.
- Server entry → Error handler: applies · Server installs centralized error handling.
- API routes → Health check: invokes · Route module forwards health requests to the controller.
- Shared script → Health check: checks · Client-side runtime can call the health endpoint for verification.