0

I have developed a push notification engine in AWS Lambda, using One Signal over https, and it is working just fine. I can trigger notifications based on incoming IoT rules and send them off in near real time.

async function sendNotification(data, api_key) {
    
    console.log("Data to POST : " , data);
    const response = await new Promise((resolve, reject) => {
        
        var headers = {
            "Content-Type": "application/json; charset=utf-8",
            "Authorization": api_key
        };

        var options = {
            host: "onesignal.com",
            port: 443,
            path: "/api/v1/notifications",
            method: "POST",
            headers: headers
        };
    
        const req = https.request(options, function(res){
            console.log('statusCode:', res.statusCode);
            console.log('headers:', res.headers);
            res.on('data', (data) => {
                var buff = Buffer.from(data, 'utf8');
                console.log('data received: ',  buff.toString());
            });
        });
        
        req.on('error', (e) => {
            console.error(e);
        });
        req.write(JSON.stringify(data));
        req.end();
        return;
    });
    return response;
}

The condition to cause this code to run can trigger many times per day. The problem is that I need to only send notifications up to a maximum of once a day in some cases, and sometimes only if a previous notification has been sent to that user. My issue I suppose is where is the best place to store state?

  1. Is there is a way of scheduling the notifications in an idempotent way so that rather than send multiple, subsequent calls would overwrite each other, and result in just one call? Could SNS be used somehow?

  2. Another thought was using device shadows. Is this a possible solution where the state could be stored there and used to ensure once and only once delivery of a first notification when needed and escalate to send more serious notifications, when required?

monkey
  • 1,213
  • 2
  • 13
  • 35

1 Answers1

0

You can create a schedule within EventBridge to run once per day. Whenever this schedule turns into an event sent downstream; it will have a unique event-id. You can use this event-id (perhaps persisted in a database or temporary cache) to ensure you only trigger once.

Alternatively, you can record last invocation for any customer and then check it each time elapsed before making the next call.

blr
  • 908
  • 4
  • 8
  • I came up with a good answer. Tucked away in the onesignal API, there is a parameter called 'external_id'. Despite it's completely unrelated name it actually acts as a uuid for the notification. By sending potential duplicates with the same uuid, you are instructing the onesignal API to destroy duplicates. I then wrote a function to convert each duplicate scenario into a valid UUID; one input to the UUID creator being the period (wither daily or weekly). This ensures timely delivery of the first notification, and ignores duplicates within the required timeframe. – monkey Jan 01 '21 at 06:34