Can you please explain how the Push Notifications pricing work?
For example:
If I send a notification to 1000 apps, is that 1000 notifications, or 1 notification?
If I send a second notification to the same 1000 apps, is that another 1000, 1 or 0?
Are you counting pure number of notifications sent, or number of “apps” receiving notifications? The latter counts far less notifications, because once an app have received a notification, that’s a count of 1 for the month, and no more regardless of the number of notifications sent to that app.
The reason I ask is two-fold:
the terminology you use, that is: “Number of native push notifications delivered by Backendless”, then the number is 1,000,000 (or 5,000,000). However, underneath the number you state “$0.05 for extra 1000 recipients/month”. The word “recipients” here suggests “apps” to me.
Other BaaS providers use one or the other, i.e. some use pure number of notifications, some use number of recipient apps receiving.
Can you please clarify?
Also, is the pricing model for Push Notifications the same, or different to Pub / Sub messaging?
I do not quite understand the terminology you you used when you say “deliver to an app”. A push notification is delivered to a device. Such device must use the registration API call in order to be able to receive a notification. As a result, all push notifications will be delivered within the context of a single app. As for the pricing, it is the total number of notifications delivered. When you sent one to 1000 devices, that’s 1000 push notifications, when you send it again to a 1000 devices, that’s 2000 in total.
Push notifications are counted differently than pub/sub messages and thus have a different pricing calculation.
Thanks for the info. What I meant by “delivered to an app” was exactly what you said. To me, an app registers to receive notifications, then notifications (of a specific pattern as per the registration) are delivered to the device, and thus the app.
Okay, so what you’re saying is that notifications are counted by the number sent, not by the number of devices registered. Other providers count by devices, so it wouldn’t matter how many notifications I send to a device, it’s counted at only 1 (for the entire month) as soon as the first notification is sent. (That is my understanding anyway).
You say that push notifications are different to pub/sub, what is the difference in pricing strategy?
Yes, notifications are counted by the number of messages sent, even if they go out to the same device.
As for pub/sub vs push, I should’ve said “counted separately” rather than “differently”. As a result, you will see two line items in the pricing table: “push notifications” and “pub/sub messages”.
That discounts using notifications or pub/sub for my new app, in the short term unless it requires Enterprise down the track
Can I please ask a couple more questions?
I’ve not used pub/sub before. Is it the same as pub/sub notifications under the covers? Or is more reliable, like have a async callback, guaranteed to be delivered?
Also, I noticed in your high-level architecture diagram that there’s a cache layer in their. Does that mean if I request the same object / list of objects from a table, or more precisely the same query, I’ll get it from cache? If so, what are rules of this, by backendless app, or by device, or something else, e.g. I can configure it?
I would not discount it for long - we’re planning a significant overhaul of pricing which will change things quite a bit.
The concept with pub/sub is the same, however there are some differences:
Push notifications are sent via intermediary servers of Google, Apple and Microsoft. Pub/sub messages are handled entirely by us.
Pub/sub offers additional message filtering mechanism with SQL selectors and sub topics (see the doc for details).
With push notifications your app does not need to be running and or be on the foreground. With pub/sub it must be an active app.
Regarding caching: we do not cache the actual data, however, you can do that in your app using the Caching API: http://backendless.com/documentation/utilities/rest/ut_caching_rest.htm
any new on the new pricing tiers yet? The reason I ask is that I’m design my game to use polling (queries or cache), rather than pub/sub due to the potential costs.
A couple of questions regarding my approach:
I’m playing with caching now. Was wondering how much faster it would be compared to doing a find with a query? If there are 1000’s of users, would it be preferred if they are all getting the same data?
On the converse, if 1000’s (or more depending on number of players) of apps need to create a row in a table (all unique), and near concurrent, would the backend handle this? Are there better ways? I can’t use the cache due to object count constraints , i.e. max of 1000 (e.g. send to cache, then asynchronously push to db).
Before I answer your questions, could you clarify what role cache is playing here? It is confusing to me when you say “polling (queries or cache)”. These there entities (1)polling, (2)queries, (3) are all very different. Can you share more details on your approach?
I have a “game server” that manages the game. It uses backendless as it’s store. It cycles createing a new game every few minutes. The game runs through several stages during this time, and completes, before the next game starts.
Each app (iOS, Android, etc.) will join the game (authenticated) (i.e. call to backendless), and retrieve the current game state (call to backendless), and if at the right stage, can join that game be creating a record, unique to the app (call to backendless). Once the game is complete, the “server” calculates the results (which is my biggest headache, because it needs to update or create a record (in backendless) for every player/app currently playing. Finally, when that is done, each app need to get back their state (backendless). As you can see, there are a lot of backendless calls from apps.
Other than login, the comms could be done with notifications and pub/sub, between the “server” and the app. However, since there are potential 4 or 5 notifications / pub/subs per app, that becomes a lot as you scale the number of apps.
This is very helpful. Without knowing additional details, it seems to be, you should be able to do it without any push notifications at all. To clarify further:
When you say "the 'server' calculates the results", do you mean your server or the server-side code running in Backendless?
Also, do the apps (the client-side) know when a game is over? If they do, can't they periodically poll the Backendless server until they get a sign that the "server" from (1) is done with its task? Of course, it would be cleaner with a push notification (there would be only one as I understood it), but I am also thinking about alternatives.
Regards,
Mark
The “server” is my code (nodejs) calling backendless, it’s not running in backendless.
By the way I have no issues with getting my app running, the app knows when everything is going on. My questions were more about what it the most optimal.
My server has one area where it has to do a large amount of processing with updating a record for every player at the end of game. Maybe that needs to be done on backendless.
My app needs at least 3 calls to the server per game I.e. (new game, submit result, end game), or 1 call (submit result), 2 notifications (new game, end game)
I am not really getting the understanding in these; Counting push notification per total number of pushes sent across all devices each month and paying $0.05 for extra 1000 recipients/month.
Are notifications counted per recipient devices or total number pushed across to all recipients
