meteor-feature-requests
meteor-feature-requests copied to clipboard
meteor
Postpone open the DDP connection
yes, it didn't prevent the initial connection attempt. I still see an http GET to the /sockjs/info?... path
@knigal from the original post, I thought you want to avoid open tunneled connections (WebSocket), which is a waste of server resources. Falling back to sockjs will help to reduce the amount of concurrent and idle sockets. Disabling keepalive or setting it to short time should help too.
Disabling first "acknowledgment" request is not possible.
In that case I'll clarify:
I have a few meteor instances which are not set up as classic Meteor servers with ddp. They include the cfs:http-methods package, which provides Meteor the ability to act as a nodejs server - apart from the initial app bundle download, it only serves REST api requests.
The clients of these servers do not need to connect the ddp. They will not use it. Allowing the connection to happen prevents scale, because once connected, the server is limited to the number of concurrent sessions. Thus I asked for a switch to override or prevent/postpone the initial ddp connection. I hope this clarifies a bit...
@knigal now it's almost clear, so you don't use Meteor's methods and pubs/subs, and you only need to serve js/css static files + REST from those servers, right?
Correct.
In practice I use an environment variable to switch the server from REST methods to a reactive pubs/subs session. Reason is the scaling issue. Many sessions are 'good enough' to run over REST, which allows for easy, inexpensive scaling
@knigal
We have such experience, for example those two experiments, is build on Meteor, has node.js server, but without DDP, Methods, and Mongo dependencies:
- https://cssbuilder.veliovgroup.com
- https://goto.veliov.com/en
In short, - default packages is removed and only Meteor's core packages is kept:
meteor
webapp
underscore
ecmascript
As you see we've removed meteor-base and mongo, where is meteor-base just a package collection:
dynamic-import
meteor
webapp
ddp
underscore
livedata
hot-code-push
But we need only meteor, webapp and underscore to create minimal functional app.
Going further take a look on meteor-build-client package which will create a static application build with no need to have a Node.js server, and can be easily served via CDNs:
# in the meteor's project dir:
npm install -g meteor-build-client
meteor-build-client ../static-build --url https://example.com
Let me know if this is helpful.
It's reassuring that there's a "no ddp" mode which can be reached by removing packages. That being said, this solution does not seem to work in my case.
As previously mentioned (I apologize for repeating myself) today I have several servers running the same meteor app bundle. Using an environment variable USE_REACTIVE_SESSION=yes I toggle clients behavior: pub/sub or REST.
Still, the REST clients automatically attempt to connect to the meteor app. To fail that connection, I set DDP_DEFAULT_CONNECTION_URL to some unreachable url, such as http://no.such.url which returns a silent error with no further implications.
The path of removing packages cripples the bundle. The server will not be able to serve ddp traffic when the USE_REACTIVE_SESSION environment variable is toggled
Lastly, I'll add that the in the future I'd need some of the "no pubsub" clients to connect DDP, but only under certain conditions. If I corrupt the DDP_DEFAULT_CONNECTION_URL then it's still possible, but I'll need:
DDP.connect('http://myapp.realdomain');
This should work in theory, but it'd be cleaner if I did not corrupt DDP_DEFAULT_CONNECTION_URL and simply run DDP.connect();
while setting a (non-existing) env variable DDP_CONNECT_ON_START=0
That's my vision for this use case. I don't see adding support for a DDP_CONNECT_ON_START variable a big change. It's relatively safe since as it does not affect any other Meteor behavior
wdyt?