Reasons to be excited:
Simon from classcraft:
First, thank you very much for giving this a chance, the biggest Meteor app is the best first case study. I am going to be on top of it to make sure it’s running smooth for them.
Must admit, got a bit excited, an almost 100% improvement is not to be ignored. But honestly, I would’ve been much happier with a 300% improvement. Anyway, 100% doesn’t necessarily mean that you can run on half of your infrastructure, because the more you grow the better the performance will get. And the important part is: you can continue growing
The fight isn’t over yet
What if I told there is room for even more performance improvement ? (https://github.com/cult-of-coders/redis-oplog/issues/199) But this one is relatively hard… It’ll take me a while to accomplish and do it right (At least 16 hours of work), as I need to rethink the architecture and refactor stuff so it doesn’t become an unmaintainable mess.
Just a little bit of a history since we’re celebrating a nice achievement:
- First we did the fetching (at the insert level) when we mutated and push it to redis
- Then we realized it’s prone to race-conditions so we moved fetching to processors that interogate the db individually
- Then we realized if we have a lot of observers, it can lead to 30-40 db requests for a single event
- Then we optimized and aggregated what is needed for processing into 1 single db request / event (unless it’s a removal event)
- Then this is the holly grail: issue #199
I won’t even start on how many hairs I pulled because of Optimistic UI !! But we nailed it in the end.
Stressing some things out:
The road to making any DB reactive has been opened.
The road to scaling reactivity infinitely has been opened.
The road of heavy investments into big Meteor apps has been opened.
We made this happen together, it was a shared effort.