I am a bit of a newbie in Webhooks, so excuse me if this is a simple question.
I am clear about how Webhook providers work, i.e. whenever this information needing to be pushed, it sends the payload to the URL specified as callback.
Now my question is: how do I write a client-side Webhook handler, that can detect/process the callback and update my client-side accordingly. For example, if my client-side is a simple web-page with bullet-points, I would like to append new data to the list, whenever it comes through.
Preferably, I would be after a complete JavaScript solution...
Is there perhaps a JS WebHook Client/Handler that already exists? It seems that this should be so common, that it should exist, although I haven't been able to find anything.
Take a look at WebSockets. Depending on your needs, this could be exactly what you need to avoid polling and keep things in sync - particularly if you have a lots of clients who need to see the same updates from your server.
I highly recommend Socket.IO
To consume a webhook API endpoint, or in other words, to "listen for changes", you'd poll for changes, long-poll for changes, or anything else clever you'd like to do.
Or you can use any javascript Publisher Subscriber module to easily do this. try googling around for PubSub stuff. here's an example of one such tool: http://www.pubnub.com/tutorial/javascript-push-api
web hooks are not made for this. Event notification in web hooks is done through POST requests meaning your client app cannot be notified about new events unless it listens for incoming HTTP requests (usually the client is behind a firewall so this will not be feasible in most cases).
If you'd like to avoid polling the server for status updates, use WebSockets as matthewhudson pointed out.
Related
The logic of my code is basic.
The user sends a request to the server side, where it is processed and shown in an admin panel. Afterwards a person with access to the admin panel analyses the data and sends a response with some delay.
How can I create a response listener on the client side, so that I can catch the message I get from back-end, no matter the delay?
I tried doing it with fetch, but no wonder it didn't work, because once it is compiled, it makes the action immediately. Is AJAX an option in my case?
You'll need to have some sort of bidirectional communication layer here. The most common approaches are polling, web hooks, or sockets. Polling will probably be the easiest to set up in a beginner use-case.
If you're referring to jQuery's $.ajax, which uses XMLHttpRequest, it's not likely to be a good idea unless the server can respond very quickly every time. From what I understand, if the request isn't fulfilled within a reasonably short period of time, the browser or OS will terminate it. Fetch might have different limitations, but I still wouldn't trust it for something like this.
There are better approaches. Either create a websocket, so that the server can push information to the client on demand, or (less elegant) have the client repeatedly make requests to the server (say, every minute) and have the server respond positively if/when the admin panel has been dealt with.
I have a C++ project for windows, using MiniBlink as embedded browser. (MiniBlink is a smaller Blink, which is close to chromium). I use this embedded browser to show responsive and nice looking dialogs with Quasar.js (wrapper for vue.js).
Problem:
Mostly a browser is just the passive backend. In my case, both the backend (project with embedded browser) and the frontend (dialog) are active and thus I need some communication. At the moment I use a local server to catch HTTP send from the frontend to the backend.
But is there a way to communicate from the backend to the frontend? At the moment I could only think about catching cookies or using a permanent loop in JS to send http queries to check for a possible response.
And is there no other way to send information to a backend? Everything is local, I dont need nor really want to send it into the network.
Thanks!
Idea 1: Use a local temp file to save on one side and read on other (can be also used both way)
Idea 2 (similar to question author solution): Local server with both side communication (GET/POST request into one side, text/json other way around)
Idea 3: Use launch parameter to pass though data directly into links for example: instead of using browserprocess.exe file.html, use browserprocess.exe file.html#showsomething
There are also other ways which like catching for example: checking window title of process with certain binary name from running tasks by other side; we didin't get good enough info about your background becouse you coud either use it in same process or other process, if thats same process you coud also just directly use variables both ways directly in code of miniblink and do action when they meet if statement
As CertainPerformance added as a comment, WebSockets might be the best way to go.
If one does not like to implement a websocket server, because a http server is already running, long polling requests might be the best workaround to simulate this behaviour.
Long polling: The client sends a request, which stays open as long as possible. If the server needs to communicate, it can use the open request to send its own "request" via response. It is a bit hacky, but essentially the idea behind websockets.
Mozilla has a nice article to help with websockets:
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers
If you (like me) use vuejs or quasar, you might want have a look at vue-native-websocket.
https://github.com/nathantsoi/vue-native-websocket
Good luck
I am trying to implement a simple UI which shall be showing the logs written in my server console. Have searched but couldn't find a solution which satisfies my requirement.
As per my design, I have a java program using Apache common-io api for tailing log file. It helps me to reduce memory overhead, I do not want to keep large chunks in memory.
So when client makes a request, server shall start reading file and send the read data incrementally and shall keep showing until client stops receiving. I do not wish to send multiple request because that would make application read file again and again adding to which I would need to maintain a state/offset (possible solution but avoiding it).
I tried to check for JAX-RS using Asynchronous Response but that doesn't seem to help. I am not sure if HTTP/2 is gonna help.
Please help me understand how this can be achieved, and if I would need to implement socket programming at client and server side or if there is any such protocol which can be used. I am open to modify tech stack.
Thanks
You can use any protocol that supports long lasting streaming connections (which there are many).
If you're already using JAX-RS, then StreamingOutput might be what you want.
After bit of more searching I finally found a bunch of ways of achieving what I mentioned. Before I would like to explain how it cannot be achieved using HTTP (Rest specifically).
HTTP Way: There are few ways in HTTP and/or HTTP2 where you can create a long lasting connection using long-polling in both versions or using multiplexing property present in http2. In both cases the underlying protocol in TCP so there not much difference. However, in HTTP/HTTP2 transactions occur in a fashion where once server receives a request and sends response back, it doesn't expect client to receive response again neither client expects to receive one. So one complete cycle includes a pair of request and response. Hence, if you try to send another response you cannot do that because neither client nor server would be able to receive or send that respectively. There are many resources in Google for more in-depth information.This has a good explanation and references
So I tried to check if I can use some socket coding in order to keep the connection alive and transmit data. Luckily I stumbled upon another way to achieve that.
Two of which I felt make more sense for my requirement are as follows. I would not try to explain them just to avoid providing wrong information here since I myself am trying to get more insight.
1. Server-Side Events(SSE)
2. WebSockets
This will give a fare idea about them.
I have this situation where I need to store data in a database and emit an event to only specific sockets. This can be done in two ways :
Emit an event from the client side, listen to that event on the sever side, store the data and emit the event to sockets we want.
Send a http request to the server, where I store the data and emit the event to sockets.
I was wondering which one of these methods is efficient and is there any better solution to the use case than these two.
I would say that if you are already using SocketIO, it might be a good idea to go with option 1, emiting an event from the client side. I am not sure how your application is structured, but I presume that when you use SocketIO in the first place, you will do all your server side communication through there anyway.
HTTP requests have an obvious overhead to them as they - at the very least - send headers to the server.
However when you begin long polling you'll always need to make sure that it doesn't create a massive load on the server. Now I see that you have node.js in your subject, which I hope is what you use. If that is the case, then this will not create any problems as node.js is very good in handling these requests at almost no cost of system resources.
Disclaimer: I am no expert on the raw technical details which is best or not, I am a mere developer with an opinion. I don't mind down voting, but please let me know why so we can all learn.
I'm just wondering if there is a way to have a server push information to a JavaScript function. Essentially I have a Dashboard-type page that has a javaScript function to get updates from the server and update the dashboard.
I would like my server to be able to "ping" the JS.
I don't even know how that could be possible (I'm guessing Twitter and Facebook use polling?), but I'd thought I ask.
I heard of Comet, but I don't know if that works with a plain standard IIS 7 installation? (It's a SharePoint 2010 site if that matters in any way) If I understand it correctly, Comet is essentially a constantly open connection, so it seems like it's actually the opposite of what I want (reducing # of requests and therefore load)
If you're looking for a comet server for IIS, check out WebSync; it's exactly that :)
Truly initiating a connection from the server is not possible using HTTP. Comet isn't really a single technique, but a set of different workarounds (many of which are described at the article you linked).
For information on Comet techniques with IIS, see the prior question, Comet Programming in IIS. One of the programs discussed there is WebSync.
A Comet style workaround is the most common way to get this functionality. The connection is not constantly open, but rather throttled to make calls every x seconds, then try again upon timeout. The timeout essentially means that the server didn't have anything to give to the client in the duration of the poll. You'll see that the Etherpad code used this same approach, which has been integrated into other Google products now like Google Docs and Wave.
As Samuel Neff says, "You're going to need an open connect to "push" data from the server to the client."
You can use a service like pubnub to open persistent connections from the client and support fallbacks for older browsers.
I made a small demo to show you how the front-end of this application may work. The demo shows PubNub latency over time. The source is available here.
The browser subscribes to a channel and fires a callback when a message is received.
pubnub.subscribe({
channel: 'my_channel',
message: function(m){console.log(m)}
});
In the demo the client also publishes messages. In your case you would include the PubNub IIS library.
pubnub.Subscribe<string>(channel="mychannel", DisplaySubscribeReturnMessage, DisplaySubscribeConnectStatusMessage, DisplayErrorMessage);
// NOTE: DisplaySubscribeReturnMessage, DisplaySubscribeConnectStatusMessage and DisplayErrorMessage are callback methods
You're going to need an open connect to "push" data from the server to the client. So even if you went the route of using a plugin like Flash to open a socket connection which supports two-way communications, you have an open socket connection.
Your statement "reducing # of requests and therefore load" really is problematic. You're equating number of requests with load and that is not accurate. With Comet the majority of requests are waiting on data. Therefore you can have a very high number of requests, but really a very low load on the server--it's hardly using resources besides a waiting thread from the worker thread pool.
Use Comet. Works great, is simple to implement, and does exactly what you need.
You have to do it the other way around, by having the client "pinging" the server with JS.
You can do something like:
function pollServer()
{
// Get some parameter
var param = .......
AJAXCall("page.php?param="+param, onReturn);
}
function onReturn(response)
{
// do something with response
setTimeout("pollServer()", 5000);
}
pollServer();
AJAXCall being the function you use to do an AJAX call and that calls onReturn when it gets a response.
Once it gets a response it waits in this case 5 seconds and polls the server again