Mid year update

When I wrote our last blog post early this year, my intention was to write them monthly moving forward. As you may have noticed, that hasn’t exactly happened! Whenever I sit down at my computer to work on Apollo, I inevitably go straight to the code as I want to bring you guys new features. Moving forward, I might aim for an update at least once a quarter. I’d love to do monthly, but I know that I’d likely disappoint!

The year so far

The last six months have been about getting Apollo to a state where I’m no longer embarrassed about any areas of the app. Apollo has worked, and continues to work well for most use cases, but there were a few areas that I wanted to improve, as having to shrug my shoulders when users asked certain questions felt really bad.

Recurring events

The first step was to completely rewrite our recurring events system. The old recurring events module was fairly naive in its implementation, and was limited to a recurrence pattern of how many days between each event. This worked fine for daily and weekly events, but anything beyond that became quite tricky.

It was becoming quite common for users to ask for the ability to create monthly events, events on certain days of the week, or events on certain days of the month. Or in regards to post time, users wanted some freedom, as previously events would always post 2 hours after the previous one. Each time the answer was a “No, sorry that’s not possible”, and I knew there was no way for it to be possible without a complete rewrite.

The new system uses the iCal standard for a recurrence rule, which lets us allow for theoretically any recurrence pattern. The only limit right now is building out a UI to capture new recurrence patterns, but in theory I can shove any recurrence pattern into the database and Apollo will make it work. It was tricky to port all of the old recurring events to the new system without breaking anything, but we managed it!

Scaling

Next I had to take on some surprise work in scaling Apollo. Most large Discord bots don’t run as a single process; they run as a collection of shards where each group of shards is served by a single server (computer).

We were getting to the point where Apollo was becoming too slow under peak load. I didn’t realize we were as close to that point as we were, so I had to pull somewhat of an all nighter to get things back and working. Essentially I had to split the app in two, which was a bit tricky for a few technical reasons. We cache quite a bit of data for guild and channel information, and inevitably you need information for a guild or channel that is in the cache on another worker.

It took a few days to iron out all the kinks, but we managed it! Currently each worker is serving approximately 45,000 servers, though we’re now prepped to easily add a third worker when the time comes.

Optional event channels

This was a big one. One of people’s biggest gripes with Apollo was that it was required to let Apollo create a text channel, and events could only be posted in that channel. It was brought up several times a week, and when Discord made some tweaks to permissions, it got even harder to consistently create text channels without permission errors.

We landed on adding the option to create events outside of an event channel, while still retaining event channels in their prior form, as being able to sort and purge event channels was something I’d included from day one, and highly value to this day.

This was far from a glamorous release, but it has made providing support much easier!

Edit optimizations

This was another big one to address quite a few “feels bad” moments. Simply put, editing recurring events was hard. Even viewing recurring events on your server wasn’t possible. The only way to edit a recurring event was to modify an existing event in the series, otherwise you were out of luck.

Allowing the option to edit a series was far far from glamorous, and ended up taking quite a long time to complete. I don’t think a lot of folks were super happy with the release, as they wanted something flashier, but it was a huge win for me, as having to tell people that they needed to wait for the next event to be posted in order to modify it was straight up embarrassing.

Looking forward

There were some actual feature releases that were pretty nice thrown into the mix, but I wanted to highlight some of the “grunt” work that took place this year to help get Apollo to a state where I’m reasonably happy.

That’s all fine and well, but what’s next? My focus for the remaining half of the year is to get Apollo to a more mature state.

Localization

As some of you may have seen, work is currently ongoing to localize Apollo into different languages. We’ve made good progress on translations (thank you to those who have contributed), as well as good progress on pushing translations through the app.

There’s still a good chunk of work to go, as every place where we translate a message needs to be updated such that we have a reference to the locale used to translate it. Currently the event creation prompt is close to being finished, with French being fully supported. In the coming days I’d like to turn on Italian and German as well.

Documentation

Another task I’m working on that isn’t dev related, is to do a better job documenting how Apollo works. Currently we have next to no documentation online; it’s all either in the help command or on the Apollo Discord.

The goal is to have a much better web presence than we have previously, and to have not only standard command documentation, but a more robust collection of written guides.

Website

I won’t say too much about this, other than I’m working on a complete refresh of the website with a slight rebrand in the process. Stay tuned!

New Discord features

Discord has recently released slash commands and buttons. The library we use doesn’t yet support these, but I’m eager to start playing with them to see how we can further improve Apollo’s user experience.

Slash commands are neat and all, but buttons potentially offer more to Apollo, as we could potentially stop using reactions for event signups. I hope this will reduce our API footprint, and eliminate scenarios where we have a “half posted” event where only some of the reactions were able to be added to the event message.

Discord is also working on threads, which could further stand to improve how we interact with Apollo. I’m not certain what we might do to plug into this, but at the very least it should offer a nice way to have targeted conversations in a thread on an event message.

Other things…

There are quite a few other features I’d like to add as well to Apollo, but I don’t have a clear roadmap of what exactly that will look quite yet, so don’t want to promise anything too soon!

Closing thoughts

It’s never a dull moment working on Apollo, and I’m excited to see where things will go next! Thank you for you support of Apollo; it means a lot. My hope is that soon I’ll be able to potentially start working part time (or even quit my job entirely) so that I can focus more on Apollo, all of which is only possible through your support.