NodeBB + MongoDB + Scaling (k8s)
-
@baris
Is there any way to not use Redis (it produces extra cost)?
Maybe we can implement something to supportisCluster: true
with the MongoDB?Also you shouldn't put isCluster: false in config.json if you are using clustering.
We did it cause this property anyway works only with the Redis
-
@baris mind explaining why redis is now required for clustering?
-
@antosik to answer your question:
No, you must use redis is you have multiple instances.
Why are you so opposed to using redis? The amount of "extra cost" it adds can't be that significant when you're already running multiple instances of NodeBB.
-
@PitaJ
I'm not against it ^^.
Just want to research a bit before giving AWS more money. :d@baris
So, we need to try:- implement something like
src\database\redis\pubsub.js
in mongo; - check out
socket.io-adapter-mongo
and@nodebb/mubsub
packages?
UPD. Found an interesting thing - maybe we can use
watch
+changeStream
to implement the pubsub ? - implement something like
-
The main issue from what I understood is actually lack of a maintained MongoDB equivalent of this: https://github.com/socketio/socket.io-redis
There are a few old packages based on the official redis one, but they were last published a few years ago. I think NodeBB team was looking at this fork recently (2 PRs made by 2 NodeBB staff members): https://github.com/lklepner/socket.io-adapter-mongo - and I guess it is the most recent one - but it also seems kinda abandoned.
So for now it seems that unless NodeBB takes on maintaining an adapter, redis will have to remain a requirement.
-
@antosik said in NodeBB + MongoDB + Scaling (k8s):
@PitaJ
I'm not against it ^^.
Just want to research a bit before giving AWS more money. :d@baris
So, we need to try:- implement something like
src\database\redis\pubsub.js
in mongo; - check out
socket.io-adapter-mongo
and@nodebb/mubsub
packages?
UPD. Found an interesting thing - maybe we can use
watch
+changeStream
to implement the pubsub ?What's your overall goal? I have a feeling that you are giving AWS way more money than you should already. If the goal is to go big without wasting money, this isn't the approach. Unless you are doing something in the billion hits a month range, I don't think that this approach can be cost effective at all.
So if you want to give AWS money just for fun, then you might as well give more. If you want to be cost effective, then setting yourself up for scaling will require more scale than will ever be practically needed.
- implement something like