A five-person course project that turned a public dataset into an explorable web product. The work covered the complete request path: interface states, backend services, relational storage and the integration points that keep those layers in sync.
Course project
Full-stack · SQL · Team of 5
Data-Driven Web Application
A collaborative full-stack application built around a public dataset, spanning interface work, service integration and relational data modeling.
JavaScriptHTML / CSSSQLREST APIsGit
Architecture view
End-to-end request path
The application turns a user action into a validated query and returns structured data to the interface.
01InterfaceInput · states · views
02API routeValidate · authorize
03ServiceApplication logic
04SQL layerSchema · queries
05ResponseStructured UI data
01 / ContextWhat I built
What I built
and why.
The technical challenge was less about rendering a single screen and more about agreeing on stable contracts across a team. Changes to the data model affected API responses and interface behavior, so coordination and clear boundaries mattered.
We shaped the dataset into a relational schema, exposed the required operations through a service layer and built the interface around predictable loading, empty and result states. Git-based collaboration and small integration checkpoints kept parallel work manageable.
02 / Engineering
Key decisions
The choices that shaped the system—not only the technologies that appear in it.
Design from the data contract
The schema and API response shapes were defined early so frontend and backend work could progress against the same assumptions.
Keep responsibilities visible
Interface, service and persistence concerns were separated to make changes easier to trace across the request lifecycle.
Integrate continuously
Smaller checkpoints reduced the cost of merging five contributors' work near the end of the project.
Technical toolkit
Built with
JavaScriptHTML / CSSSQLREST APIsGit
03 / Reflection
What the project taught me
- Team velocity depends on shared interfaces as much as individual implementation speed.
- A relational model should reflect the questions the product needs to answer.
- Loading, error and empty states are part of the application—not edge-case polish.
This page uses a system diagram to document the current technical structure. Product screenshots and experiment outputs can be added here as each project evolves.