I'm building an app using MEAN Stack (something like Facebook). So a user can login to my app using different browsers and I want for example, if there user will add a new message to the MongoDB, I want to update his messages in the other sessions. The same of he will remove a massage. At the same time, there maybe logged in different users from different browsers and I want to notify the user with his update in the other sessions.
Does Socket.io supports such an option? And what is the best way to do it?
Thanks.
Yes socket.io do support that. Here is an example made by socket.io themselves: https://github.com/socketio/socket.io/tree/master/examples/chat
You should be looking for socket.on() which are the listeners for an event on the server side and look into socket.emit() which are the senders of the events. the .emit()could be added into an function which are triggered on a button click for example.
Depending on you needs, if you're going to send the message to every user using your app then you could use this above code. But if you only wants to send to a specific list of persons you should look into something called Rooms (http://socket.io/docs/rooms-and-namespaces/#rooms).
This does exactly what it sounds like, it emits the messages to the specific room where users have been added to when they connect to your application.
Related
I am a bit dumbfounded on how to achieve this properly. So you have an app that is getting regularly updated, and you show those new updates to the user (something like discord update popup and whats new and such). How do you handle whether or not the user has seen it? A more high level question that "local storage", I am well aware of that or storing it in a DB, but this doesn't seem 1) Scalable, 2) Easy to work with in the long run. Are there any JS libraries that can simplify the process, eg or do I have to manually track each update? If there are more updates or the user hasn't logged in a while
I hope I conveyed what I am working on properly. Would love to hear how it's usually done.
Q: have an app that is getting regularly updated, and you show those new updates to the user
A: Service Worker can help you .That support reacting to push message .And they provide the Push API gives web applications the ability to receive messages pushed to them from a server, whether or not the web app is in the foreground, or even currently loaded, on a user agent.
More detail about start up a service worker to send users a message . https://developer.mozilla.org/en-US/docs/Web/API/Push_API .
Finally I suggest you try Workbox , that is a library that bakes in a set of best practices when working with service workers.
I'm designing a custom team tab using React that calls third party API, I need after executing the API successfully, user gets notified . What is the best way to achieve this? I used Bot in my project, but not sure how can I call it from my custom tab class. I'm aware of the existence of proactive messaging, is it the only way to do it? If it is, a pointer on how to implement it to a custom tab would be appreciated.
If you're wanting to message the user 1-1 (like in the personal app), then proactive messaging is definitely what you need (inside a Team, there are other options), and considering you have the bot already in place that's perfect. The only thing you might be missing are the details required to send the actual proactive message (the best time to get them is when the bot is first installed by the user). In particular, you need ConversationId and ServiceUrl.
With regards the concept of Proactive Messaging, basically once the bot is installed, and you have the required values, you can -send- the message from any backend code at all. That can include, for example, custom tab's backend api. You need to identify the user, which you can do using the Teams Context (it's not the safest way but it's the easiest), and then look up the values in your own backend store (e.g. database or whatever) to get the ConversationId and ServiceUrl, then just message the user in your backend.
I am creating an AdminUI for my users where I set all the permission. As part of the requirements, every time that a user logins on my IdentityServer I need to set some default permissions, but those are handle on my Admin application. Which is the best way to raise an event to let that application that a user was created on the IdentityServer?
The simplest is i think to create a simple WebApi in IdentityServer that returns the latest users and then let the other application poll this API every X seconds. In that way the system is cleanly decoupled. Perhaps expose the data as a a RSS XML document or a JSON list of items.
There is a built in eventing model in IdentityServer that you could use and push notifications to the Admin application. But push is a bit more complicated to get right, especially how to deal with all the failre/error cases.
I's suggest to add a custom event sink to process UserLoginSuccessEvent or any other event you need, here is list of all builtin events. Find their code here.
In the custom sink as suggested in the other answer you can call an API on admin app to inform it about changes.
Here is a sample for custom sink.
I think to keep two applications decoupled you better to setup a service-bus for simple implementation a sub/pub mechanism. when any user complete registration(or any other actions),then as mentioned in another answer handle the events and add message. admin UI should subscribed before to receive these messages with some information to create a user related data.
I'm rebuilding the CoinbaseCommerceButton component from scratch, and in order to improve the end-user experience I want to allow the user to continue on using my app after a payment has been detected. Is there a way to do this?
There are currently two ways to do this.
1. CoinbaseCommerceButton
There is an onPaymentDetected callback as documented here. After the callback is triggered, you can safely remove the button from the DOM and allow the user to continue using your application.
2. Webhook Subscriptions
Detected payments can also be registered for via webhooks with the charge:pending event type. See here for a more detailed explanation of how this can be achieved.
I am curious how others are solving the following problem...
I have an angular application that requires user authentication. The user must log in to the system to make requests. The user must also be authorized to create a socket.io connection.
When the application first starts up I must determine if the user is already authorized. I was planning on looking in sessionStorage for a user object/token. Does that make sense? And if the user is not authorized, the application will make a request to get the current user. If/When that fails, a 401 error is returned and angular intercepts/prompts for a username/password.
Given that there are two different code paths for authentication (check sesssionStorage vs make a request and wait for the response) how do you trigger the requests for all the other information that is required for the application? Do you emit/listen to a LOGIN event that gets broadcast in both scenarios?
My plan was to wrap the socket.io connection attempt and the ".on(...)" calls inside of the LOGIN event, does that make sense?
And if you want to listen to socket.io events or grab information from the server in a controller that is loaded after the LOGIN event has fired, how do you trigger the data from being retrieved from the server?
Sorry for the long winded questions, but I've hit a road block and I'm wondering how others are managing all the authentication and different pieces of information that is required to get from the server.
Ok, I guess let's go in order of question asked.
Does it make sense to use sessionStorage to hold user auth info?
Yes. You will need to decide between local/session Storage depending on how you want it to work. We decided we wanted the session to still be active for the time period that the backend recognizes, so even if the user closes the browser and reopens it, they will be logged in, and so we opted for localStorage instead of sessionStorage.
How do you trigger the requests for all the other information that is required for the application? Do you emit/listen to a LOGIN event that gets broadcast in both scenarios?
After login, we redirect the user to the "landing" page (route). All of our route/state changes wait on a resolve function which is doing the session auth. We only store the session id in localStorage. After the successful state change, the controllers that go with the newly loaded views start requesting data from our services. All of our controllers are designed to load data on init. So no, we do not use events. It feels like events should be used only as a last resort - and that is also the impression I get from core Angular devs since I get chastised for event usage in pull requests :)
My plan was to wrap the socket.io connection attempt and the ".on(...)" calls inside of the LOGIN event, does that make sense?
Maybe. I am not using socket.io outright, but instead have been experimenting with atmosphere (mainly because we had a java backend requirement). I do initiate the connection in the login success handler. But the general atmosphere event handling I have put into an application-level controller that is on <body>.
And if you want to listen to socket.io events or grab information from the server in a controller that is loaded after the LOGIN event has fired, how do you trigger the data from being retrieved from the server?
I could imagine (again using an app-level controller, or a service, or in my case, likely both) a function that returns the socket.io connection. A controller that has come into being could grab the socket.io stuff on init, and setup the listeners for the events that it is interested in.
My advice is to get all of your session and auth stuff worked out first, especially with regard to how you are going to do routing. Once all of it is working to your satisfaction, then add the socket.io stuff in. I realize that this might not be possible in all cases because perhaps you need something from the socket.io connection that is critical to your app even at an early stage.