When you unsubscribe from all channels, Pubnub still keeps making heartbeat calls (pings). This results in the application consuming too much battery and data in the background.
Any way to completely unsubscribe and not make any calls?
This has been addressed in the latest github repo of PubNub JavaScript SDK v3.7.6. CDN libs may still need to be updated.
So doing an unsubscribe from all channels should prevent any further traffic to/from PubNub network.
Related
Service workers require HTTPS ... If your production web server does
not support HTTPS, then the service worker registration will fail, but
the rest of your web app will remain functional.
quoted from the docs at https://create-react-app.dev/docs/making-a-progressive-web-app.
What does it mean the rest of your web app will remain functional, but service worker registration will fail? In other words, if my app remains functional, do I really care if service worker has failed? (what are the limitations?)
So your app would still work, but you would lose all of the functionality provided with the service worker. At the bottom of the "Why Opt-in?" section of the Making a Progressive Web App it states:
The workbox-webpack-plugin is integrated into production configuration, and it will take care of generating a service worker file that will automatically precache all of your local assets and keep them up to date as you deploy updates. The service worker will use a cache-first strategy for handling all requests for local assets, including navigation requests for your HTML, ensuring that your web app is consistently fast, even on a slow or unreliable network.
So you could use it as normal but you would lose:
Offline support,
Precaching of your local assets,
Cache-first approach for your local assets and navigation requests,
Performance improvements of your application in slow or unreliable network conditions.
Whether or not you care if it fails is directly related to if you value these features in your application. If they are critical to your application, you probably care a lot. If it doesn't matter to you either way or affect your end-user, it's probably not a big deal.
You can find out more about Service Workers and why they only work using HTTPS in the Service Workers API documentation
I'm running a backend app on App Engine (still on the free plan), and it supports client mobile apps in a Firebase Realtime Database setup. When a client makes a change to the database, I need my backend to review that change, and potentially calculate some output.
I could have my App Engine instance sit awake and listen on Firebase ports all the time, waiting for change anywhere in the database, but That would keep my instance awake 24/7 and won't support load balancing.
Before I switched to Firebase, my clients would manually wake up the backend by sending a REST request of the change they want to perform. Now, that Firebase allows the clients to make changes directly, I was hoping they won't need to issue a manual request. I could continue to produce a request from the client, but that solution won't be robust, as it would fail to inform the server if for some reason the request didn't come through, and the user switched off the client before it succeeded to send the request. Firebase has its own mechanism to retain changes, but my request would need a similar mechanism. I'm hoping there's an easier solution than that.
Is there a way to have Firebase produce a request automatically and wake up my App Engine when the db is changed?
look at the new (beta) firebase cloud functions. with that, you can have node.js code run, pre-process and call your appengine on database events.
https://firebase.google.com/docs/functions/
Firebase currently does not have support for webhooks.
Have a look to https://github.com/holic/firebase-webhooks
From Listening to real-time events from a web browser:
Posting events back to App Engine
App Engine does not currently support bidirectional streaming HTTP
connections. If a client needs to update the server, it must send an
explicit HTTP request.
The alternative doesn't quite help you as it would not fit in the free quota. But here it is anyways. From Configuring the App Engine backend to use manual scaling:
To use Firebase with App Engine standard environment, you must use
manual scaling. This is because Firebase uses background threads to
listen for changes and App Engine standard environment allows
long-lived background threads only on manually scaled backend
instances.
I want to send live updates to a phone to my app, approximately 1KB/sec. It is acceptable, if for reasons of power management, the updates will come about once per minute in batches, since Google advises that what drains the battery is leaving the radio on, and that a radio drops power after 15sec. What is the appropriate tool to use?
Websockets/stomp. That's what I am already using for the browser client. However my worry is that it will keep the radio on, and devastate the battery.
Google Cloud Messaging. Google promises that it's battery efficient, however how live is it? Who controls the frequency of pushes? Is it designed for a lot of data? Does it have to put notifications up for every push which would be highly undesirable to me since it's a push every second.
Amazon SNS. I already use Amazon AWS, so it may fit the profile well. How good is it with power management?
Something else that I don't know of
There is now https://firebase.google.com/docs/cloud-messaging/
Firebase Cloud Messaging (FCM) is a cross-platform messaging solution
that lets you reliably deliver messages and notifications at no cost.
and
For use cases such as instant messaging, a message can transfer a
payload of up to 4KB to a client app.
FCM is the new version of GCM under the Firebase brand. (read more about FCM v GCM and limits and pricing)
As you write
the updates will come about once per minute in batches
the server could send a notification if a new batch is ready, instead of every second.
Instead of transferring the payload with the notification, the app could use a HTTP(S) connection to get the payload. This would allow to download all updates in one batch with one HTTP request, which might be more efficient (less overhead).
I'm trying to build a chat/messaging application, which may be consumed on the desktop, but also likely consumed on the mobile web (iOS Safari etc.). I started using the App Engine Channel API, but see that its making a very frequent request to the server (~1/sec). I'm worried this would have an adverse impact on battery life and data consumption.
The application is a chat/inbox type application, so it's OK to be 2-5 secs late IMHO. In this situation, is it just better to stick with traditional polling and ping the server every 3 secs to see if any new messages have arrived? And what would I be gaining by using the Channel API?
The actual experience (and so the tradeoffs) depend on my application, but I'm trying to understand if my worry about battery drain is warranted or unfounded?
All you are seeing is the emulation of the channel by the dev_appserver. Once you deploy it'll work properly, as you expect.
Users will send messages to your server via the usual HTTP methods, and the server will only send messages down the channel when you actually send one.
It's worth mentioning that the channel API removes the need for polling. That's it's purpose.
I do not think there's a way to do this but I thought I'd ask to see what workarounds people are using to avoid polling on Heroku and/or GAE.
How are you sending out notifications in somewhat real-time from these apps?
GAE can use one of the following to notify another system:
xmpp
urlfetch to a callback url
like to pubsubhubbub
send email
With Heroku's new Cedar stack you can do long polling.
There's a link to some long polling example code here.
As #dar mentions, you can use PubSubHubbub to do realtime notification without polling. Nick Johnson has an excellent tutorial on using an existing PubSubHubbub server, or even including a server with your application.
This will let you publish feeds and subscribe to them in realtime without polling.