So what I need is a kind of a push and pull web service mechanism; Certain devices will be sending data to my parse backend and some others should be able to receive the newly added data as it's being added. Think of it as a restaurant environment where customers send their order via their phones and the restaurant manager receives the orders on his pc real time.
I know I can use push notifications but I want to target specific users (in this case the manager alone). I guess I can have a specific push notification channel in which only the manager is added, but I am not sure if I can send proper json data in bulk or just simple strings. Maybe there's a smarter way of going about it.
Any suggestions?
Many thanks,
Polis
You can use the Parse Cloud for this purposes. So certain devices (you can differentiate in cloud or in client side) can call the cloud method. The called cloud method can make http request to your server (manager pc real time). From now on your server side can deliver coming message to your manager in real time. In this solution, I assume that you have your own server for web users (like manager) and mobile application for client user (customers).
Hope this can give you an idea. Regards.
You can use Push notification for this purpose. In my opinion that would be your best option.
When registering for push notification on client side, you can set a column owner to user pointer. Now when sending push notification from one user to another you can query the Installation class for other user's pointer. You can send push notification either from client side or writing cloud code for afterSave trigger. Cloud code is a better option.
The downside of this approach is that if other user did not allow push notifications then this would fail. The second user would still be able to get the data when they open the app, but won't get push notifications.
***I built a chat app using this approach on Parse.com
You don't need a complicated channel setup, before you save your installation, do a line like this:
[installation setObject:[PFUser currentUser] forKey:#"owner"];
[installation saveInBackground]; // ... completion or whatever
Then, just query:
PFQuery *installationQuery = [PFInstallation query];
[installationQuery whereKey:#"owner" equal:userImLookingFor];
Then, it's like PFPush w/ query or something.
(I'm typing from memory, so some of these might need to be slightly tweaked)
Related
I want to develop an application where I want to push the messages (or data) to UI from backend Spring boot application.
I have the following requirement -
Consider there is a REST service that accepts the data from other applications using the POST method.
This data will be pushed to UI.
OR
Consider that there is a background process running which generate events and we want to push these events to UI.
For this, I came across about the WebSocket component that we can use in the Spring Boot application.
However, is there any other settings required to make it possible to push the incoming data to the UI?
Any help is appreciated.
Thanks,
Avinash Deshmukh
The backend cannot magically push updates to a client UI. The backend will have no way of knowing where the UI exists (i.e. what the UI's ip address is) and even if it did, it may not have access to establish a connection (due to firewalls or a NAT).
For this reason a client UI has to request updates. One way this could be done would be to have a timer in the UI application that polls for updates via REST. But this is essentially what websockets do - with much less overhead.
This is how common applications that you use everyday work all the time. So I'm not sure why you do not want to go down the websockets route.
...
Starting with Spring 5.0.5.RELEASE, it isn’t necessary to do any customization because of the improvement of #SendToUser annotation, that allows us to send a message to a user destination via “/user/{sessionId}/…” rather than “/user/{user}/…“.
That means the annotation works relying on the session id of the input message, effectively sending a reply to destination private to the session:
...
There is a good example over here:
https://www.baeldung.com/spring-websockets-sendtouser
The Problem
We are currently architecting our new Notification Microservice but having trouble with how to handle aggregated emails. What we need to do is instead of sending one email every action performed (could be 20+ in a few minutes), we would send an email after an hour summarising all the actions that were completed.
What We Have So Far
We so far propose that we have this type of messaging pattern, where Client Service is any service in our cluster and Messagebot is our Notification Microservice.
Client Service sends a notification to Messagebot that it will need to send something in the future
Messagebot stores the details in its database
Messagebot periodically checks its database for what needs to be sent
Messagebot gets the required data from another service (could be Client Service) via API
Messagebot sends email using the data from #3 and an HTML template
The Debate
For the data that needs to be sent, we are less sure and it is what we need help with. So far we think this should be the structure of the JSON from Client Service to Notification Service (step #1):
{
template_id: SOME_TEMPLATE_ID,
user_id: SOME_USER_ID,
objectid: SOME_OBJECT_ID
}
or
{
template_id: SOME_TEMPLATE_ID,
user_id: SOME_USER_ID,
required_objects: { task_id: SOME_TASK_ID, document_id: SOME_DOCUMENT_ID }
}
Where task_id and document_id are just examples and it would change based on the template. It could just as easily be {product_id: SOME_PRODUCT_ID} for a different template.
Why The Debate
Our thoughts so far are that:
We only need template_id because the source of the data would be implied in the objects (like an ENV var). For example, the Task object would be at http://taskservice/:id. Otherwise, we can have problems with failing APIs or switching URLs in the future.
We should use userid instead of email and name because we prevent the issue of email/ name pairs not matching up over multiple messages
For the objects, we're still sceptical because it means that the client app service would need knowledge of the inner workings in Messagebot but a single objectid might not be very extensible. We could easily imagine many of our messages needing more than one object.
In Conclusion
Thank you for reading. The design of this service is important because it will be central to our entire organisation.
Which debated JSON structure is most appropriate in our situation? Also, knowing our requirements, what would be the proper setup for this type of service? (aka. Are we correct in our other assumptions?)
So your messagebot will
store notifications
get data from other services
compile emails from the data and
send the compiled emails
In my opinion, your messagebot were given too many tasks. If I were designing the system, I would like to keep the messagebot simpler. The servces should encapsulate the knowledge to compile the email, e.g. manage it's own template and so on. The services will push the compiled emails to a queue so the messagebot can pick up and send. The only logic in the messagebot is to pick up the emails from the queue and send. In this way, it doesn't matter how many more services you are going to have in the future, the messagebot will stay nice and simple.
I need to cancel some of scheduled push notifications via API.
Not via web console.
For example, it will be good to have ability to cancel all of scheduled push notifications for specific deviceToken (filter by deviceToken will be good enough, because I don’t need to cancel specific pushes).
REST API doc have nothing on this topic.
This is not possible at the moment, the only two ways are to either use the Push Dashboard in a browser, which can be unhandy if you schedule a huge amount of notifications or to implement your own queuing system for Push notifications.
The latter would involve creating a new table for your notifications and a background job that will send out all notifications that are due to be sent. Once sent, remove them from that table.
Other than that, you're out of luck at the moment.
I'm trying to understand whether the HTML5 Web Notifications API can help me out, but I'm falling short in understanding how it works.
I'd like user_a to be able to send user_b a message within my webapp.
I'd like user_b to receive a notification of this.
Can the web notifications API help here? Does it let me specifically target a user (rather than notify everyone the site has been updated_? I can't see how I would create an alert for one person.
Can anyone help me understand a little more?
The notifications API is client side, so it needs to get events from another client-side technology. Here, read THIS: http://nodejs.org/api/. Just kidding. Node.js+socket.io is probably the best way to go here, you can emit events to one or all clients (broadcast). That's a push scenario. Or each user could be pulling their notifications from the server.
HTML5 Web Notifications API gives you ability to display desktop notifications that your application has generated.
What you are trying to achieve is a different thing and web notification is just a part of your scenario.
Depending upon how you are managing your application, for chat and messaging purpose as humbolight mentioned, you should look into node.js. it will provide you the necessary back-end to manage sending and receiving messages between users.
To notify a user that (s)he has received a message, you can opt for ajax polling on client side.
Simply create a javascript that pings the server every x seconds and checks if there is any notification or new message available for this user.
If response is successful, then you can use HTML5 notification API to show a message to user that (s)he has a new message.
The main problem with long polling is server load, and bandwidth usage even when there are no messages, and if number of users are in thousands then you can expect your server always busy responding to poll calls.
An alternate is to use Server Sent Events API, where you send a request to server and then server PUSHES the notifications/messages to the client as soon as they are available.
This reduces the unnecessary client->server polling and seems much better option in your case.
To get started you can check a good tutorial at
HTML5Rocks
What you're looking for is WebSocket. It's the technology that allows a client (browser) to open a persistent connection to the server and receive data from it at the server's whim, rather than having to "poll" the server to see if there's anything new.
Other answers here have already mentioned node.js, but Node is simply one (though arguably the best) option for implementing websockets on your server. You might also be comfortable with Ratchet, which is a websocket server library for PHP, or Tornado which is in Python.
How you handle your real-time communication is up to you. Websockets are merely the underlying technology that you can use to pass data back and forth. The client side of this will be fairly easy, but on the server side, you'll need a mechanism for websocket handlers to get information from each other. Look at tools like ZeroMQ for handling queues, and Memcached or Redis to handle large swaths of data which don't need to be stored permanently.
I am starting to use gwt and I am having some problems to identify the clients state.
I am using GWTEventService to push some data to the client. But this data depends on which tab the client is. But how to know the state of the client (eg. which is the radio button selected)without using cookies. As I am sending events each 5 seconds, check the client state using cookies to each event that I want to send would make the application become very slow.
Can anyone help me?
Thank you,
Maurício
I would suggest a different design approach. Instead of pushing data to the client, have the client pull the data from the server. I have used GWT-RPC extensively to do this: http://code.google.com/webtoolkit/doc/latest/tutorial/RPC.html
If that approach doesn't work for you, the next best approach, whenever the state of the client changes, notify the server, so it always knows the state. You could then to client tracking with sessions.