[Subscriptions] Queue "new post" email

[franzliedke]

Relates to #978.

A nice first use-case for playing around with our new queueing support (#1773).

1. Send new_post email via queue (which uses the sync driver by default, so this should not change behavior).
2. Document the setup for real queue workers using e.g. Redis, and try it out on discuss.

Once this is implemented, we can start showcasing this to extension developers, and tackle other tasks in the system that could benefit from being offloaded to the queue.

[STotev]

I've read both the #978 issue and PR conversation as well as the code(multiple times) and still wondering what's the idea of this? Why just not using the original laravel queuing system?

Would've been easier to just have a configuration of what queue type to be used. If the shared hosting doesn't support background workers, the config can remain sync.

Am I missing something that I can't explain myself or... ?

[luceos]

We are actually using the Laravel Queue, but without any configs (per se). What Flarum relies on more heavily is the ability to replace bindings in the service container. There are several reasons for this:

• we rather allow admins to configure things in the admin area, not in configuration files
• we hope to limit the file size of a full Flarum install by not loading all direct dependencies (drivers)

I used to be skeptic too, mind you, but I think doing it like this makes sense for a product like Flarum.

Here's an example how I am implementing a Redis based Queue (I need it for the horizon extension to work):

https://github.com/Bokt/flarum-redis/blob/bc8a25776e02de1c5284dd6011e0aa96aeea542c/src/Provides/Queue.php#L15-L26

[STotev]

I guess I am missing some internal knowledge about Laravel and components and makes me confused of what is going on.
To be honest. I've never worked on a project that strips off a huge part of Laravel.

I need to dig a bit longer to get better understanding of the internals but I will still be happy to try and work on this so I can get deeper understanding of Flarum as well.

Anyone else could work on this as well. I am taking this mostly for learning purposes.

@luceos is your Redis approach going to be implemented in Flarum?

[franzliedke]

AFAIK, bokt/flarum-redis is the current playground for what will probably move into core.

As @luceos already explained, there is not much gain in offering all the adapters and functionalities that Laravel brings to the table in Flarum. We mostly use Laravel (its components, really) as a library, not so much as a framework. Laravel wants to offer a lot to many different types of applications; we have very specific requirements and goals, thus we don't need it all.

My current vision is for Flarum to support a fallback and a "real" driver for queueing. The latter will probably be based on Laravel's Redis queue.