On my site I'd like to do push notifications of comments like Stackoverflow does. Amazon SNS/SQS seems to provide a framework to do this but I'm having difficulty finding any code/explanation on the web for anything beyond a "hello world" equivalent.
From reading the AWS SNS/SQS documentation it looks like I need the following:
logic:
PHP on the page where comments are posted (http://mysite.com/postCommentOrAnswer.php):
$comment=$_POST['comment']; //posted comment
require_once 'application/third_party/AWSSDKforPHP/sdk.class.php';
$sns = new AmazonSNS();
$response = $sns->create_topic('SO-like-question-12374940'); //create topic
$response = $sns->publish(
'arn:aws:sns:us-east-1:9876543210:SO-like-question-12374940',
$comment
); //publish comment
$response = $sns->subscribe(
'arn:aws:sns:us-east-1:9876543210:SO-like-question-12374940',
'https ',
'https://mysite.com/notificationsReceiver'
); // Subscribe to notifications
PHP on the page where notifications are received (http://mysite.com/notificationsReceiver.php):
no idea, thoughts?
Obviously, this is not close to being a complete demonstration and probably has some incorrect function calls but I was wondering if someone might be able to help build upon this?
SQS cannot publish messages to SNS. SQS can only store the messages. You have to pull the message using SQS Api's.
SQS does not push messages to the consumers, instead, consumers have to poll the queue, and as soon as one of them receives a message, the message is out of the queue and no other consumer can access it. This polling inevitably introduces a certain latent delay in message delivery.
With SQS, messages are delivered through a long polling (pull) mechanism, while SNS uses a push mechanism to immediately deliver messages to subscribed endpoints.
Amazon SNS allows applications to send time-critical messages to multiple subscribers through a “push” mechanism, eliminating the need to periodically check or “poll” for updates.
Your comment implied that you are not wedded to SQS, so I am answering with a MySQL solution.
Unless you're dealing with so much traffic that messages would actually ever get queued, I'd recommend just a simple MySQL table approach.
I have a site with a MySQL notifications table that looks like this:
CREATE TABLE `notification` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`user_id` INT(11) NOT NULL,
`notification_type` ENUM('inline','popup') NOT NULL DEFAULT 'inline',
`html` TEXT NOT NULL,
`entered_date` DATETIME NOT NULL,
`display_date` DATETIME NOT NULL,
`show_once` TINYINT(1) NOT NULL DEFAULT '0',
`closable` TINYINT(1) NOT NULL DEFAULT '1',
`destroy_on_close` TINYINT(1) NOT NULL DEFAULT '1',
PRIMARY KEY (`id`),
INDEX `user_id` (`user_id`)
)
COLLATE='utf8_general_ci'
ENGINE=MyISAM
This table is checked upon page load and the proper notification is displayed according to the notification data. Insertion is done as various actions or events occur on the website.
I'm at well over 10,000 users and so far this approach has not proven to be a bottleneck for the site. I don't expect it to anytime soon, either.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With