For my current web (reactJS) app, i need to implement a push notification system. Backend APIs are written in Python on Django Framework. So how should i implement socket, should I write in python, or may I write in node or node for the client-side and python for the server-side?
Are you looking for Web push or mobile app? The term push is really synonymous with 'push notifications' meaning the client will get them even if the app / website is open or not.
If that is what you are looking for then you need to be looking at service workers and push notification servers.
If you want to simply send alerts to users on your page you can for sure use a simple websocket or long poll done in JS with a node server to emit to.
Related
I am having an API locally hosted in one of the servers (LAN). What I am looking to understand if it is feasible to enable push notification from the server in case of a record entry. Every time a post request is made to the local server, Is it possible to push a notification to a certain mobile device? Please note, I am not considering push notification from web services such as google, Azure, Firebase etc.
It is feasible.
As Sushi said, you can use WebSockets or other Sockets to keep connect between Apps and Server. When client connected to your server, server will record which app is connecting.
By the way, you can custom notification's url between server and app.Use some special characters to distinguish between your various parameters, such as &/[ ]. You are free to set the header and body style of the message. Also, when your message needs to be encrypted, some encryption methods can be used.
Here is a similar discussion about Building an Android notification server can be refer .
I am working on a project which is basically a Customer Feedback Analysis Dashboard. There are few graphs on the dashboard and data for each graph is fetched from the server through API requests.
Right now the dashboard is updated every time the page is refreshed. I want it to be updated immediately when there is a new feedback in the system. I am confused, whether I use websockets to send data for each graph or just a flag and use that flag to fetch data through API requests.
Like, facebook/twitter does. They tell you about new posts/tweets and when you click that button your feed/wall gets updated.
If you want to "push" data from server to client and you want that data to show up in a timely fashion (e.g. within 10-20 seconds of when it was available on the server), then you will want to implement some sort of "push" solution where the server can efficiently push data to the client whenever there is new data to send.
There are several possible approaches:
webSockets
socket.io
Server-sent events
Mobile platform-specific push (Android and iOS)
For a general purpose solution that works within a browser, you will want to use one of the first three. socket.io is built on top of webSockets (it just adds more features) so architecturally, they are similar.
Server-sent events are fairly new (modern browsers only) and are only for one way communication (from server to client). webSockets can be used for communication either way.
I'd personally recommend socket.io because of the features it offers (such as automatic client reconnection) and a simplified messaging layer. You can see the feature difference between socket.io and webSockets here. With socket.io, the client makes a connection to the server when the web page is loaded and that connection is persistent. After the connection is established, then either client or server can send messages to the other at any time in a very efficient manner.
Other useful references:
Push notification | is websocket mandatory?
websocket vs rest API for real time data?
Why to use websocket and what is the advantage of using it?
What are the pitfalls of using Websockets in place of RESTful HTTP?
Ajax vs Socket.io
Firstly, here is state of my application:
I have a request coming in from a client (angularjs app) into my API (web api 2). This request is processed and a record is stored in a database. A response is then sent back to the client.
Currently, I have a windows service polling and processing this record(s).
Processing this record can be long running. As a side effect to processing this record, there might be notifications generated to be sent back to one or more clients.
My question is how do I architect this, such that I can utilise SignalR to be able to push the notifications back to the client.
My stumbling block:
I can register and store (in-memory backed by a db) the client's SignalR connectionid along with the application's own user identifier. This way I can match a generated notification with a signalr client.
At the moment, I'm hosting the SignalR hubs within the IIS process. So how do I get back from the Windows Service to IIS to notify the client when a notification is generated?
Furthermore, I should say I am already using SignalR elsewhere in the application and am using a SQL Server backplane.
The issue's with the current architecture:
Any processing is done in the same web request, and notifications are sent out via SignalR before a response to the client is returned. Luckily, the processing is minimal and very quick.
I think this is not very good in terms of performance or maintenance in the long run.
Potential solutions:
Remove SignalR hubs from IIS and host them somewhere else - windows service?
Expose an endpoint on the API to for the windows service to call to push the notification once a notification is generated?
Finally, to add more ingredients to the mix: Use a service bus to remove the polling component of the windows service, and move to a pub/sub architecture. Although this is more work than I want to chew off right now.
Any ideas/recommendations/constructive criticisms are welcome.
Thanks.
Take a look at this sample for starters
Another more advanced solution can be using a backplane to manage the communications between the front end and the backend...
HTH
I'm new to ServiceStack and want some validation on a pattern we're thinking about using.
We want to use ServiceStack with Xamarin and Message Queues. While I understand how REST works under the covers, I'm not sure how the Message Queues on ServiceStack work and if its appropriate for mobile devices.
Specifically we know that all mobile devices are essentially behind a NAT firewall setup by the Telco. Meaning Clients can talk to servers, but servers cant talk directly to clients, without the client talking first.
While the concept of a ServiceBus is designed specifically to handle this case, i'm not sure if its "mobile network friendly".
I would assume that the client side implementation, would need to work in one of two ways: polling, blocking get.
Polling would have the client side frequently runing a Http GET to ask the server if anything is available on a queue. A Blocking Get would, perform a Http GET but have the server return nothing until data is ready. Or is there another technique that i'm missing?
If it is a poll, is there any way to control the Poll frequencies in service stack. If its a blocking get how is this configured..
What happens when the app goes to the background, do we need to cancel the connections manually. etc.etc.
We tool an old version of the ServiceStack client library and ported them to xamarin. We now see that the latest ServiceStack client side library is Xamarin compatible.
So, basically my question is: Had anyone used Message Queues from a Xamarin Mobile to ServiceStack with RedisMQ or other server side message queue.
I used webApi for create web Service and provide Web services to mobile Android/Apple programmer. I want to send a notifications for mobile when the database has changed. I searched on the internet and found that i can use PushSharp or Signal R. Which is the best option ?
It is really depends !!
if you want Notification server for mobile app i think PushSharp is good solution it's built as Push Notification framework for mobile app it is depends on GCM (google cloud messaging API ) it's full free API from google .
I think this task is not for signalR .
signalR is a framework for building real time apps you can Implement any Scheme like pub-sub .
what i know there is a client implementation for signalr for android called :
SignalA : URL : github.com/erizet/SignalA
So if you want to send Notification to Mobile app you can use one of
those :
PushSharp
PushBots
i found pushsharp more reliable .
and has a big community .
also you must consider what your mobile app developer good at ??! .
As Khairy said, SignalR and PushSharp do very different things.
SignalR is a real-time web framework. It is best suited to real time, two-way communication between a client and a server. It requires that your client application be in constant communication with your server.
PushSharp is a push notification library. It is used to send, well, notifications. The act of sending a push notification to a client is inherently one way, and might not happen in real time.
If all you really want to do is send notifications, I see no reason why you wouldn't want to use the right tool for the job. In this case, PushSharp is the right tool for the job.