NightBloom GO vrooom.

Yes, cheesy, punny, stupid title, but it will all make sense in a moment

Hey Everyone! Been a while since we published something on our blog. Today, we are announcing a MAJOR update to NightBloom, our downloads platform.

Before we get into the technical stuff, a bit of backstory.

NightBloom was originally created, as a replacement for our Jenkins downloads, with the goal of making it easier for users to find test builds. It was created during the Alpha testing of both CraterLib and Simple Discord Link, because we noticed users having trouble finding the correct downloads for their platform. So, in as little as 24 hours, NightBloom was born. Originally named FDD Snapshots.

The first version of NightBloom, as built in the 24 hours

The platform was built purely to help our users find downloads a lot faster, and to keep old builds around practically forever, compared to them getting wiped every couple of months from Jenkins.

Due to the fact that the platform was built so quickly, the code base wasn’t the best. It was held together with duct tape and coffee. Fast forward 2 years later, and that code is really starting to break down.

Why was it an issue, and why the change?

While NightBloom serves its purpose, it has 1 major issue. Performance. The core of NightBloom, namely the backend is written in TypeScript, powered by NodeJS. For the database, we use PostgreSQL.

Both of these are great by themselves, until they aren’t. In 2024, we let the first non-fdd person, publish their projects on NightBloom. CDAGaming (developer of the popular CraftPresence Mod) saw our platform and became interested in. Knowing CDA and having worked with him quite a bit in the past, we allowed him in.

Initially, all was fine. The platform could handle the load, and the amount of data, but as the platform grew (traffic wise, and data wise), that statement became a lie.

The biggest place this performance hit can be seen, is when accessing the home page. The API query to load the home page, takes a whopping 2.5 - 3 seconds to complete. Normally, this wouldn’t be an issue. It’s a bit longer to wait, so what’s the big deal? Well, this route also comes with a nasty side effect.

Every time someone would visit the home page, in addition to waiting that 2.5-3 seconds, the server CPU load would also spike. Jumping from 0% to as high as 30% (this is on an 8-core Ryzen CPU). By itself still not really a big deal, but imagine multiple users hitting the home page at the same time…. Yeah, then that 30% CPU usage becomes 100%. During this, the memory usage of the backend would also spike from a couple of MB, to GB’s.

The cause of this, is the way Mikro-ORM, the framework we used to handle the database stuff handled queries to the database. It would perform anywhere from 3-12 queries each time the home page was loaded. While all that was going on, the NodeJS server would also hang, waiting for the task to complete. Not entirely the fault of the framework, but it played a huge part in it.

So how was this fixed?

We rewrote it in Rust… Kidding. We actually rewrote the entire backend in GO. Why GO? It’s lightweight, has a huge community behind it and it just works.

Before the rust fans stone me, yes rust would probably be better than this, but I am comfortable with GO, and wanted to challenge myself as well.

In doing so, not only did we see a MASSIVE performance improvement, but the overall stability of the backend also got better.

For the technical people, here are the before and after results

Route

Before

After

Home Page (projects)

2.5-3 seconds, with heavy CPU load

75ms with hardly any CPU load

Single Project

400-700ms

8-12ms

Project Files

80-120ms

10-15ms

Single File

30-50ms

3-8ms

While most of these numbers aren’t that impressive, it’s an overall performance increase of 44x.

Rewriting the backend in GO also means we can handle a larger number of users, with less resources, and if we ever needed to scale up, we could easily do that.

The take away?

Even if you never intend for your projects to be something bigger, something more, take the time to do it right.

The poor design and tech choices we made took its toll a lot sooner than expected, and slowed down whatever potential growth the platform had.

FAQ

  • Q: What platform is NightBloom built on?

  • A: Nothing. It’s completely designed, coded and built from scratch. The UI of the platform does take inspiration from both CurseForge and Modrinth. I chose the things I liked best about both platforms, and based my ideas on that.

  • Q: Why build it from scratch? Why not just self host modrinth?

  • A: That was an idea that was explored. As well as other platforms like Hangar from PaperMC. Ultimately, all of these platforms were purpose built for what they are used for. Modrinth at the time also grew to a point, where self hosting it was not feasible. Building the platform from scratch, allows us for full control and to build it according to our needs.

  • Q: Are you planning to challenge CurseForge and Modrinth, causing more community split?

  • A: Nope. NightBloom is just a hosting service, intended for unstable, test projects and builds, that aren’t suitable for platforms like CurseForge and Modrinth. While we do publish actual releases of projects on the platform, it’s simply to give users an alternative source of downloads, and a place to have a full backup of all our projects.

  • Q: Can other authors publish on the platform?

  • A: Yes and No. While we do allow other authors to publish their projects on the platform, it’s entirely up to us. Factors that decide who we allow include how well known you are, the size of your projects, and the type of content you create. If we feel like allowing you, we will approach you. Authors are still free to ask for access, but that does not mean you will be allowed.