What is on Your Mind?

Update:

UserCP Screeching Frog 0.7603

Still working on tweaking the list of users in live chat.

Code:

updated() {
    this.updateCount++;        // initially set to zero in data()
    if (this.updateCount % 5 === true || this.updateCount == 2) {
      this.getHereNow();
    }
    //console.log("update count", this.updateCount);
  },

It is interesting to console.log() the updateCount var.

For this page, after the initial page mount, updateCount == 2, so I set the logic to call this.getHereNow(); (again) testing, as it was also called when the page was first mounted (so this is a test, not final answer).

Then I noticed if we receive a new pubnub message the count is incremented by around 5. So for fun, I set this.updateCount % 5 == true but this is really just overkill, because I also call the same method when a message is received. so if I go with this kind of approach, using the view update() lifecycle hook, then I can get rid of the calls to the same method in other parts of the code and control the logic from update().

The problem I am trying to solve is that sometimes when a user enters live chat (that also includes "self"), their occupancy and name (uuid) does not appear correctly above the message window. As soon as a message is processed, all is updated because I call getHereNow() when a message is received.

Of course, if I setpubnub.subscribe() presence TRUE, this problem can be easily solved, but then the API pings the pubnub network every second or so, flooding the network with presence pings from the browser. This is not scaleable.

Hence, the best way forward, in my view, is for PubNub to include a new configuration timer in the pubnub.subscribe() so we can control the frequency of the pubnub presence pings (polling) in the browser.

Or maybe I am just missing some more obvious way in the PubNub SDK to do this more correctly?!

Neo -

If I understand, you are calling hereNow every 300ms, which is a lot.
Assuming that is the case, you should only call hereNow upon successful subscribe to a channel (in the status callback for PNConnectedCategory).

When you subscribe to a channel(s), subscribe withPresence:true to get the realtime updates for others' join, leave, timeout and state-change.

