Add Parse Endpoint that "sends all scheduled pushes"

[mrmarcsmith]

I have no idea how to cleanly send all of my scheduled push notifications ensuring:

1. the status of that push object is updated appropriately after sending and we don't just create a duplicate _PushStatus object
2. we respect the scheduling rules baked into the _PushStatus object (we don't send too early or skip pushes that should be sent)

I'm hours into researching how to use parse to send "scheduled Push notifications" and this is what I know.

• Parse will never embed a scheduler into the project
• Parse has an optional flag that allows for the "scheduling" of push notifications
• The flag allows for the creation of the "scheduled" push which under the hood makes a "_PushStatus" object with the "status" set to "scheduled"

Describe the solution you'd like
I would like to add a master key protected endpoint, like "/parse/push/sendScheduledPushes" or "/parse/push/sweep", that triggers the sending of all "scheduled Pushes" respecting the scheduling rules so that the scheduler of my choice can just trigger this endpoint on an interval of my choice without having to write a cloud function that requires knowing about all of the details of _PushStatus.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Option B: Would work for me but not for the community
Build out a cloud function that Queries _PushStatus and sends qualifying pushes BUT Since the "scheduling" of pushes is baked into Parse Server I feel like the community would have to dig too deep into the code to understand the details of _PushStatus. whereas it would be simple to trigger the sending of those pushes with just a POST to the proposed Parse Server endpoint.

Additional context
Add any other context or screenshots about the feature request here.

I'm happy to open a PR if this is something that would be considered, I would just need some help with understanding the rules of scheduling _PushStatus.

[davimacedo]

It makes sense for me. I am not sure if it would be better an endpoint at Parse Server or a command at Parse CLI or maybe a separate package. What do you think? @acinader @dplewis thoughts?

[mrmarcsmith]

Thank you for your feedback, The problem I see with a CLI is that everyone's current "Jobs" Schedulers interface through the "/jobs" endpoint. so if we did a CLI people couldn't use the existing scheduler they have for "Jobs" for also triggering the sending of pushs. A separate package doesn't make sense because the "pushTime" is baked into parse server and there is only one "correct" way to use it.

[mrmarcsmith]

Also, I don't think the cloud function alternative would work at all actually because internal access to "pushController" and "StatusHandler" is needed to sent the existing _PushStatus objects and update them in a uniform way. Plus, using the pushController means the endpoint solution would work for ALL existing push adaptors with no changes needed.

[davimacedo]

Take a look in this discussion here and also in this package here.

I don't like so much the idea of the api endpoint because it would lead people to create a schedule to hit this endpoint every min (or every second?). That's why I think that it would be better a process that we can run separately (through CLI or separate package - we can use Parse Server as a dependency in the case of the separate package) ideally listening to a queue or at least querying directly in MongoDB.

[mrmarcsmith]

@davimacedo thank you for the package, that is a valid way of performing this task.

You are correct in assuming that this would lead people to poll the endpoint every minute BUT that is exactly the process we have already been using for the last year to trigger scheduled jobs. I use Kubernetes to manage 30+ instances of Parse Server for a VERY large app. so even at scale polling every minute is a very valid way of using Parse Server.

I would like to make a few points though hoping they warrant the consideration of a PR.

Using the package you mentioned has the following disadvantages:

1. It adds 'required' complexity for people who are new to parse, vs the endpoint creates an "out of the box" solution that can easily be replaced later if desired or needed.
2. deploying and managing yet another "type" of container is messy and complicates dev-ops for small and large deployment vs scaling up one more Parse Server instance which is already configured.
3. I would imagine most users of Parse are already polling their cluster every minute because that is the only way to trigger scheduled jobs, with the proposed endpoint a minor tweak to that system can hit two birds with one stone, triggering both scheduled jobs and scheduled pushes
4. The dedicated "Pusher Program" would sit idle and waist resources when there are no pushes to be sent, vs an additional Parse Server instance using the same resources could be serving requests during that time.
5. The proposed endpoint doesn't force any user to use it, nor does it interfere with the use of the above package if the user decides not to use the endpoint. it does add a simple solution to a very complicated problem should a user decide that polling their cluster every minute and the stress that brings to the server, is a better solution than deploying a package that isn’t as well supported as Parse Server.

[davimacedo]

There is a difference between the scheduled push and the scheduled job. The scheduled job hit the server only when you know that there is some job to be executed while the scheduled push will have to hit the server every minute (or second) just to check if there is something to be sent. So if you don't schedule so many push notifications, you will have to hit the server a lot of times unnecessarily. On the other hand, if you have a large number of scheduled pushes to be sent each time, you may have memory problem with a single container sending all these pushes.

Anyway I think that each approach has its advantages/disadvantages and that's why I brought them for discussion. Besides I personally believe that a separate process would be better, I am not against having it in the API as well. So, if you believe that's actually the best way, go for it and send the PR. I will be happy to review.

[mrmarcsmith]

Thank you @davimacedo! I’ll try to open a PR for this hopefully in the next week!

[mrmarcsmith]

Follow up question, you said we might run into a memory problem with a single container sending lots of pushes, why would a Parse Server instance run into a memory issue and the dedicated pusher not?

[davimacedo]

If implemented by listening a queue, we could have many containers listening to it. So instead of a single container sending the pushes, we'd have multiple ones.

Anyway, I think we can try to mitigate it even in the API approach. What we will probably need to do in the sendScheduledPushes endpoint is (instead of actually sending the pushes) only add the pushes to the normal send flow (that already has the option of working with queue).

[mrmarcsmith]

Yup! thats the way I’ve written it, I have 4 test cases so far but I want more coverage before I open the PR