Introduction
Welcome to Project Spawnpoint, the website I am currently working on. It’s a complete rework of my old homepage, which has been long overdue for an upgrade. While the previous version served its purpose, it was built with PHP and lacked scalability, which became more and more of a pain as I continued to add projects.
This new version is built with Node.js and Express.js, allowing for a much more scalable approach. The main reason for this rework was to make the website adaptable for future growth while also introducing an admin panel that enables me to manage projects with ease. Now, I can add new projects and update information without diving into the code every time. All the data is saved persistently, making it far more efficient to handle.
Intention
In contrast to Spawnpoint, the old website forced me to manually edit the code every time I wanted to add a new project, which was far from ideal. While it worked in the early stages, it quickly became frustrating and time-consuming. This new system streamlines the process and gives me the flexibility to scale as needed, without having to worry about the technical limitations of the past, thanks to the implementation of an admin panel.
Implementation Details
Authorization
As this web app is not intended to provide access to multiple users, password authorization has been chosen for the admin panel. On successful login, a server-side generated token is associated with the user (saved as a cookie). On each HTTP request to the admin panel, the cookie is verified to ensure it is still valid to prevent unauthorized access.
Front- & Back-End Separation
Also, different from the previous iteration of this website, which was a monolith made entirely out of PHP, HTML, and CSS, this project has a proper backend and an independent front-end. The front-end has been implemented with the templating language Pug, which is translated into HTML.
Persistence
All projects are saved in a JSON database. JSON was chosen because it is a lot less performance- and storage-demanding than a relational database, as the only overhead is ensuring data integrity. Since the points of failure are manageable (editing and creating projects), this is not a significant issue.
A database cache has also been implemented, which caches all results accessed by users for a set amount of time. The downside is that changes may only be visible after the cache expires, but the upside is that frequent reading of the file is prevented. Since changes aren’t expected often, this is a net positive.
Flexibility
Each project can have its own description, which supports markdown when editing in the admin panel and renders accordingly when visited by users. This was made to allow the admin (me) to create very flexible descriptions of projects and dynamically include pictures and code blocks.
Markdown Rendering
Table of Content
From the markdown headers a table of content is being generated
Blog Posts (discarded)
Initially, I planned to have a blog for each project where new posts could be added and existing ones edited through the admin panel. However, I discarded this idea because it wouldn’t provide much additional benefit over the description field (other than perhaps separating blog posts or comments). Updates can still be added in the current description and visualized with markdown, for example:
Update: 2024 September 15th
Today I decided not to work on this project and went shopping.
ToDos
- make Contact Page more beautiful
- Redesign visually
- Admin Page for About Page
- Optionally a bats.li/docs/project/id for more indepth documentation of each project.
Written: 2024-09-14