if you don't mind trying languages other than js, might I suggest phoenix's liveview? Its past what meteor could ever accomplish
here's the basic operating model.
you have a controller but unlike a typical web controller, you are rally controlling the lifecycle for a long lived server process thats specific to the user in a session. you get callbacks for the startup where you can load data structures into the session. You also have functions that let you write frontend components from the backend similar to server side react.
Here's where it gets interesting. The frontend maintains a long lived websocket connection. if you change a piece of data on the backend, the frontend will automatically update to reflect the changes. additionally, you can set event triggers in your html that trigger server side callbacks from which you can update that server side data.
so you might be asking yourself, "big deal, meteor does that"
The big deal of course is that you're using elixir, a mostly functional language with immutable data structures and concurrency abstractions that make node look amateur hour. Spawning thousands of one off short lived persistent sessions, one for each user, that each have a websocket connection is a trivial task for the beam virtual machine that phoenix runs on. Scaling the backend for this is trivial compared to ding it in node which is what meteor is doing. The underlying platform is just a better fit for what meteor is trying to solve. Every thread has its own heap of memory and is isolated from others. You have no such guarantee in meteor unless you dedicate an entire OS process for each user, a task that will be expensive and nontrivial)
of course, its a backend process. so phoenix liveviews can also do a few other interesting things. need to upload an image or perform a background task? have your callback send its process id to the background worker and the background worker can send a message back to your session enabling you to update your session data. the frontend will automatically reflect the change. by comparison, tailing mongodb's oplog is child's play. If you can have your data source emit events on changes, you can plug it into elixir's pubsub system and accomplish the same reactivity in a live view.
Oh yea, and fly.io already works with both meteor and live view's limitation of needing the physical machine to be close to the users for keeping the latency down.
that largely depends on your machine's specs but the limit is much higher that you are going to get in go, python or ruby (yes I know action cable uses go)
but to get a better handle, here's some interesting reading
here's the basic operating model.
you have a controller but unlike a typical web controller, you are rally controlling the lifecycle for a long lived server process thats specific to the user in a session. you get callbacks for the startup where you can load data structures into the session. You also have functions that let you write frontend components from the backend similar to server side react.
Here's where it gets interesting. The frontend maintains a long lived websocket connection. if you change a piece of data on the backend, the frontend will automatically update to reflect the changes. additionally, you can set event triggers in your html that trigger server side callbacks from which you can update that server side data.
so you might be asking yourself, "big deal, meteor does that"
The big deal of course is that you're using elixir, a mostly functional language with immutable data structures and concurrency abstractions that make node look amateur hour. Spawning thousands of one off short lived persistent sessions, one for each user, that each have a websocket connection is a trivial task for the beam virtual machine that phoenix runs on. Scaling the backend for this is trivial compared to ding it in node which is what meteor is doing. The underlying platform is just a better fit for what meteor is trying to solve. Every thread has its own heap of memory and is isolated from others. You have no such guarantee in meteor unless you dedicate an entire OS process for each user, a task that will be expensive and nontrivial)
of course, its a backend process. so phoenix liveviews can also do a few other interesting things. need to upload an image or perform a background task? have your callback send its process id to the background worker and the background worker can send a message back to your session enabling you to update your session data. the frontend will automatically reflect the change. by comparison, tailing mongodb's oplog is child's play. If you can have your data source emit events on changes, you can plug it into elixir's pubsub system and accomplish the same reactivity in a live view.
Oh yea, and fly.io already works with both meteor and live view's limitation of needing the physical machine to be close to the users for keeping the latency down.