Question says it all really. I can setup a page at a known location, and make sure the http request works, but that feels kinda hackey.
Meteor.status() is a client side function which will help for individual clients within the Meteor context. Your best bet for a platform-agnostic check is a DDP client that lives outside your Meteor environment. (True, the Meteor folks proposed the DDP client, but the intention is that it serve as a protocol for real-time platform, not a tightly coupled part of the Meteor architecture).
In practice, then, you'd need to wire up a DDP client and subscribe to a server-side publication, returning whatever defines 'running' in the context you require. This could be simply a collection of mongo documents, or some status checks based on more complex set and unset method calls within your publish function.
Here are a couple DDP clients I've found
DDPClient.NET
node-ddp-client
ruby-ddp-client
Hope that helps.
Related
How does a meteor application deal with server-side methods for inserting and updating? especially:
if an application is temporarily offline (available through appCache-package) and a call to a server-side
method happens: is optimistic-ui possible? how does it work?
do i
need to define the (usually server-side) methods in /libs
directory instead of /server?
Thank you
You should put your collections under libs and use Collection.allowand Collection.deny to control the permission on both server and client side.
In meteor, most of the time you're dealing with client side data, Meteor will save them to the Minimongo and synchronize your update to server when available.
Regarding to method definition, it really depends on where you want to use it, only a few things you'll put on server, e,g, authentication logic, encryption salt
Are Meteor.methods they only way to call server-side functions from the client?
http://docs.meteor.com/#/full/meteor_methods
the docs don't make it clear that they are they only way, but the fact that they exist seems to imply they are the only way. What is their purpose?
There are several ways to communicate back and forth between the server and client in Meteor :
Using Meteor.methods to perform Remote Method Invokation on the server, these calls are initiated by the client, ask for a computation to be performed on the server and receive a result.
Using the Pub/Sub mechanism, the server publishes a set of data and the client is subscribing to a subset of this data, being notified in real-time of data-updates taking place in the server and thus receiving modifications.
Using plain old HTTP requests with the HTTP module.
So Meteor.methods are not the only way to execute some code on the server upon a client request.
Their purpose is usually to update the database by providing new values for server-side collections, as a matter of fact, client-side collection inserts and updates are implemented as Meteor.methods.
The Pub/Sub mechanism is used to propagate DB updates to every connected client and to make sure they receive only the minimal subset they need.
The HTTP communication is used by the server to send the initial source code (HTML/JS/CSS) of the app on load time as well as performing standard operations such as requesting and downloading a file.
For manually testing an HTTP client in my application, I'd like to use a tool which starts an HTTP server my application can connect to and that lets me respond to request from my application manually. I'm basically looking for a tool with a GUI that lists all incoming requests and allows me to select a status code and type a response message. I've already tested the functionality with unit tests but I also want to verify it manually with no mocking etc.
Sounds simple but I didn't find such a tool. I've found some that can be scripted but no interactive one. Do you know one?
This can probably be written relatively easily by creating the Swing GUI dialog popup inside the servlet servicing methods. Have never seen Tomcat running this way but probably it would. Only, mind the server time out. It may be not long enough for you to make an input and require to be configured, also on the client side. Also, parallel calls will make multiple popups that may be difficult to respond but probably this is a single client app.
As a simplest solution, server GUI can be simply disposed after call and newly created as the next call arrives. This will make eveything indepenent on how servlet container is managing the servlets (does it stays, is it destroyed, maybe class is unloaded, who knows). Advanced solution could include the "server servlet" that would interact through its own JSP page but then it may be complex to update it when the new call arrives (unless maybe refresh periodically).
Having watched Meteor Framework screencast. I noticed that changing the database seamlessly changes the data in browser. Usually AJAX, just reloads a part of page every few seconds but here I didn't noticed browser reloading. How did they achieve that in Meteor? Is it Node.js dependent?
UPDATE: Toby Catlin poses another interesting question. How does Meteor handle different browsers?
They use both Session and Meteor.autosubscribe (from Meteor API) to ensure that changes are reflected on the clients.
These Meteor APIs use XHR (XMLHttpRequest) by SockJS. SockJS is WebSocket emulation utility. So when something changes on the server, SockJS ensures that an XHR is sent, and the changed data is in the JSON response.
Yes, Meteor is fully dependent on Node.js. From the Meteor docs:
A Meteor application is a mix of JavaScript that runs inside a client web browser, JavaScript that runs on the Meteor server inside a Node.js container, and all the supporting HTML fragments, CSS rules, and static assets. Meteor automates the packaging and transmission of these different components. And, it is quite flexible about how you choose to structure those components in your file tree.
The only server asset is JavaScript. Meteor gathers all your JavaScript files, excluding anything under the client and public subdirectories, and loads them into a Node.js server instance inside a fiber. In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. We find the linear execution model a better fit for the typical server code in a Meteor application.
Sources: http://docs.meteor.com/ and https://github.com/meteor/meteor
There are a few techniques that allow the server to push data into the browser without the browser needing to request it. The term for such technology is Comet [wikipedia.org] and most techniques are related to AJAX (there was a bleach called Comet and a cleaning product called Ajax). There are a number of connection types: long polling, streaming XHR, forever frame, server-send-events and websockets. Socket.IO is a nice library that provides connection types to streaming servers.
You do need a server that will support Comet connections. You can google for current ones but off the top of my head: node.js, tornado, cometd, orbited, Jetty streaming
I would guess that Metor would use different connection types depending of the capabilities of the browser, eg websocket for Chrome and long polling for IE. If anyone can give a more specific answer i would be interested
I am creating a node.js module which communicates with a program through XML-RPC. The API for this program changed recently after a certain version. For this reason, when a client is created (createClient) I want to ask the program its version (through XML-RPC) and base my API definitions on that.
The problem with this is that, because I do the above asynchronously, there exists a possibility that the work has not finished before the client is actually used. In other words:
var client = program.createClient();
client.doSomething();
doSomething() will fail because the API definitions have not been set, I imagine because HTTP XML-RPC response has not returned from the program.
What are some ways to remedy this? I want to be able to have a variable named client and work with that, as later I will be calling methods on it to get information (which will be returned via a callback).
Set it up this way:
program.createClient(function (client) {
client.doSomething()
})
Any time there is IO, it must be async. Another approach to this would be with a promise/future/coroutine type thing, but imo, just learning to love the callback is best :)