The current project is in Node.js with the Expressjs framework. We have an application with client/prospect information, authenticated users are allowed to modify the database and initiate long-running processes on the server. As an example, printing a 30 pg document could be one process.
The application user needs two main things:
A response when the process begins.
A response (notification) when the process ends.
We currently handle need #1 in standard express fashion by ensuring the process starts followed by res.json({msg: 'Process Started']); back to the Angular front end. Need #2 is currently handed with an email to the user that initiated the process with a process status report.
I would like to improve how we handle need #2. Specifically, I would like to send a JSON string to the user to display in the interface.
Questions:
Is it possible to do this over HTTP?
Does this functionality exist within Express or a well-know middleware.
Assuming 1 & 2 are false. My solution is to run a TCP socket server to maintain a socket with the required users. When a process ends a message is sent to the user with a status update. Can anyone comment on the issues my solution presents?
Yes to both 1 and 2. Essentially what you seek to achieve here is to push from the server to the client. The need to do this is pretty ubiquitous in web applications and there have been various solutions for it over the years with various fancy names. You might like to read up on Ajax, Comet, Long-polling, Websockets.
For your node application, take a look at socket.io. In a nutshell, what this framework does is it abstracts the complexities of Ajax, Websockets, etc. into a single API. Put another way, socket.io gives you bi-directional communications between your node application and front end.
Related
My application allows a user to enter a URL of an article he/she wishes to analyze. It goes through our API gateway to reach the correct services engaged in this process. The analysis takes between 5 and 30 seconds depending on the article's word count.
For now, my reactjs client sends the request to the API and waits for 5 to 30 seconds to receive the response. Is there a better way to handle this such as enqueuing the job and let the API ping the client (reactjs frontend) once it has been done?
Server-sent Events (SSEs) allow your server to push new information to your browser, and hence look ideal to me for this purpose. They work over HTTP and there is good support for all browsers except for IE.
So the new process could look as follows:
Client send request to server, which initiates the lookup and potentially responds with the topic the browser needs to subscribe to (in case that's unique per lookup)
Server does its thing and sends updates as it processes new content. See how the beauty of this is that you could inform your client about partial updates.
If SSEs is not an option to you, you could leverage good old Websockets for bi-directional communication, but for such a simple endeavor, it might be too much technology to solve the problem.
A third alternative, especially if you are talking amongst services (no web or mobile clients on the other side) is to use web-hooks, so that the interested party would expose and listen on a specific endpoint, that the publisher (the server that does the processing) would write updates to.
Hope this is useful.
I have built a web application using JavaScript stack (MongoDB, ExpressJS, AngularJS, NodeJS). The registration works, the authentication works, the chat is which is using Socket.io works but I need a way of distinguishing which client is sending and which client is receiving the message in order to perform further functions with the user's data.
P.S. Since this is a project that I can not publish there are no code snippets in my post, hopefully it is alright
The ultimate design will depend on what you are trying to achieve. Is is "a one-to-one chat" service or maybe a "one to many broadcast". Is the service anonymous? How do you want users find each other? How secure does it need to be?
As a starting point I would assign a unique identifier (UID) to each connection (client). This will allow the server to direct traffic by creating "conversation" pairings or perhaps a list of listeners (subscribers) and writers (publishers).
A connected user could then enter the UID of a second connected user and your service can post messages back and forth using the uid pairing.
conversation(user123,user0987)
user123 send to user0987
user0987 send to user123
or go bulletin board/chat room style:
create a "board" - just a destination that is a list of all text sent
user123 "joins" board "MiscTalk"
user0987 "joins board "MiscTalk"
each sends text to the server, server adds that text to the board and each client polls the board for changes.
Every Socket can send or recieve, your program must track "who" is connected on a socket and direct traffic between them.
I think a fine way to handle the clients is creating a Handler class, a Client object and create a clientList in the handler, this way is easier to distinguish the clients. Some months ago I built a simple open source one-to-one random chat using socket.io, and here are the handler and the client class.
I hope this example can help you.
1.) Create a global server variable and bind connections property to it and whenever the authentication is true ,store socket_id against the id(user_id etc) which you get after decoding your token.
global.server=http.createServer(app);
server.connections={};
If server.connection hasOwnProperty(id) then use socket emit to send your message ,
else store the socket_id against your id and then send your message.
In this way you just need to know the unique token of the target user to send the message.
2.) You can also use the concept of room
If authentication is true use
socket.room=id ; socket.join(id)
when sending message use client.in(id).emit("YOUR-EVENT-NAME",message)
Note: Make your own flow , this is just an overview of what I have implemented in the past.You should consider using Redis for storing socket_ids.
I'm trying to design a client program that connects to a remote server and sends various messages / request to it and expects responses based on the requests sent (for e.g. send a join message and wait for a response, then either query for some resource or ask for some info etc. in no particular order).
I would like to design the client such that the user can choose any of the possible requests to send after joining the server (after completing one request and getting a response if any it should allow them to carry out further requests or quit). Something like a menu of actions that it returns to each time (while also waiting for any data from the server)? However I can't seem to figure out how to this could be done. Is there a way to do this (preferably without getting into forking/threads)?
Any inputs on this would be really great. TIA
I would start off with a simple chat server to get your feel for socket programming. Google Example TCP Chat Server or something, you'll end up with simple examples like this: http://www.cs.ucsb.edu/~almeroth/classes/W01.176B/hw2/examples/tcp-server.c .. once you are able to telnet to your server and read/write to your clients, you should be able to progress from there and perform actions when your clients issue a specific command and that sort of thing.
I got an assignment to do and for that I could use any www technology like HTML, JavaScript, PHP etc. I'm really sorry to say that I haven't studied any of these technologies. Therefore I took few tutorials and skimmed through them searching for answers.
I found solutions for many problems but one problem yet unsolved. It is this:
I want two clients to communicate through a server for this assignment. One send a message, server processes it and forwards it to the next.
None of PHP tutorials showed me anyway of doing this. All of them talked of communication between one client with a server.
Please help. Show me a way to do this. Thanks.
Currently, without reverting to cutting-edge (and possibly hacky/unreliable) techniques, your PHP server cannot initiate communications with a page you've already loaded into a web browser. This is a result of the way the HTTP protocol works.
One way to solve this would be polling on the "receiving" end for data. Something like a publish-subscribe pattern.
One way to do this would be:
One client sends data to the server using an HTTP request (XHR aka AJAX) specifying the target for this data (the other client).
The server stores this data in a persistent storage (local file, database, etc).
The second client periodically sends a request to the server asking if there's any new data for it to consume. This can be done using setInterval and XHR in JavaScript.
I would suggest you take a look at:
http://en.wikipedia.org/wiki/Publish/subscribe
And also, for a cutting edge way to do this, check out Socket.IO:
http://socket.io
You might want to Google on "php chat server." Building a chat server is a simple way to get started.
http://net.tutsplus.com/tutorials/javascript-ajax/how-to-create-a-simple-web-based-chat-application/
http://code.jenseng.com/jenChat/
Can anyone think of a good way to allow the server to notify the client based upon server processing? For example, consider the following events:
A user requests a deletion of data, however, due to it's long-running time, we kick it off to a queue.
The client receives a "Yes we completed your transaction successfully".
The server deletes the item and now wants to update any local structures any clients may be using (I'd also like to notify the user).
I know this can be done by client-side polling. Is there a event bus type way to do this? Any suggestions are welcome, but please keep in mind I am using GWT with App Engine.
The standard AJAX interaction is that the client sends requests to the server and expects some sort of response back fairly quickly.
In order for the server to initiate a request to the client, you will need to use WebSockets, and experimental HTML5 feature currently only supported by Chrome.
Or, to simulate this kind of interaction, you can use Comet (long-polling), made available in GWT by the rocket-gwt project.
You want server events for GWT? Have a look at GwtEventService (they couldn't have chosen a better name): http://code.google.com/p/gwteventservice/wiki/StartPage
Of course, it uses a Comet implementation, but you can't do any different when using HTTP, the client always initiates the communication. Request, response.