Currently we have an application that, upon certain events, will send notifications to users. We use SQS to handle the actual delivery of the notifications.
As an example, when a user registers an account we will create a new push notification task (put onto an SQS queue) that will send them a push notification using OneSignal.
It's been working well for us so far and notifications are delivered pretty quickly.
My question is why are websockets typically advocated as the go-to architecture for when setting up a push notification service when the above model seems like it's just as good, if not better? Am I missing something?
2 Answers 2
OneSignal is a service that is implemented by sending notifications to Google or Apple, who in turn wait for target devices to come on line and pass on the notifications.
WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. This is a much more general architectural component, which can be used to solve a wide variety of application problems, including but not limited to notifications. Its quite possible some part of oneSignal notifications uses webSockets internally, but I don't know this.
Comparing OneSignal to Websockets is like comparing a car to an engine.
In answer to your question, you are not missing anything, you are correct to use a public service if suits your needs!
However in some situations (say a highly secure military system) people may be worried that OneSignal could be hacked, or service could be interrupted etc and so build their own.
WebSockets is a technology that allows 2-way communication between a client and server with a single open TCP connection, whereas SQS and OneSignal are products built on top of this technology and other message delivery protocols.
Explore related questions
See similar questions with these tags.