In my node.js server app I'm providing a service to my js client that performs some handling of remote api's.
It might very well be possible that two different clients request the same information. Say client 1 requests information, then before client 1's request is fully handled (remote api's didn't returns their response yet) client 2 is requesting the same data. What I'd want to is to wait for client 1 data to be ready and then write it to both client 1 and 2.
This seems to me like a very common issue and I was wondering if there was any library or built-in support in connect or express that supports this issue.
You might not want to use HTTP for providing the data to the client. Reasons:
If the remote API is taking a lot of time to process you will risk the client request to timeout, or the browser to repeat the request.
You will have to share some state between requests which is not a good practice.
Have a look at websockets (socket.io would be a place to start). With them you can push data from the server to the client. In your scenario, clients will perform the request to the server, which will return 202 and when the remote API will respond, the server will push the data to the clients using websockets.
Related
I currently have a socket.io server spawned by a nodeJS web API server.
The UI runs separately and connects to the API via web socket. This is mostly used for notifications and connectivity status checks.
However the API also acts as a gateway for several micro services. One of these is responsible for computing the data necessary for the UI to render some charts. This operation is long-lasting and due to many reasons the computation will only start when a request is received.
In a nutshell, the UI sends a REST request to the API and the API currently uses gRPC to send the request to the micro service. This is bad because it locks both API and UI.
To avoid locking the socket server on the API should be be able to relay the UI request and the "computation ended" event received by the micro service, this way nothing would be locked. This could eventually lead to the gRPC server on the micro service to be removed.
Is this something achievable with socket.io?
If not is the only way for the API to spawn a secondary socket connection to the micro service for each one received by the UI?
Is this a bad idea?
I hope this is clear, thanks.
I actually ended up not using socket.io. However this can still be done with it if the API spawns a server and has the different services connected as clients, https://socket.io/docs/rooms-and-namespaces/ can be used.
This way messages can be "relayed" and even broadcasted from the server to both in case something happens.
My app was hosted in xxx.com, which gets data from yyy.com. All API requests were triggered from client side.
Is there a way to intercept its request or response in node?
No, and Yes.
For the requests made by your client, you must have some control of the data sent back to the client in order to intercept it.
Assume a scenario where:
Client -----(request)----->Third Party App Server -------(response)-----> Client
In this case, as the back-end server never had a chance to come into picture, there is no way the server can change the data. Well of course, that is when the server doesn't come into picture.
Instead, if you send the request to the node server itself, which forwards the request to the Third Party App server, you obviously have control of the response receive and thus, you can manipulate both request and response or maybe just log it (whatever is your use case).
Client -----(request)----->NODE_SERVER---->Third Party App Server -------(response)-----> Node_Server ----> Client
What a few developers do to intercept the requests made from the client is that they write some client-side JavaScript code and embed it into the browser (Some sort of authentication).
While this works okay in case of normal requests, a person with malicious intents might just disable your front-end interception code and directly receive a response from the Third Party application.
Thus, if you really need to have access to the requests and response,
YOU MUST FORWARD THE REQUESTS TO AN APP SERVER YOU HAVE CONTROL TO.
P.S. It is not just about nodejs.
Normally i use ajax http requests to get/post data. Now i have thoughts like why shouldn't i replace all the ajax get requests with socketIO?is there any disadvantage in following this approach?
I understand that session cookies via http headers will be sent between client and server during every http requests, during client<=>server interactions using sockets, will the session cookies in browser automatically sent to the server via socket headers(if that exists)?
In which usecases should i prefer SocketIO over Http?(if you consider this as a question that demands broad answer then you can link me to some relevant articles)
WebSockets are useful when the server needs to push some real time information to the client about some events that happened on the server. This avoids the client making multiple polling AJAX calls to verify if some event has occurred on the server.
Think of a simple chat application. If the client needs to know if the other participant in a chat session has written something in order to display it, he will need to make AJAX calls at regular intervals to verify this on the server. On the other hand WebSockets allow the server to notify the client when this even occurs, so it is much more efficient in terms of network traffic. Also the WebSockets protocol allows the server to push real time information to multiple subscribed clients at the same time: for example you could have a web browser and mobile application subscribed to a WebSocket and talking to each other directly through the server. Using AJAX those kind of scenarios would be harder to achieve and would require much more stateless HTTP calls.
I understand that session cookies will be sent between client and server during every http requests, is this case the same during client<=>server interactions using sockets
The WebSockets protocol is different from the HTTP protocol. So after the initial handshake occurs (which happens over HTTP), there are no more notion of HTTP specific things such as cookies.
There's one important thing that you should be aware when using WebSockets: it requires a persistent connection to be established between the client and the server. This could make it tricky when you need to load balance your servers. Of course the different implementations of the WebSockets protocol might offer solutions to this problem. For example Socket.IO has a Redis implementation allowing the servers to keep track of connected clients through a cluster of nodes.
I have a SPA application (Backbone on client and node.js on server). It all communication in both directions is through via websockets. Now I wondered - it's a good idea? What are the cons before approach: the client sends data to the server via the REST API, and server sends data to client via websockets?
thanks.
UPD:
I have websockets in any case because my app is multiroom chat.
Even if you only consider RPC ("Remote Procedure Calls"), REST is less capable than WebSocket.
REST, since it runs over HTTP, cannot pipeline RPCs. Each HTTP connection can only serve 1 RPC synchronously. And browsers limit the number of parallel HTTP connections to a given origin.
With RPC over WebSocket, you can fire off 100 RPCs pipelined, and process RPC returns asynchronously as they come in.
Then, with WebSocket, you can have server-initiated notifications as well. E.g. you can have full-flavored Publish & Subscribe.
WAMP ("The Web Application Messaging Protocol") runs over WebSocket and was designed exactly for this: SPAs that need 2 messaging patterns in 1 protocol - RPC and PubSub.
Disclaimer: I am original author of WAMP and work for Tavendo.
If server needs uncertain time to prepare data, it may be a good idea though
basically there is no reason to use websocket(socket.io) for REST API.
because of what REST API stands for,You don't have to keep connection stablished nor don't have to wait for someones action like broadcasting server.
EDIT answering the comment
even if you already used websocket,it doesn't mean you can't handle normal req/res.
RESTapi with websocket is like
get request -> server response -> client try io.connect(); -> connection established -> server send data to the client thru websocket
and normal REST API is like
get request -> server responce
which do you choose?
Do I need to use a websocket to send JSON data to my client? (it's a tiny session description)
Currently my client-side code sends a session description via XHR to my Node.js server. After receipt, my node server needs to send this down to the other client in the 'room'.
I can achieve this using socket.io, but is it possible to do anything a bit faster/ more secure, like XHR for example?
If you just want to receive the offer from the other side and nothing else, I would suggest you to try HTML5 Server Sent Events.
But this may bring problems due to different browsers support, so I would use a simple long pooling request. Since you only want to get the SDP offer, the implementation is pretty simple.
No, you don't need to use the WebSocket API to send JSON data from client to client via a server, but unless you use Google's proprietary App Engine Channel APIs, then the WebSocket API is probably your best choice.
Also, please keep in mind that you're not only sending session descriptions, but also candidate info (multiple times) as well as other arbitrary data that you might need to start/close sessions, etc.
As far as I know, the WebSocket API is the fastest solution (faster than XHR) for signalling because all the overhead involved with multiple HTTP requests is non-existent after the initial handshake.
If you want to code things yourself, I'd start reading the latest WebSocket draft and learning how to code the WebSocket server-side script yourself or else you will pretty much have to rely on a WebSocket library like Socket.IO or a proprietary solution like Google's App Engine Channel APIs.
How about using the 303 HTTP status code?
The first client send the session description to resource X, the server acknowledges the receipt and responds with a 303 status code that points to a newly created resource Y that accumulates other clients session descriptions.
The first client polls resource X until it changes.
The second client send its session description to resource A, the server acknowledges the receipt and updates resource Y. The first client notices the update with the next poll and will now have the second client's session information.