Ability to pass an alternate DDP connection to autoupdate
rclai opened this issue · comments
_1 Upvote_ I hope this fix makes it in the next release.
Here's a reproduction!
https://github.com/rclai/meteor-reload-of-death
Someone else was having this issue too it seems:
http://stackoverflow.com/questions/26184479/meteor-does-not-render-css-and-keeps-reloading-the-app-when-using-external-ddp-m
Looks like there was an identical issue from 2 years ago that was never addressed.
I'm not an expert on this, but as far as I can tell the recommended way to have two apps run on one backend server is to use DDP.connect. If you set the DDP_DEFAULT_CONNECTION_URL this connection will also be used by autoupdate (hot code push) and other app-specific data, causing reload problems. @glasser, does that sound right?
Is it not possible to create a separate connection that handles the hot code reload/CSS refresh if a DDP_DEFAULT_CONNECTION_URL that is different is set?
We have a large set of collection models that each of our separate apps share by being encapsulated in a local package. Our single backend server that all the apps connect to uses that local package with our models in it.
We were trying to avoid having to use DDP.connect because we would end up having to do something like:
MyModel = new Mongo.Collection(
'myModel',
(notCentralBase ? { connection: DDP.connect('...') } : undefined);All of our apps already had a bunch of Meteor.call(), Meteor.subscribe(). It would've been terrible to have to keep some global BaseConnection = DDP.connect('...') floating around and having to refactor all our code to use that for our method calls and subscribes. Many third-party packages that use custom subscriptions (i.e. subs-manager) or do method calls that we want making to our central server will end up making them to the 'local' server. Our user accounts needed to connect to the central server too, but because it already connects to the 'local' server, you would have to resort to ugly workarounds to get authentication working.
PS - We had to use a custom meteor-platform package that excludes reload and autoupdate to get rid of the constant reloading in case anyone wanted to know.
It sounds like the best thing to fix your problem would be a DDP URL for things like methods, subscriptions, and login that doesn't affect autoupdate?
Yes.
I actually managed to get it working where hot code reloads/CSS refreshes work in the local server and still stay connected to an external DDP server! All I had to do was clone a local copy of the auto-update package and change the client code to use a custom MyLocalDDPConnection = DDP.connect(...) on the Mongo.Collection("meteor_autoupdate_clientVersions") and replace its Meteor.subscribe's with MyLocalDDPConnection.subscribe.
👍 I've came across this same issue recently. Removing or modifying the autoupdate package fixes the infinite reload loop for me as well. It would be nice to have an actual fix though.
I'm a little confused. I think this is working as intended. DDP_DEFAULT_CONNECTION_URL is intended to be used for things like "ensure that the DDP connection always goes over https" or "use a randomized URL to get around per-server concurrent connection limits", not to make Meteor.server be a different server. I think it's pretty reasonable to assume that autoupdate always reloads the app over the default connection.
It seems like the third-party packages like subs-manager should allow you to pass in an alternate connection as an option instead of always using Meteor.subscribe.
That said, sure, I can see wanting to be able to configure the autoupdate package in the same way (to use an alternate DDP connection instead of Meteor.connection), but I think this is separate from "you should be able to redirect DDP_DEFAULT_CONNECTION_URL and make things work". Let's track this as a feature request, albeit one that is somewhat stymied by our general lack of a pattern for configuring the things that packages do at initialization time.
Yes, I should have clarified, but yes, the idea is to set the DDP connection of autoupdate. Is this something that could be done via settings.json or an API of sorts like Meteor.setAutoUpdateConnection()?
Also, are pull requests encouraged here?
Here's a workaround (only works pre-Meteor 1.3 era) if anyone is interested.
Any news on this?
Currently working with the workaround - thx @rclai , but it would be nice to have a built in solution.
Regards,
Lukas
For v1.3, it now requires making some changes to the new WebAppLocalServer.
I already have a hack-ish implementation that I can streamline and make stable next weed (when I have a bit of time), at least for the browser and Android.
It involves creating a second DDP connection on dedicated to the hot code push and accepts a configuration option. Right now I am using a custom autoupdate package and hard-coding the URL in the Cordova overrides, but I believe it can be passed as an argument to WebAppLocalServer.checkForUpdates from the WebView.
Do you have any thoughts on this matter, @dgreensp @rclai @benjamn?
I think that having a mobile app that connects to a main Meteor server (e.g, the main web app's server) is a reasonable use case, as I wouldn't want to bundle all of the web app's resources with the mobile app (and vice versa).
I've been working on a final solution for this issue. I think I got it working well but I'm still testing it out. Anyone interested to help me test it?
@Richie765 I will be building a small project that may use this type of functionality, so I would be happy to take a look at what you did. Mine was to much of a hack for my taste.
@MasterAM, I've been testing it on my production app and it seems to work just fine. Here are the instructions and a working example:
To help provide a more clear separation between feature requests and bugs, and to help clean up the feature request backlog, Meteor feature requests are now being managed under the https://github.com/meteor/meteor-feature-requests repository.
This feature request will be closed here, but anyone interested in migrating this feature request to the new repository (to make sure it stays active), can click here to start the feature request migration process. This manual migration process is intended to help identify which of the older feature requests are still considered to be of value to the community. Thanks!