Blomstra, development services & scalable managed Flarum

rob006 we measure the volume via a Flarum customization and compare that against the overall traffic volume on the network tiering level. Bots, guests and member traffic is identified from within the Flarum layer.

We do not enforce the "active users" limitation, we hold onto soft limitation. There are obviously some sensible resource limitations in place to protect our auto-scalable stack but these - under normal circumstances - do not affect the performance or availability of your community. Once you continuously or repeatedly reach our limits you will be informed through email and the dashboard. A single occurrence of over-usage on "active users", as such, won't bring your forum down.

I will write some more about how our stack works and how we founded the company later on, feel free to follow along.

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.

Time for a new update. The local extenders I mentioned before luceos can be added by enriching the skeleton (flarum/flarum) - the thing where your extend.php is located. To do so you can update your composer.json by adding a new key (on the same level as require) called autoload with the following entries:

   "autoload": {
        "psr-4": {
            "App\\": "app/"
        }
    },

Run composer dumpautoload after changing the file to enact the change.

If autoload is the last entry before the ending }, make sure to remove the ,. Composer will complain if the json file is invalid. Usually this is the cause.

You are now able to store php classes in the app, next to public and storage.

One of the things we do this for is to enable a session driver that uses redis or the database. Flarum by default uses a file based session driver; when you want to allow visitors to hit all web nodes you need to share those sessions between the nodes. File based sessions are only stored on that node (unless you mount that directory on a shared disk, but that limits where you can host those web nodes).

In order to override that we can do the following:

app\Session\OverrideSessionHandler.php

<?php

namespace App\Session;

use Flarum\Extend\ExtenderInterface;
use Flarum\Extension\Extension;
use Illuminate\Contracts\Container\Container;
use Illuminate\Database\ConnectionInterface;
use Illuminate\Session\DatabaseSessionHandler;

class OverrideSessionHandler implements ExtenderInterface
{
    public function extend(Container $container, Extension $extension = null)
    {
        $container->extend('session.handler', function ($_, $container) {
            $config = $container->make('config');

            return new DatabaseSessionHandler(
                $container->make(ConnectionInterface::class),
                'sessions',
                $config['session.lifetime']
            );
        });
    }
}

And in extend.php:

return [
    // ...
    new App\Session\OverrideSessionHandler,
];

That's it

Do let me know if you tried this out and what you think of it ️

I totally forgot about one thing, you need the sessions table. So here goes part 2

Create a directory called resources/migrations in your flarum directory. And store this file in it:

0000_00_00_000000_sessions_table.php

<?php

use Flarum\Database\Migration;
use Illuminate\Database\Schema\Blueprint;

return Migration::createTable(
    'sessions',
    function (Blueprint $table) {
            $table->string('id')->primary();
            $table->unsignedInteger('user_id')->nullable()->index();
            $table->string('ip_address', 45)->nullable();
            $table->text('user_agent')->nullable();
            $table->text('payload');
            $table->integer('last_activity')->index();

            $table->foreign('user_id')
                ->references('id')
                ->on('users')
                ->onDelete('cascade');
    }
);

This change to the database sadly isn't automatically picked up by Flarum, so we need a command to run the migration:

app/Console/MigrateCommand:

<?php

namespace App\Console;

use Flarum\Console\AbstractCommand;
use Flarum\Extension\ExtensionManager;
use Flarum\Foundation\Paths;
use Illuminate\Contracts\Container\Container;
use Illuminate\Filesystem\FilesystemAdapter;
use League\Flysystem\Adapter\Local;
use League\Flysystem\Filesystem;

class MigrateCommand extends AbstractCommand
{
    /**
     * @var Container
     */
    protected $container;

    /**
     * @param Container $container
     */
    public function __construct(Container $container)
    {
        $this->container = $container;

        parent::__construct();
    }

    /**
     * Fire the command.
     */
    protected function fire()
    {
        /** @var ExtensionManager $manager */
        $manager = $this->container->make(ExtensionManager::class);
        $migrator = $manager->getMigrator();
        $migrator->setOutput($this->output);

        /** @var Paths $paths */
        $paths = $this->container->make(Paths::class);

        $migrator->run($paths->base . '/resources/migrations');
    }
    
    protected function configure()
    {
        $this
            ->setName('local:migrate')
            ->setDescription('Run outstanding local migrations');
    }

    protected function localDisk()
    {
        $driver = new Local(app(Paths::class)->base);
        $filesystem = new Filesystem($driver);

        return new FilesystemAdapter($filesystem);
    }
}

Now register this command in your extend.php:

return [
    // ...
    (new Flarum\Extend\Console)->command(App\Console\MigrateCommand::class),
];

Now run php flarum local:migrate to create your sessions table