For information, Meteor.http
calls are deprecated. The current syntax is HTTP.
Using an empty function()
parameter just means no action will be taken when the HTTP call completes - it continues to run asynchronously and executes that (empty) function when it finishes.
Your options (server side) are:
(1). Synchronous HTTP call:
You can do this on the server by omitting the callback function entirely:
try {
var result = HTTP.get('http://somewhere.com/endpoint/');
// this line will be executed when the get completes (and "result" is available)
} catch (error) {
// We got an error
}
I suspect that this is not what you want - 500 synchronous requests will take a l-o-n-g time to finish. Note that you cannot make an HTTP
call like this on the client successfully, anyway.
(2). Asynchronous HTTP call:
You can do this on the client or the server by passing a callback:
HTTP.get('http://somewhere.com/endpoint/', function(error, result) {
if (error) {
// some error occurred
} else {
// "result" is available here
}
});
From the documentation:
On the server, this function can be run either synchronously or asynchronously. If the callback is omitted, it runs synchronously and the results are returned once the request completes successfully. If the request was not successful, an error is thrown. This is useful when making server-to-server HTTP API calls from within Meteor methods, as the method can succeed or fail based on the results of the synchronous HTTP call. In this case, consider using this.unblock() to allow other methods on the same connection to run in the mean time. On the client, this function must be used asynchronously by passing a callback.
The advantage of doing this on the server is that you make one request to each radio station every 30 seconds. If you do it on the client and you have 500 clients connected, you will be making 500 requests to each radio station every 30 seconds. This sort of use will almost certainly violate their terms of service (you will probably want to check those regardless).
(You can get quite clever with async calls by running them in parallel, in which case the time to completion is the single longest time to complete. Use fibers on the server and promises on the client.)
My view is that if this is the only way to get that information, a server-side timer as originally proposed by @loupax is probably the best way to do it. The whole issue of reactively consuming REST endpoints seems to be cropping up a lot right now and Iām not sure what the best approach is.
EDIT: Wrapped synchronous call in a try/catch block. Made discourse use my block numbering (grrr).