I am working on a project where we have server that is administrated from angular web page, and I noticed that it is calling this main server REST interface for status update each second.
My questions: Is it a proper technique to solve this kind of problems?
If not how do I properly make such regular updates in more reactive or event way from back to front end?
I was thinking about reworking to maybe keeping the session opened for longer period and update only on change of status, and retry on session expiration.
Related
I am using web socket for communicating with back end server from a reactjs client. Socket is getting closed when a user refreshes the page. That is happening as expected. However, my requirement is to have persistent web socket connection across page refresh. I am currently using localstorage to store access, refresh tokens.
I understand this is not a secure way to resolve the problem. I want to know if there is any secure way available to achieve my goal.
I am not sure if this works because it would be kind of a security breach to be able to let the user connected even though he is not on your page. (Because as you are refreshing, you leave the page and re-enter it).
Your best bet maybe something with a service worker that can run in the background :)
Since you are using Web Sockets it would be a good idea to use a SharedWorker to create a new thread for your Web Sockets. The difference between a normal WebWorker and a SharedWorker is that the web worker will create a new session in each tab or browser when loading the page, whereas the shared worker will use the same session in each tab. So all of your tabs or windows will have the same worker and same Web Socket connection to work with.
I quoted from this answer which will probably point you to the right direction: https://stackoverflow.com/a/61866896/11665341
I'm sending data from my backend every 10 seconds and I wanted to display that data in reactjs. I've searched on the net to use socket.io to display real-time data. Is there a better way to use it?
If you're dead set on updating your data every 10 seconds, it would make more sense to make a request from the client to the server, as HTTP requests can only be opened from client to server. By using HTTP requests, you won't need to use socket.io, but socket.io is an easy alternative if you need much faster requests.
Depending on how you are generating the data being sent from your backend, specifically if you are using a database, there is most likely a way to subscribe to changes in the database. This would actually update the data in realtime, without a 10 second delay.
If you want a more detailed answer, you'll have to provide more detail regarding your question: what data are you sending? where is it coming from or how are you generating it?
I'm working on an autodialer feature, in which an agent will get a call when I trigger the button from the frontend (using react js language), and then automatically all the leads in the agent assigned portal will get back-to-back calls from agent number. However, because this process is automatic, the agent won't know who the agent has called, so I want to establish a real-time connection so that I can show a popup on the frontend that contains information about the lead who was called.
How can I deploy and Angularjs app and ensure that all my users get the update when it happens? I have a breaking change that needs to be deployed and would cause some downstream issues should a user continue using the old version. Are there any tools or best practices on how to handle this?
Like in the comments says you cant do it with session expires, one alternative you can do, its handle in the backend to check if an update was release and with push notifications cand inform to client. Forcing to reload the app.
An intrusive will do the same thing but without notification, only if response tell there is an update reload page, according api response.
Couple of questions:
I have list of components on the client app which has some near real time info e.g. status, which I want to display.
I have server app, which can pull the status info from a third party REST endpoint.
My question is, should I cycle through all the components in the client app and request the server app for the status?
Or should I have a server worker thread, which pulls the status info and publishes on the websocket, which the client can then update the state of the component.
Or is there background thread which I can run on the client app, which will update the status and the state. How will this conflict with the dispatch/queuing of events from user interactions.
I think I might be asking some of the architectural questions and the answers might be "it depends" ambiguous, but anyone who has done this before and any guidance is appreciated.
Thanks, Rajesh
It depends :) But it's safe to go with server-side approach since with client-side you would have to deal with CORS and cross-domain ajax calls in general. Most of the 3rd party API do not allow to make arbitrary AJAX calls from other domains. Those that do allow that usually have API quota which is again easier to manage since you can keep your keys secret on the server and throttle and cache requests.
Server side approach requires more effort though. So it's a prototype and 3rd party API allows cross-domain requests – go for it, it's easier, for production app, consider doing this on the server.
For client-side approach if 3rd party API doesn't offer subscriptions, yes you would have to poll, but you don't have to cycle through components. You can abstract this polling in one, root component and then just pass props down.
You are right, the answer is "it depends".
Basically, you have two options:
Poll the server for the current status.
I believe you do not have to cycle through all the components and query their status. You could just have an API that provides the server the timestamp when you last queried the status, and the server will respond with just the information that has changed since the last query.
This is simple and will work fine if the updates are not huge, and you can afford to be a little late.
You could have a dedicated websocket connection with the server
In this case, the server will push any new updates to your front-end whenever any new update is available. This is a little cumbersome to implement, but is the right approach if the updates are near real-time.
To answer your question about having a background-thread on the front-end: no, you cannot have background-threads on the front-end. Javascript doesn't work that way. What you do have are callbacks. Whenever the server pushes you any new information, a callback, that you define, will be called and you can do whatever UI changes you need from here.
My question is, should I cycle through all the components in the client app and request the server app for the status?
No, this sounds very inefficient to me.
However, if you decide to poll from the client, it should be done only from a single component that is parent to all children that need the information. The parent then passes its state to the children and they update on each poll.
Or should I have a server worker thread, which pulls the status info and publishes on the websocket, which the client can then update the state of the component.
Absolutely. Let this socket be in your top-level application component which holds the real-time info in its state and passes down to its children. Whenever information gets published to the socket, update the top-level application state with the new real-time info and all children will rerender displaying the most current information.
When I make a change to my Backbone web application code on my server, how can I make user's browsers update so they see those changes.
Being a SPA the page rarely if ever refreshes. So even if place hashes/timestamps on my script tags it still wont be adequate enough, ie, this isn't ideal IMO:
...
<script src="js/main.js?t=SOME_HASH"></script>
Does Backbone have a way to handle this?
Backbone being a JS framework that merely gives structure to your applications, it doesn't handle stuff like this. This is something that involves configuration of server and you need to tackle it yourself.
Since you said you have an SPA that rarely refreshes - Your app is probably contacting the server via lots of AJAX requests. You can add an interceptor to these requests on the server that checks if stuff changed on server and sends a shouldReload: true with the response.
You should also have an AJAX interceptor client side that checks for this in response and reloads the page/lets users know about updates on server and give option to reload/restart.
Another option is to implement websockets/polling so that server can push notification about changes to clients. socket.io is a plugin that uses web sockets and falls back to polling.
P.S: You also need to bust the cache as you mentioned in question