Last week we talked about user accounts and said that this week we’d talk about the new software stack, so let’s do that.
On both new and old Cherp, the core technologies are staying roughly the same - we use PHP as the backend language that handles all the server side logic. This interacts with PostgreSQL as our database engine, and Redis acts as a caching layer between the two for information that takes a little while to get but that’s accessed often; things like your unread count, chat status, etc (Coincidentally, this is also the cause of the ghost unread bug - it caches your unread count for 24 hours unless it changes, but grace period and account deletes don’t decrement the counter. More on that in a minute). On the frontend, we currently use React, an abominable monstrosity that we’re glad to be dropping.
Let’s talk about PHP first. Cherubplay was originally written in Python, but nobody really knew enough Python to fix that code up when it started breaking. As such, current Cherp uses PHP 7.4. This is about to leave active support meaning it’ll be receiving security updates only, meaning that for this rewrite, we’re switching to PHP 8. Right now, we’re coding with 8.0 in mind, but by the time we release, we’ll be on 8.1. It’s quite likely that we’ll be able to upgrade through all the 8.x versions after this with little issue. On top of PHP, current Cherp uses a microframework called Slim to provide some API routing stuff. For new Cherp, we’re using Laravel, something most PHP developers reading this will be familiar with. Personally, I prefer the older system (albeit with some major code touch ups needed), but that’s because I find MVC as a paradigm overly convoluted for what it does - but given Laravel is extremely widely used, and will make recruiting new devs easier in future, that’s what we’re going with. It gives us a lot of tools to work with, and so far, is making some things easier and some things harder.
React is what you use right now to see the site. It’s awful, and we hate it. It’s a Javascript framework created by Facebook. For the new version, Laravel gives us a set of tools called Blade that lets us write the frontend in PHP. On top of this, there’s also a system called Livewire that we’re adding - this uses Blade as a basis, but adds some fancy dynamism on top so that you can have a similar experience to what you already have with dynamic elements. This way there’s a lot less Javascript involved, which means it’ll be easier on your computer and, if you’re one of those users who use mobile, your battery won’t drain as fast either.
PostgreSQL (or Postgres, nobody can apparently decide how to refer to it) is the database we use. SQL is widely understood at this point by most techy people, but for those unaware, it stands for Structured Query Language. Ignore the people who tell you it’s pronounced “sequel”, they’re wrong and should be shunned (EDITOR'S NOTE: This opinion is incorrect). The most popular databases of this type are Postgres and MySQL (or MariaDB, a fork of MySQL that has a nicer license and which you should really be using instead). MySQL/MariaDB is a lot more popular than Postgres, but Postgres has a lot of extra flexibility. Most people don’t need this, but current Cherp uses Array datatypes. Arrays are very powerful, but - whether it’s just because of the way PHP forces you to use them and they’re better in other languages, or because the datatype itself kinda sucks - they’re absolutely awful to work with. For the rewrite, we’re keeping Postgres - even without using any of the advanced features, it’s powerful and fast, and if you give me 10 minutes alone in a room with it, I can make it do some impressive things. What we are doing is getting rid of arrays, and moving the stuff we use them for into a separate table. It’s one of those things that’s paradoxically both messier and cleaner, but it’ll reduce the load on PHP when it has to explode or implode the arrays when pulling/pushing to the database.
Redis is also staying, though exactly how much use it’ll get right now is
debatable, and can only be answered once we’ve learned a little more about how Laravel handles things. Right now, we use it for login sessions and, as mentioned, caching. For those who don’t know, caching is where you store something that takes a long time to get to a faster place so it can be called faster. For example, let’s say I log in for the first time in a while. When I log in, the top bar needs to show how many unread chats I have, so it asks the database to count how many chats have me as a participant. Then, it filters these to find ones where my chat_status is marked “unread”. Then it gives the count back. Each step of this is slow, and takes time. It’s also something that’s requested on every page load, so rather than do it every time, we put a step in at the beginning and at the end - check Redis first. Redis stores everything in memory using key-value pairs. Redis has up to 16 “databases” - let’s say the unread_counts is database 2. So, it tells Redis to check database 2 for a value with key [whatever my user ID is]. If it’s there - it just spits the number out. If not, it’ll run through the process of asking the database, and when it’s done, it gives the number to Redis. There’s a few other places where this is done, and a few places where the cached number is ignored and forces another database check to refresh it, but broadly speaking, Redis cuts the performance cost of the site to about 20% of what it’d otherwise be.
And there we go - a summary of what we’re using, both for the new site and the old one, as well as a little overview of what it does. If you’re in the Cherp Discord server (TT make this a link) (EDITOR'S NOTE: Ok, done), feel free to hop into the coding channel and I’ll answer any more in depth questions you have.