Not sure what the presenceInterval property would do in the subscribe. I think you are assuming that presence is polling for changes. But it is actually receiving new presence events (in the addListener's presence callback) just like you receive published messages in the message callback. withPresence:true actually just adds an additional channel for each channel you subscribe to. If you subscribe to channel abc then withPresence:true will also add channel abc-pnpres.

Hope that provides some insights.

Cheers
Craig

No Craig,

We are not calling hereNow every 300 ms.

LOL The function in updated() does not even fire, as I described. I don't think you fully understand how Vue.js lifecycle hooks or the JavaScript debounce() function works.

The updated() lifecycle hook in Vue.js only fires when there is a Vue.js event. In this code, that means it on fires on the events I described above.

Even when update() fires, the debounce() function does not fire because it fires only on the trailing edge of 300 ms and that function does not exist (the instance) because the update() lifecycle hook has already exited.

As I said above, that line of code does NOTHING. And in the current version running, it is commented out, since it does nothing.

Regarding PUBNUB.

Frankly, I feel in your replies that you may not fully understand your own API. Perhaps you have not actually every analyzed the XHR calls in DevTools looking at the code under various conditions? It seems you are advsing me from theory (from reading the API docs), not practice (coding and doing the analysis of the XHR calls).

Your API polls presence interval is based on subscribe() (presence set to TRUE). That is not the same as from the pubnub listener. It does not set the presence polling interval.

Yes, the listener listens but the polling is fired every second based in the client when presence is set to TRUE in subscribe.

I have already analyzed these API calls in Chrome Dev tools and it's easy to see what is going on,

You seem to not understand that your API polls presence every second (when it is set in subscribe to TRUE) and there is no way to set that interval in your API.

This generates 100s of thousands of useless transactions because every subscriber is polling the pubnub network every second or so when the subscribe presence TRUE.

I have been over this very carefully in Chome DevTools watching how each flag effects the XHR calls.

Then, again, I could be wrong, LOL... but I have been over this very carefully in Chrome DevTools many times for hours.

Neo -

I just ran the chat app (should have done that first) and I see what is causing the every 10s transaction. Your Presence add-on has a Presence Interval of 10s (that is the default) and you set your Announce Max property to 1, that's 1 channel occupant (20 is the default). So PubNub is sending an update every 10s.

Announce Max
Once the number of occupants reaches this number, join, leave and timeout events are no longer sent as realtime presence events to those listening (subscribed withPresence:true). Instead, PubNub Network will send an occupancy count every 10s (or whatever the value is for the Interval property). If you want to know who join, leave, timeout since the last interval update, you need to enable Presence Deltas.

My recommendation: set Announce Max back to 20. A different number may be better, but that should suffice for now. Rarely is this value ever changed for most apps. I took the liberty of updating this property to 20 to prevent your account from accumulating needless transactions. They were not benefitting your app in the slightest anyways. You would need to enable Presence Deltas for that Announce Max = 1 setting to be useful and then you would have to handle the presence delta event payload in your client app, which I don't think you are doing at the moment. You can set this back to 1 if you feel that is what you need.

Let's schedule time for a PubNub overview session and I can give you all the ins and outs, gotchas, best practices and how it works under the covers so you can make the best informed decisions with your implementation. I know I can save you hours of frustration and you'll appreciate how this all works much more.

Cheers
Craig

--- Post updated at 03:32 PM ---

Tim - I understand our APIs quite well. Your app, not so much, admittedly. Not a Vue expert. See my last post.

Thanks Craig,

I'm glad you understand your API very well.

I was beginning to wonder with your first reply today, when you did not understand how the Vue.js lifecycle hooks work or what happens with debounce() when it fires on the trailing edge of an interval in a Vue lifecycle hook.

Regarding the PubNub API, thanks for assuring me you understand it.

I still think PubNub needs a new configuration parameter in subscribe() which sets the polling interval for presence, but let me take another look tomorrow since you have made some changes in our configuration and see if I set subscribe presence to TRUE in my code (it is current set to FALSE), if it keeps polling and polling like crazy.

I am sure I do not understand your API as well as you, but I do make subtle changes in the code and watch the XHR effects and what is going on in Chrome DevTools, in great detail

I don't use Vue.js and I have never heard of the debounce API. Neither is specific PubNub and there are dozens of JS frameworks out there so not possible, or necessary, to know them all.

I still think PubNub needs a new configuration parameter in subscribe() which sets the polling interval for presence, but let me take another look tomorrow since you have made some changes in our configuration and see if I set subscribe presence to TRUE in my code (it is current set to FALSE), if it keeps polling and polling like crazy.

Subscribe already has an interval, it is the subscribeTimeout config, that you can set in the PubNub init, but please do not. It should only be changed for very specific reasons, that I will not get into right now. You will only cause your app to have increased transactions at no additional upside or cause your app to break depending on whether you set it shorter or longer. The default subscribeTimeout is 280s, and this is exactly the same for listening to presence events because it is on the subscribe connection. The hereNow is a completely different API and a different connection which does not work on the subscribe connection.

When you subscribe withPresence:true, you are just adding presence channels (with the -pnpres suffix) to the list of subscribed channels. When another person subscribes to that channel, those listening to presence events (withPresence:true) on that channel will receive that presence event, in realtime, not on some polling cycle.

But see my response about Announce Max. The increased transaction were self-inflicted Not that you would have known the side effects but rarely does anyone change that setting.

And I just checked the chat app again. It appears you upgraded to lastest PubNub JS SDK version - cheers - and I see that the client is not having the 10s interval response anymore. At most it will be 280s or everytime someone joins, leaves, timeouts, or a message is published and therefore received.

Cheers
Craig

Hey Craig,

i have been using the latest Node.js SDK since day one and have not ungraded since my initial node.js install.

You "lost me" on your "upgrade" comment.

Was there a new version released in the last week or so?

I have only used one SDK version, the initial version I originally installed.