How do i call a NodeJS RESTful Web service automatically when a data is stored in Google Realtime Firebase? For example, once i stored user details to firebase my restful webservice should detect the data and perform changes on the data. My code works perfectly fine but my question is how do i make it perform automatically without me running the server remotely.
You can do it using two ways:
(1) Traditional approach:
you can implement polling, basically calling your rest API again & again at a
certain interval; get the data & check for change
(2) Websockets(I like it more):
You can also use WebSockets, basically, web sockets can maintain a live two way communication with the server
. Reference on how to use WebSockets can be found here
https://developer.mozilla.org/en-US/docs/Web/API/WebSocket
I think that you can use an event listener and depending on the event a specific part of your code will be executed. Check the documentation for what suits you https://firebase.google.com/docs/database/admin/retrieve-data
Related
My application interacts with my users' websites via a javascript snippet that they paste into their site....like Google Analytics, Stripe, AppInsights...etc.
I'd like for my web app to be able to ping the remote site, to verify the pasted snippet exists. If it does exists, I'd like the remote javascript method to respond.
I feel like this should be easy but I'm having trouble putting it all together. For the remote script, I made it so it checked the querystring for a trigger value...if found, it would execute a 'self check' and respond.
I wasn't quite sure how to make the script respond to my ajax call and I also didn't necessarily like the idea of checking the querystring every window.load
Can anyone point me in the right direction or suggest a more elegant approach? Thanks
I think you have to think it all the other way around. How these kinds of scripts are working is that they have an API key generated just for that website and when the website is loaded it is the JavaScript code snipped that does send the API key to the API generated server to show that the snippet is available and gives the information about the page that it is loaded in.
This way you don't need to check if the snipped is available in a website. Of course if you need consistent dialog with the snipped you have to use Web Socket or other ways of communications (for the older browsers like long polling and ...)
For sure not using Web Socket and two-way communication gives the trust to the user that you are not doing any malicious work underneath and the first approach should help you enough. But if you persist on using the two-way communication please see MDN WebSocket documentation .
The first approach (not using two-way communication) is just an ajax call you can do it with JQuery: jQuery AJAX documentation, or do not use any library just pure JavaScript which is John Shipp on Vanilla JS AJAX requests .
I'm building a Tornado based server that basically allows the user to upload an image, does some processing on the backend and returns some updates during and after the processing.
I've implemented a basic server using Handlers, which works nicely.
The problem is that the handler interface doesn't allow me to communicate with the client, but only to re-render the entire page.
I've considered using WebSockets, but from what I see they shouldn't be used for image uploading, so it kind of kills this option.
Is there any other way to communicate with a specific client from an Handler (i.e render only part of the page, trigger some js event and so on).
Thanks :)
Are you using POST and GET methods in your handlers?
If you're using a GET method to receive the image from your client, you can communicate with the client by returning data using the self.write(json_data) method. (http://tornado.readthedocs.org/en/latest/guide/structure.html) However, once the GET method returns the request is considered to be finished, so you might not be able to send multiple updates.
Also, can you also configure the client side? I'm assuming you're using a JSON GET method to make a call to the tornado server, and in that case you can just link certain responses to different js functions in the client-side code.
I am using the Parse.com database service for a PhoneGap app we are creating. We have users that can mark themselves (First User) "Available" for their friends (Second User), and I need a way to listen for that toggle in availability on the second user's side, so their friends list can update without having the refresh the page.
With Parse, your interaction with the database is monitored by # API calls and Burst Limit (Number of API calls per second) so I need to only call the database for the change in status when it is actually changed, I can't keep a setInterval on otherwise it will make the burst limit too small for other user, or it will cause to many API calls for no reason if the status isn't changing.
How can I got about this?
You should try socket.io with intercom.js. The first one does the pushing to the client, the second one ensures that only a single socket is open by multiple tabs. Socket.io has multiple fallbacks on client side, it can use websockets, flash, maybe even long-polling I guess...
The server side should support sockets. By nodejs it is very easy. By classical http languages, for example php+apache just the long-polling will work I think.
Be aware that your data pushing application will be socket based and not request-response based, so it won't be part of you webservice. Probably you should only push, that the user list must be refreshed. So there won't be any duplicated code...
I would like to retrieve table data from a REST backend server with angularjs. The data changes by the second. I would like to use angularjs to refresh the data as it changes in real-time. How can this be done? Do I force angularjs to make ajax calls at regular time intervals to refresh the data display?
Yeah with REST there's no other way then polling. To refresh the data itself in the browser view you can use $rootScope.$apply() in the service (I presume that you're using a service to get the data), first you have to inject the dependency of $rootScope of course.
EDIT
Actually you shouldn't use $rootScope.$apply(), because it can lead to ugly $digest in progress errors. Instead use
$timeout(function(){
// set data here...
})
A tip for improvement if you're not happy with the polling and if you have programmed the backend or are in position to change it, is:
Try to use WebSockets:
It gets rid of the polling, because then your browser can communicate directly to the server.
It has less overhead.
It is supported in the major browsers and you can use libraries with fallback mechanisms like SocketIO
The server can then always push the data right then, when it's available. The server-side implementation depends on the backend you are using, but most backend frameworks/servers nowadays also support websockets.
You have to either use the poll or push strategy. However, since you already know that the resource changes regularly, it should be enough to setup a recurring timeout so that your application polls the resource on the REST server every second. Once it is retrieved, AngularJS updates the view. So, yes you have to force AngularJS to make calls to the service.
I have a service method written in ASP.Net WebAPI :http://diningphilospher.azurewebsites.net/api/dining?i=12
and JavaScript client gets the response and visualizes it here
But the nature of Dining Philosophers problem is I never know when the Dead-lock or starvation will happen. So Instead of having a request/response I would like to stream the data through service method and client side JavaScript read the data I assume JSON asynchronously. Currently several post directs me towards changing the default buffer limit in WebAPI so you get a streaming like behavior.
what other(easy or efficient) ways exist to achieve this above behavior.
You can return PushStreamContent from ASP.NET Web API and use Server Sent Events (SSE) JavaScript API on the client side. Check out Push Content section in Henrik's blog. Also, see Strathweb. One thing I'm not sure about the latter implementation is the use of ConcurrentQueue. Henrik's implementation uses ConcurrentDictionary and that allows you to remove the StreamWriter object from the dictionary corresponding to the clients who drop out, which will be difficult to implement using ConcurrentQueue, in my opinion.
Also, Strathweb implementation uses KO. If you don't like to use KO, you don't have to. SSE JavaScript APIs have nothing to do with KO.
BTW, SSE is not supported in IE 9 or lesser.
Another thing to consider is the scale out option. Load balancing will be problematic, in the sense there is a chance that the load will not be uniformly distributed, since clients are tied to the server (or web role) they hit first.