As promised some technical insight into how things are done at Blomstra.
Flarum
First off, let's touch on the subject of what a Flarum community instance is and where it differs from the default installation.
The skeleton
When you run composer create-project flarum/flarum -s beta it effectively downloads the files from the flarum/flarum repository - also known as "the skeleton" and do a composer install directly afterwards.
The skeleton offers flarum/core (our framework) as dependency, but also all bundled extensions like flarum/tags and flarum/approval.
Everything now installed, aside from vendor can be modified to your liking. At Blomstra we have a fully customised skeleton, it includes many small tweaks in the form of local extenders. Local extenders behave like extensions but are activated from the root extend.php in your installation (or skeleton).
Some of the changes we made are:
- Overriding the session handler to use the database instead of a file based handler. Due to our horizontal scalability we need all web nodes to read from the same session storage.
- Overriding the default Flarum file storage to use a cloud bucket. This impacts avatars, but also compiled assets like javascript and stylesheets to use one identical version.
- Setting our default mail provider settings, without them showing up in the Flarum admin area. While still allowing users to set their own configuration.
All these changes are so specific to our usecase it doesn't make sense to overcomplicate things by forcing us to use extensions.
Docker
In containerization you typically create an isolated snapshot (called image) in order to create multiple "mini virtual machines" (called containers). Doing so enables horizontal scalability - the ability to deal with in- and decreasing traffic to your application by adding and removing containers autonomously.
Because we use kubernetes, we need to create a docker image of a fully functional Flarum installation. Kubernetes is awesome, because like Flarum it's open source, configurations can be (almost fully) carried over to any other (cloud) hosting provider and it's very mature. Our CI/CD - short for "continuous integration" and "continuous deployment" - takes care of generating the image for our kubernetes cluster(s). Once this image has been completed it will be pushed towards a registry; a registry shared inside our kubernetes cluster which then updates all our Flarum communities.
Because we use images we initially start out with a fixed set of extensions. These are all triaged for use on our platform. We're already looking at options to allow customisations through local extenders and packages/extensions without interfering reducing the quality of our service.
