pushpad/pushpad-ruby

Ruby library for the Pushpad API: the easiest way to send push notifications from websites and web apps.

pushpad-ruby's Issues

Getting subscription counts

I'd like to add a way to use the new X-Total-Count header of the GET /projects/PROJECT_ID/subscriptions REST API endpoint to make count queries. The API could look like this:

Pushpad::Subscription.count(project_id: 5) # => 100
Pushpad::Subscription.count(project_id: 5, uids: ['user1']) # => 2
Pushpad::Subscription.count(project_id: 5, tags: ['sports']) # => 10
Pushpad::Subscription.count(project_id: 5, tags: 'sports && travel') # => 5
Pushpad::Subscription.count(project_id: 5, uids: ['user1'], tags: 'sports && travel') # => 1

project_id would be a required option if it has not been defined globally.

Exception Class for Connection Errors

When communicating with Pushpad from background jobs, sometimes there are errors when connection problems occur or when the site is under maintenance etc. Since these errors are of a temporary nature, I'd like to have an easy way to ignore them in exception notifications or add some special logging.

Since pushpad-ruby currently simply uses Net:HTTP, there is a rather wide range of possible errors I have to look out for. So far I've seen Errno::ECONNRESET and Net::OpenTimeout, but looking at Faradays Net::Http adatper it seems like there could potentially be a whole lot more.

Then there are more specific errors like Pushpad::DeliveryError which normally point to domain level errors (i.e. failed validation) but at the moment also come up when Pushpad responds with 503, which is also rather one of those recoverable transport level errors.

Ideally there would be an exception base class like Pushpad::ConnectionError that encapsulates all of the different Net::HTTP errors. This would make handling these errors very convenient.

In addition it might make sense to add more exception classes for specific HTTP response codes (422, 404, 403, 503).

For the first part I see two options:

• Rewriting Pushpad::Request to use something like Faraday, relying on its unification of connection errors and re-wrapping its exceptions to decouple the public interface of this library from the HTTP client library choice.

• Port some of Faraday's exception handling code if the goal is to keep having no gem dependencies. For a lightweight library this one, that might be a selling point.

Getting notification data

It would be nice if the library allowed getting notification data via the GET /notifications/NOTIFICATION_ID REST API endpoint. In particular, this would be useful to get statistics data like successfully_sent_count or open_count.

I could imagine the following interface based on a find method and further attribute readers.

notification = Pushpad::Notification.find(id)
notification.open_count # => 4

Then it would probably make sense to store the attributes that are currently the return value of deliver_to:

notification = Pushpad::Notification.new({
  body: "Hello world!",
  title: "Website Name"
})

notification.deliver_to(user)
notification.id # => 1000
notification.scheduled_count #=> 10

One thing to consider here is that the Notification class currently is more like a notification factory or builder. Calling deliver_to multiple times creates multiple notifications with different ids. I'm not sure if this is an edge case that should just be ignored by overwriting the id attribute in this case. Alternatively, one could raise an error when deliver_to is called and an id is already present, but that would be a breaking change to the API.

To circumvent this issue, we could also consider adding a whole new class, e.g. DeliveredNotification, which provides the find and reader methods. That way the concerns of delivering notifications and getting data about past notifications would be separated cleanly. deliver_to could even return a DeliveredNotification which could implement [] to stay compatible with the prior hashed based API.