RFC - Push Notification Implementation / API

[ritch]

/cc @bajtos @raymondfeng

Here is a basic example of working with the push notification API (available in master).

What we have now

var ds = require('./data-sources/db');
var PushModel = require('../index')(app, {dataSource: ds});
var Application = PushModel.Application;
var Device = PushModel.Device;

Application.find({
    where: { name: 'LoopBackPushNotificationDemoApplication' }
  },
  function(err, result) {
    if (err) throw err;
    if (result.length > 0) {
      console.log('Application id:', result[0].id); // hack to get the id for use on the client
      return;
    }

    // Register our application
    Application.register(
      'strongloop',
      'LoopBackPushNotificationDemoApplication',
      {
        id: 'loopback-push-notification-app',
        description: 'LoopBack Push Notification Demo Application',
        pushSettings: {
          gcm: {
            pushOptions: {
              serverKey: 'Your-Server-API-Key'
            }
          }
        }
      },
      function(err, app) {
        if (err) throw err;
        console.log('Application id:', app.id);
      }
    );
  }
);

app.post('/devices/:id/notify', function (req, res, next) {
  var note = {
    text: '\uD83D\uDCE7 \u2709 Hello',
    sender: 'gcm loopback app'
  };

  PushModel.pushNotificationByRegistrationId(req.params.id, note);
  res.send(200, 'OK');
});

Here are the issues I see with the current API (referencing the example above):

1. You have to dynamically create an application object. IMO this is a pretty bad approach. Almost everything depends on this object, and specifically the app's id. This should be available from a config file or statically somehow. It should be reference-able from clients and within node (by a static id perhaps) before it is even created.
2. It is also difficult to know that a push notification has failed. There isn't even a callback which at least could include potential timeout errors.
3. The notify API is surfaced as POST /devices/:id/notify. I think this can be improved. We should have a Notification model with a remote-able send method, similar to MyModel.create.

What I think we should move to

var Notification = loopback.Notification;
var Application = loopback.Application;
var Device = loopback.Device;

var androidApp = new Application(
  {
    org: 'strongloop',
    name: 'LoopBackPushNotificationDemoApplication',
    id: 'android-app',
    description: 'LoopBack Push Notification Demo Application',
    pushSettings: {
      gcm: {
        pushOptions: {
          serverKey: 'Your-Server-API-Key'
        }
      }
    }
  }
);

console.log(androidApp.id); // 'android-app'

androidApp.save();

app.model(Notification);
app.model(Device);

// from client over rest
// POST /notifications
// {
//   text: '\uD83D\uDCE7 \u2709 Hello',
//   sender: 'gcm loopback app',
//   deviceId: 'my-device-id'
// }

[bajtos]

You have to dynamically create an application object. IMO this is a pretty bad approach. Almost everything depends on this object, and specifically the app's id. This should be available from a config file or statically somehow. It should be reference-able from clients and within node (by a static id perhaps) before it is even created.

The idea is to have multiple mobile apps connected to the same LoopBack server. The Application Model refers to a mobile application.

My original feeling was the same as yours - applications should be defined & configured statically in a config file. But I can imagine another approach too, where you create new applications "on the fly" in a running loopback server.

[raymondfeng]

1. You don't have to dynamically create the application object. There should be a developer on-boarding process/portal to sign up new applications. It would be something similar to https://developers.facebook.com/apps. As part of the application signup, we should be able to configure the push settings. After you sign up, you should receive the application id and key.
2. We can enhance the error handling and troubleshooting. The tricky thing is that APN doesn't ack if the message is accepted. It's fire-and-forget best-effort.
3. There are more remote APIs, such as:

pushNotificationByRegistrationId
pushNotificationByApp
pushNotificationByUser
pushNotification (by device token)

[raymondfeng]

Most of the issues should been addressed now. The push demo app also has a simple UI to sign up new client applications.