Architecture

Franz

I've been thinking about a good architecture for the last few days. My current idea would be to split the application into a few more repositories:

flarum/core: Data storage, tests and business logic (models, commands, events, handlers etc.)
flarum/api: Web layer for the REST API (mainly actions)
flarum/flarum: The default frontend. This is where all the Ember.js files should reside, not in core. This repo will load the other ones via Composer (or Studio, during development). This goes well with the idea of alternate frontends.

For reference and further thoughts, an article from Paul M. Jones, creator of the Aura framework: Separate The User Interface Repository From The Core Application Repository.

Allineer

I would also like to suggest it, but only onto two repository:

flarum/backend
flarum/frontend

erlend_sh

Separating the user interface from the core application makes sense, but I don't get why the API should be in its own repository instead of together with the core application. Even if you can technically make a clean break between the core and the API, I don't see the big benefit here. The article you link to doesn't seem to shed a lot of light on this preference either, so why the 3rd repository?

Ahesanali

Seperating api from frontend is a perfact choise. So if one would not have any experience with ember can easily built ui in other libraries or framework like angular or backbone or marionette.

How ever with api i am seeing two repo one for
Core and one for flarum skeleton. Both repositaries are seperately managing dependancies via composer. This should not happen instead core should be part of vendor when used with skeleton and should use same vendor packages which skeleton is using. In this way both skeleton and core will refering to one vendor folder only.

Toby

@Franz Are you thinking flarum/flarum (the front-end) would be a package which is loaded into the skeleton, or would it be the skeleton itself? Where would that leave custom Laravel instances that want to integrate Flarum as a package?

I'm guessing the reasoning for splitting up flarum/core and flarum/api is that there is the possibility of someone building a PHP front-end which wouldn't need to use the API? I still think I agree that we should just put them together into one back-end repo. IMO we should be encouraging all Flarum front-ends (JavaScript or not) to be using the API rather than interacting directly with the core, and we should be encouraging all Flarum instances to have an API so they're accessible with third-party apps too.

Franz

flarum/flarum should be the skeleton package. Maybe the actual integrations with Laravel should be yet another repository, which would then be used when people integrate with Laravel (they would require flarum/laravel instead of flarum/core).

Toby

I've been experimenting with the folder structure a bit and here's what I've come up with:

[attachment:55389b042bfae]

This would be flarum/flarum, the skeleton repo. It's not functional at the moment, just theoretical. I'll go through what I'm thinking folder-by-folder.

assets contains JavaScript + CSS files which have been compiled (by PHP) from the source files in system/js, system/less, and any files registered by extensions. It also contains avatars and other file uploads.
config.php contains the forum's configuration settings - the minimum amount needed to connect to the database. The rest of the config settings are stored in the database's config table.
extensions is where user-installed extensions go (each one in its own subfolder).
index.php is the main entry point. It simply includes system/bootstrap.php and runs the returned app.
system is where all the Flarum stuff lives. The idea is to completely separate it from the forum-instance-specific files to make manual upgrades painless. You'll simply be able to overwrite the system folder with a new version, run an upgrade script, and you'll be good to go.
bootstrap.php is a custom script which sets up the framework. I'm thinking we could convert Flarum into a Lumen application?
extensions is where default extensions go. By storing them in here, they will get upgraded alongside Flarum.
js contains the forum/admin JavaScript apps.
less contains the forum/admin app LESS files.
src contains the PHP code that sets up the forum/admin app routes/actions.
storage contains temporary framework stuff like caches, sessions, compiled views.
vagrant contains vagrant scripts.
During development, studio contains Flarum's core/API repo(s). Otherwise, they are in vendor along with all the other composer deps.

Very keen to hear some thoughts on this! A couple of areas for discussion:

Integration

Say I have a Laravel app set up for my website and I want to integrate Flarum. How do I do that? The simplest way would be to just drop this whole thing into a subfolder in Laravel's public directory.

I know that's not the kind of integration some people will be expecting (the "install a composer package" kind)... I'm not sure if it will matter though, as long as we provide an extension/APIs to integrate with an external database/authentication mechanism?

I guess the other option would be to separate the front-end into its own repo, and then the skeleton would pull in flarum/core and flarum/frontend or whatever, and then set up directory paths etc. That way an existing Laravel app could pull in those packages too and set up its own directory paths. Not sure if it's worth the extra complexity though.

Distribution/Installation

I'm thinking we will write a build script which clones the skeleton repo, pulls in default extensions, does a composer install, and gets rid of unnecessary source files (uncompiled JS files in system/js, vagrant stuff, studio, etc.) The resulting package is what will be downloaded by the install script.

Toby

Re: integration:

Actually, changed my mind. I think we should move the front-end into its own repo (flarum/web) and then the skeleton (flarum/flarum) is merely a barebones setup of Laravel/Lumen that strings together flarum/core + flarum/web + extensions.

So it'd look something like this:

[attachment:5538e4da02d8b]

Allineer

Why Lumen?

Toby

Currently flarum/core depends on Laravel, but really it only needs to depend on a few individual components (illuminate/database etc.) The goal is to make it framework-independent.

If we do this, then for the skeleton repo, Laravel is probably overkill and using a microframework like Lumen will be speedier.

Allineer

Thanks.