Openbooru
Openbooru was the first major project I ever undertook as a developer. I worked on it for 1 to 2 years, releasing 9 major updates. In that time it taught me so much by allowing me to learn lots of new technologies. It also taught me about managing structure and preventing coupling in a large project.
Technologies
I designed the site to be made of two parts, the API and the Frontend. The API is a FastAPI Python REST API, whilst the frontend was a Next.js app before migrating to Sveltekit.
The frontend was written in Python using FastAPI. I originally used Sqlite then Neo4j as the database, before finally settling on MongoDB. FFMPeG for encoding.
I used it to learn Javascript frameworks. I used Next.js and then Svelte in order to build the site. It was the first project I made using either of those frameworks, looking back I made many common mistakes that led to some untraceable bugs.
Using FastAPI on this project was extremely enjoyable. If you ever have to do make a HTTP api in Python, I highly recommend it. It does validation in inputs, generates OpenAPI docs and supports Pydantic out of the box. It’s an extremely powerful and useful library.
Switching technologies often is a terrible idea for actually finishing the project. But it didn’t really matter to me, I was more focused on learning during this experience than actually making a viable product.
Successes
I made extensive use of testing in the project, which made it really easy to test new features. Especially the features which had multiple supported modules, such as storage on AWS vs local.
I made the encoding module to be extremely extensible, supporting image,animation, and videos, multiple filetypes targets, converting videos into gifs and vice-verse. After I finished the project, I split it off into it’s own project: Mediaify.
Failures
One of my main failures with this project is trying to support a huge amount of customisation. This made it extremely hard to test and develop around, as I had to support a large number of combinations when I could have focused on a single standard and branched off from there. An example would be the customisable permissions, I had to design every feature to be toggleable depending on what permissions the current user had. Even basic features like searching had to have some sort of toggle to support this.
I failed to use the SSR features of Next.js and Sveltekit, instead relying on client loading. This meant the performance and user exeperience was quite lacking.
If I were to do this project today, I would rely on Astro for content loading and keep the API as a seperate server, but make it private. Having a private API means I can make endpoints tailored for individual pages so I only have to make a single HTTP request, whilst keeping the applications seperate.
Additionally, the whole project was designed to be incredibly extensible. You could customise what permissions each user role had, even creating custom ones. You could customise how posts are encoded including how many smaller images were made.
This turned out to be another major mistake I made with the project, it became impossible to manage this much variability
Management
One of the things I did on this project was proper versioned updates. I named each update after an element on the periodic table, starting with Hydrogen I got all the way to Neon before giving up. I regularly posted on a twitter account
I also posted about the updates on Twitter, trying to build support for the project online.
Although predicatbly, it only gained minimal attention.
Links
Sadly, the site is no longer up due to server costs :(