Push features

[alexblack]

Hi, there are some areas within push that I'd love to see some new features, and I'm interested in contributing.

Would you be open to accepting PRs in these areas:

1. Modifying parse push send to return an ID that can be used to find the push status in the parse dashboard
2. An api to check push status, that takes the above ID as input, and returns which installations the push targeted, and if available any delivery info
3. Make available summary push info on the Installation record:

• most recent push sent I'd
• most recent push sent timestamp
• most recent push sent status (sent, failed, received, opened)

[flovilmart]

return an ID that can be used

The _PushStatus objectId is return as X-Parse-Push-Status-ID response header

which installations were targeted

The full query is stored in _PushStatus

On modifying the installation objects,

I'd rather not introduce side effects on public facing objects, I understand you want that part some analytics.

As for the status of the push, we report a global status, because we don't force the adapters to return a status per push to a certain device. That seems complex to enforce.

[flovilmart]

On another note, even if he delivery through the push adapter is successful, it is not guaranteed that the notification will be delivered. We usually encourage tracking opening on the local device for that purpose.

[alexblack]

I should have started with my goals, sorry :) Here is what I'm looking for out of a push provider (Parse or otherwise):

When sending a push, being able to both query for, and receive notification (via code/api) of:

• which devices pushes were attempted delivery to
• for each device, status of the delivery: sent, failed, received, opened

If you are interested in having these features in Parse server, do you have suggestions on what form of implementation would be acceptable?

Objectives here are:

• know when pushes fail to send
• easily debug push failures and issues
• find devices that have uninstalled the app (or that need action taken to restore push functionality)

Perhaps similar to #2889

[alexblack]

The _PushStatus objectId is return as X-Parse-Push-Status-ID response header

That sounds fantastic. Last I checked (ages ago) this wasn't possible. Do you know if the JS SDK exposes this? It doesn't appear to: https://parseplatform.github.io/docs/js/guide/#sending-pushes

The full query is stored in _PushStatus

Ah I was looking for the installations sent to, not the query. Eg the results of the query at the time of the push.

[flovilmart]

installations sent to, not the query.

The best for that would be a relation, like queryResults that would point to the targeted installations. Do you want to tackle That one?

[alexblack]

I'm interested in adding the capabilities I described above: #2910 (comment)

Is that something you'd be interested in having in Parse Server?

[flovilmart]

Let's start with tracking through a relation the installations. Like I explained above, the main issue with tracking status per installation is that most likely to be an analytics thing, and we try not to store them in as it would make the DB explode very fast.

[alexblack]

Hmm. If you're interested in those features, then I'd propose we discuss (at a high level) what they might look like, and if after that it looks reasonable then I'd be happy to start on one of them.

If on the other hand these are not features you're interested in, then we'd look to use another push solution instead.

[flovilmart]

I didn't say I'm not interested in those features, What I'm saying, is get a knock at it, open a pull request and we'play discuss the implementation details with the base code in, instead of over engineer a specification.

[alexblack]

I think I understood you clearly. I'm just saying I'd like to hear if you are interested in those, and then if you are - spend a few minutes discussing what they'd look like, and then if that looks good I'd love to help out.

[flovilmart]

For:

• which devices pushes were attempted delivery to

Add a key to the _PushStatus Object, which is a relation to the _Installation objects that were intended to be delivered to.

• for each device, status of the delivery: sent, failed, received, opened

The push adapters don't guarantee that the list of status will be sent back per installations, some do some don't, the default push adapter should forward back that information AFAIK.
Look there: https://github.com/ParsePlatform/parse-server/blob/master/src/StatusHandler.js#L145

Note that I don't think it's a good idea to add a new set of reserved columns on the _Installation object to track the status of the last push, first because it's ephemeral, second because you can very well do it yourself. This is an analytics problem an event that should be stored outside of Parse.
Also APNS don't report the push failures synchronously but through a separate listener that is not implemented. GCM, should provide the response back.

spend a few minutes discussing what they'd look like, and then if that looks good I'd love to help out.

Again, you should go forward with what you think is best, then we'll discuss with the code at hand. That's how it should work. For the simple reason that many other people can contribute to the code review/discussions about the implementation. Anything that I can think is good can be challenged by another maintainer, that's why I encourage you to move forward with an initial implementation of the feature(s) you'd like to see.

[flovilmart]

Also, important to note that with medium sized audiences (1000 push to send in 1 query) you will start noticing a bump in memory/CPU usage, above 10k audiences, you may notice complete meltdown of the system.

[alexblack]

This is an analytics problem an event that should be stored outside of Parse.
Also APNS don't report the push failures synchronously but through a separate listener that is not implemented. GCM, should provide the response back.

It sounds like we think about this quite differently. I would like to send pushes, and use a push solution that delivers pushes, and tracks delivery, receipt, and opening. If you're not interested in having these capabilities added to Parse, then we'll likely switch to another push solution.

Again, you should go forward with what you think is best, then we'll discuss with the code at hand. That's how it should work. For the simple reason that many other people can contribute to the code review/discussions about the implementation. Anything that I can think is good can be challenged by another maintainer, that's why I encourage you to move forward with an initial implementation of the feature(s) you'd like to see.

I think its worth taking a small amount of time to discuss before building the entire feature.