Using database for queues was responsible for deadlocks, appeared to be slower and less reliable than using redis.
Also, I didn’t like having supervisord installed in the docker image, and I didn’t like the way it was started from the docker-compose.yaml file either. And Horizon has a nice feature: the number of processes it allocates to the queues can be minimal to save resources under light loads, and dynamically increased on-demand.
All in all, I think running redis is not as inconvenient than I initially expected. It’s very fast, lightweight, and its “universality” makes it probable it’s already installed when you want to use Cyca. And debugging queues is a lot easier…
In fact, I choose redis because I already use it in many other apps, but you could also use other servers like Beanstalk or Amazon SQS.
In the end, I recommend anything but “database” in the QUEUE_CONNECTION of your .env file.
I have improved how the UI reflects document update and change in unread feed items count. The queue processes were not executed in a correct order, which caused a large amount of data sent through websockets after documents and feeds were updated. Now, these notifications to the UI occur right after each document and feed update.
I’ve improved several things about the UI, mainly the color scheme used in the light theme, the look of scrollbars have been fixed for Firefox, etc. The 0.6.9 release compiled these changed, which you can glance here
v0.7 - The History Update
I have released a new major version which bring a history feature. You can read all about it in the announcement.
Two pivate donators were very generous this week, in fact, the first ones, for a total amount of 400€. That’s amazing, and I couldn’t be happier about that. A big, big thank to them ! Your contribution make me realize that there are other people, besides me, that have faith in this project and it means the world to me. Thanks 👍
This money will be saved for now, as my intent is to rent a dedicated server or find a docker hosting platform to run a permanent demo of Cyca. I would do it at home, if only I had a decent connection, but for now I’m on a 8Mb/s down and moreover, 1Mb/s up connection, so unfortunately, it wouldn’t make it. I have to go hunting for a good offer.
A dedicated server at Online.net would cost me a bit less than 50€ per month. I like them, I already have worked with them in the past, and never had any issue. But 50 per month just for a demo of Cyca, I must be able to find something cheaper. I’m going to see this week.
My birthday 🎉 Yep, it’s tomorrow. And I have plans involving some construction bricks, so I might not work on Cyca as much as I usually do on week ends.
This week didn’t see as many commits as past ones and I think this tendance will continue. The reason is simple: until now, my intention was to fix what needed to be fixed, and add small features.
My code base satisfies me right now, so I’m more encline to work on bigger features, the kind that would take me more than two days to build.
Consequently, the fast pace at which I published new minor versions will slow down, but publishing new major versions should occur proportionally more often.
The next update should be released next week, or maybe the week after, depending on how it goes. This will be the biggest update ever, for the most complex feature addition. Although I will definitely publish fixes when needed, you should not expect as many releases as you’re used to, until the v0.8.0 will be made available. It will be a big leap.
Stay tuned ! And remember: if you like Cyca, there are a few ways to make a contribution. For instance, donating would be nice, as it would allow me to rent a decent server which will be used to present you a live demo of Cyca, so you could test it before installing it if you liked it. And, maybe, a public instance ?
Regardless, I’m glad you read the developer’s blog, and I thank you for that anyways !