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.
Related
I have a simple React application that allows performing CRUD operations on various entities. It uses RTK Query to interact with the backend, and I want to utilize its built-in caching system - invalidating the cache only when a mutation is performed on an endpoint with the given tag. It works fine as long as I have only one tab open. If there are multiple users interacting with the application and one of them performs a mutation, the cache will be invalidated only in this user's browser tab. The update will not be populated to other browsers or tabs that are currently connected to the app. Each user would have to manually refresh the page after another user performed a mutation. One way to solve that is to invalidate the cache periodically, which isn't ideal, another is to force every query to re-fetch on focus, which is even worse. The best scenario would be to somehow detect that another user had sent a mutation for the given endpoint, and then invalidate the cache of this endpoint (by tags) in every other browser tab that is connected to the application. I'm looking for a solution that is better than what I've already implemented, which is the following:
There's a global component with a single websocket, which immediately connects to the backend
The backend assigns a unique identifier to the socket, saves it in a socket pool and sends back an event with the identifier
The component with the socket saves the identifier in Redux
RTK Query adds the identifier as a custom header to every request sent to the backend
The backend checks the HTTP method of the request. If it is a mutation (POST / PUT / PATCH / DELETE), it extracts the identifier from the custom header, filters the socket pool excluding the socket that has the same identifier as in the request, sends an event with the tag of the service that is being mutated to all the filtered sockets
The component's socket receives the event and uses RTK Query's invalidateTags utility function to invalidate the cache of the mutated service
Thanks to that, the whole app functions as if it was a real-time collaboration tool, where every change made by any user is immediately reflected in all the connected browser tabs. However, I think it is a bit too complicated and I feel like I'm reinventing the wheel. This scenario is surely quite popular, and there must be something that I'm missing, like an npm package that solves this problem, an RTK Query option that I've omitted, or a well-known design pattern. Of course, there are multiple packages that allow synchronizing Redux Store across multiple tabs, but that doesn't solve the problem of having multiple users connecting from different devices.
It works fine as long as I have only one tab open
JS code lives within a single tab / open page by default.
That includes JS variables and logic, and the Redux store is just another JS variable.
RTK Query is not specifically designed to interact across tabs. You'll have to write that part yourself.
If the concern is multiple users interacting with the same backend server, that's what RTK Query's polling options are for. Alternately, yeah, you could have the server send a signal via websocket to let the client know it needs to refetch data. But again, that's something you'll need to write yourself, as it's specific to the needs of your own application.
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.
My friend and I are currently building a web-based chat app with WebSocket. I'm in charge of client side (React + Redux). Golang is used for the server side (I don't know whether this is a good combination, but I do this just for fun).
Basically my problem is that I don't know what to do after the successful re-connection to the WebSocket server.
More concretely:
The client side tries to reconnect to the server when the connection is lost. My questions are
When the re-connection is successful, what should I do with the data that were supposed to be sent to the server, but actually weren't sent because of the lost connection? Is it better to have something like a buffer to store all the data that are not yet transmitted to the server?
Currently, a React component do the initial fetch of all the necessary data ( rooms, friends, chat history, etc.) on componentDidMount. For the app to be in sync with the server on successful re-connection, the app should perform actions similar to the initial fetch. But calling componentDidMount deliberately does not seem to be a good idea, because it is not supposed to be called in this way. Is it good to perform initial fetching in componentDidMount in the first place?
Since this is is a general question, I will answer in general terms:
You need some kind of buffer between the application and the unreliable stream. Since you're reactive, you can implement this using an observable. The service that is responsible for the actual communication over WebSocket will subscribe to this feed.
Separate the initialization of the component from initialization of the data. If you're communicating over WebSocket, you can reinitialize data every time the socket connects.
Go is certainly a good choice for the chat server because of the way it handles concurrency. The other common option for chat servers is Erlang. React is a matter of personal preference.
You probably don't want to buffer it all. You just want to buffer the messages but not, for instance, typing indicators because they make no sense if not sent immediately. Something as simple as an array with push() and shift() would do.
Move data fetching to a separate function, then call it both from componentDidMount and from the callback or whatever place where you reconnect.
Using both HTTP and websocket in one app is a matter of design. It does seem to complicate things though.
I am writing web app in angular, using Nancy as my backend. I have setup signalR websockets as my primary communication mechanism. It works great, with one exception. I can't figure out how to attach state to my socket connection and make it easily available to my code. To be more specific, I can create and maintain state, I am finding it difficult to make that state available to everything on the back end that needs it, without passing a state data object around through every call.
I was hoping to tie to Nancy's IoC, but that is based off of the session, not off of a websocket. I looked at other IoC systems, but I cannot grok how to tie them to the socket.
Does anyone have any insight on how to maintain state non-obtrusively with signalR?
EDIT: This may explain it. When the user connects via signalR, I want to create an IGame instance with a life cycle that is tied to the signalR session and inject it throughout my code as needed. for that particular user.
Is that any clearer?
Have an Angular web app that track status of many objects. Now, I have a directive for each object to poll a nodejs server for status. This works but it is quite chatty and I am a bit worried about scalability. However, the backend does not support subscription so it could not use a pusher. One option is to let the nodejs server do the polling and push status back. Then nodejs need to keep a list of objects to poll and client probably need to check the message to determine whether a status needs update. Really appreciate your suggestion for a better strategy.
You can use firebase and load the data from a third party source into the firebase database then use angular-fire to get that data into the app... alternatively you could use a socket connection to DIY. In either scenario, I assume like you said the NodeJS portion on the server will need to handle polling the third party system for data and populating the firebase instance which would be a read-only layer as far as the system is concerned... changes would be sent directly to the third party and NodeJS would just be responsible for updating the firebase DB.