this was a smaller project, but it was useful because it stripped things down. the brief was basically: build a simple rest api in php, then make the frontend talk to it without hiding behind a framework.
what was in it
- php rest api
- mariadb
- vanilla javascript frontend
- plain css for the ui
- login and registration flow
- project cards with create, edit, delete, and detail views
- language filtering with a many-to-many relation
that made it a good learning project. there was nowhere to hide. requests, data flow, database access, and frontend state all had to be understood more directly.
what the structure taught me
the project was split pretty clearly into a few folders: database connection, dashboard logic, login handling, and the data endpoints. on the javascript side there were separate files for services, rendering, cards, tabs, validation, and utility functions.
that sounds simple now, but at the time it was useful because it forced me to think in layers:
- php for the backend endpoints and session logic
- sql for the data model
- javascript for the api calls and rendering
- html/scss for the actual interface
it was one of the first projects where the frontend/backend boundary started to feel concrete instead of abstract. and because no framework was allowed, it was also one of the moments where i really started to understand plain javascript better instead of hiding behind library structure.
backend and data model
the sql side had four main tables:
usersprojectslanguagesprojects_languages_relation
so even though the project was still small, it already had a proper many-to-many relation for assigning languages to projects.
that part matters because it was not just “store everything in one table and hope for the best”. it already pushed me toward thinking about data structures, relations, and what the api would actually need to return.
what made it more than a school toy
there was also a real login flow with php sessions, project cards, modal editing, validation, and separate api services for the crud calls. we even documented parts of the javascript with jsdocs and generated html docs from that.
the whole thing was still early, but it already had enough moving parts that structure mattered:
- authentication
- crud endpoints
- card rendering
- filtering by languages
- modal interactions
- client-side validation
that is why i still keep it here. it was one of those projects where the stack was basic, but the learning was very real.
why keep it here
because it still marks an important step: understanding the split between frontend and backend well enough that later tools felt like an advantage instead of magic.