DDP over bad connectivity in emerging markets?

I have heard that DDP on Meteor is very bad if GPRS/3G/HSPA/4G connectivity is bad.

It just doesn’t work. Is this true? Bcoz this is very common in emerging markets, in interiors.

Is this a serious problem? I have been told that the reactivity doesn’t work under these circumstances. It fails.

Does anyone have info about this?? Is a nice mobile connectivity prerequisite for DDP etc. to work??

My question is in the context of Meteor on Web & also talking to a Native Android app. I am building a platform for politicians in India to communicate with their supporters/volunteers. Working with bad network is a given with Indian interiors. Mainly with regard to data connectivity. LinkedIn recently came up with their Lite version of Android app, which even works with 2G.

Is Meteor/DDP/AndroidDDP graceful with this or does it just snap??

Thanks.

I think this issue is not DDP, but websockets.

This may help your understanding:

You can completely disable websockets with the DISABLE_WEBSOCKETS environment variable.

3 Likes

What is the current status of Websockets’ performance when connectivity is bad?

How bad is it? And will disabling them altogether, mean that reactivity will cease? What is the benefit of disabling Websockets, apart from what is mentioned in the code (proxies)?

My situation entails too many Android native Apps, connecting to the Server on Android DDP, along with a few Web based clients.

I have read the links you have posted. Many, many thanks for that.

How much does Re-connection feature of DDP help? Doesn’t it make the problem go away?

Do you have any thoughts? @copleykj @serkandurusoy @storyteller Sir!

Websockets basically enables you to create “connected clients” and DDP is esentially a client/server data synchronization built on top of that.

Now if you have “connection” problems, the idea of “connected clients” automatically becomes something to reconsider because you’ll have to figure out how to best handle the “disconnected” state. Luckily you can use the offline-related packages you can find on atmosphere to make your user experience as seamless as possible.

It is really not that hard and with some extra work, you can manage it quite nicely to achieve good UX. After all, meteor gives you the “connected” part out of box, which in my opinion, is usually the hard part to get right.

Also, you might want to give appsync a chance because that’s something purpose built around offline-first paradigms, but its developer experience might be lesser for you because it is still a beta product with tooling not being very well evolved.

From the DDP Readme that @robfallows linked:

It also supports a second transport, EJSON over HTTP long polling. It will automatically fall back to this transport if websockets are not available. This is not as efficient as websockets, but it works in older browsers. It uses the sockjs library for long polling.

This means that the behaviour of your app doesn’t change, as the websocket is emulated over HTTP long polling.

The delay for reactive data to make it’s way across the connection will be a bit longer. You’ll need to test how serious the penalty is, and if it gives you a benefit in poor-connection areas