Yes, that's right. I said it. Let me explain what I mean, but first, let's make a few things clear.
- I am the creator of Cronfig. So I do not hurt anybody else's feelings.
- This is not a hate post. Sorry if you got here only because you wanted to read some dirt on the service.
- It's meant to point out what is wrong with the current version and how the next version should look like.
You may find interesting to read about why Cronfig was born before this post where I explain why it's stupid, difficult and user unfriendly.
Cronfig 1.0
I created Cronfig to be simple and easy to configure. Oppose to other cron configuration solutions. Where you needed to know the syntax, the folder where Mautic lives, the commands. The first version of Cronfig solved all that. You had just a button to push and the cron task started to do what the task description said it will do.
There was a list of available tasks like this:
And when you pressed the button that you wanted to process the emails you saw what the task did, how long it took and when it will be triggered again. You could configure its frequency. Like this:
What I did wrong
Overcomplicated UI
And I thought it cannot be simpler. Boy, was I wrong. There is still tons of questions users have. Like:
- What tasks do I need to enable?
- What frequency is the best for the particular task?
- What happens if I misconfigure it?
I also spent a lot of time on the UI part where users will see live updates, will be able to configure, stop, refresh, delete the tasks and so on. Let's get rid of all that.
Wrong assumption when selecting the technology
I wrote it in ReactJS as an embeddable UI so anyone could implement it easily into another apps. It was fun, but it was time consuming and totally unnecessary. After several years of looking, I did not find any other self-hosted app that would depend so heavily on cron tasks as Mautic. Other apps need 1 cron tasks for everything they do. No other app do so much work in the background. Let's throw that away. Let's focus only on cron service for Mautic.
Cronfig 2.0
When I throw away the UI, how will users configure it?
After several years working with DB and other great coworkers I probably learned to think differently than I used to. The right question to ask is
How to make it intelligent so the users wouldn't have to do anything?
It's not really harder to do. The UI will be a lot simpler. Just a log of what has happened. The rest the information needed to run the right cron tasks at the right interval is stored in Mautic itself. Why should we request that knowledge from the user?
An example - Segments
Segments are being rebuilt by a command and the command must be triggered periodically. The Cronfig plugin can read from the database if any segment is published. If so, it can create a task via API itself and configure optimal frequency. If all segments will be unpublished or deleted, it can stop or delete the task and save some resources on both sides, the Mautic instance and the Cronfig workers.
This can be applied to all commands. The Cronfig plugin can read the configuration and use of each feature and configure the tasks accordingly. There is no rocket science behind it but I decided to call it Cronfig Intelligence anyway.
Autoscaling
One more powerful feature can come out of this re-thinking. Some commands can be automatically scaled. Cronfig uses HTTP requests to trigger the commands. That has its limitations mainly in the time how long the request can wait for the response. By default it's 30 seconds. I believe all Mautic users had to increase this limit already but it will never be enough to process a long list of segments on a large database.
The thing is that the Cronfig plugin can know what the limits are and adjust the tasks accordingly.
The Cronfig plugin could identify if the last execution was close to the timeout and apply the --max-contacts parameter so it would not timeout. It could increase the task frequency and decrease the number of processed contacts so it would fit into the limits.
It can even use concurrent tasks for campaign event execution. There are parameters like --max-threads that will allow to create multiple concurrent Cronfig tasks.
Cronfig can also make sure the server where the Mautic instance is installed won't get overloaded. I played with a library for system info before. It can check if the system is overloaded and decide not to proceed the current job.
There could be even some intelligent priorities. Like if there is an email blast to send and the system is getting overloaded, stop rebuilding segments or webhooks for a short period of time. Or decrease the frequency for campaign events until it's sent.
Conclusion
The point is, I can change Cronfig from "a button press simple" to "dead simple". It can automatically reconfigure itself on demand. User does not need to make any action. With this philosophy I can even trow away a half of the code base that built the UI and write simple intelligence engine instead.
The main problem now is to find the time to get it done. As it always is. With everything.