When I do a Meteor.call instead of a direct collection manipulation on both client and server. Does it remove the optimistic UI changes, aka minimongo changes and simply does direct to server change and wait for update on server before updating the UI?
Read the last section of this Meteor doc about 'How latency compensation works'
In Summary
You do lose optimistic data changes as you suspected if your Meteor.method is defined server-side only. In this case, when your client calls the method, you are essentially calling an REST service and waiting for the server-side response before your client can process the response.
When you do a client-side collection manipulation, client-side simulates the changes in minimongo, then tells the server to change the collection, then server updates the client with the server side changes (accepted or rejected).
Note: If you share Meteor.method to client and server, you can get optimistic nature. I've never done this, but read the link
Related
New to firebase and trying to understand how things work. I have an android app and plan to use the offline support and I'm trying to figure out whether or not I need to use callbacks. When I make a call like:
productNode.child("price").setValue(product.price)
Does that call to setValue happen synchronously on the main thread and the sync to the cloud happens asynchronously? Or does both execute asynchronously on a background thread?
The Firebase client immediately updates its local copy of the data with the new value. As part of this it fires any local (value, child_*) events that are needed.
Sending of the data to the database happens on a separate thread. If you want to know when this has completed, you can register a CompletionListener.
If the server somehow cannot complete the write operation (typically because the write violates a security rule), the client will fire any additional events that are needed to get the app back into the correct state. So in the case of a value listener it will then fire a second value event with the previous value.
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.
How can the web server invoke a method on the client synchronously using SignalR? The key part here is that the server should wait for client to send data back to the server before continuing on?
Basically I'm looking to treat a client method invoke like a WCF service request. Invoke the client and wait for the data to be returned.
SignalR does not provide a way to synchronously invoke client-side methods.
To achieve the same functionality as a synchronous call, you could pass some sort of invocation ID as an argument to your client-side method. The client could then invoke a server-side method like ClientMethodCompleted with its invocation ID when the client-side method is done. Basically you will be implementing your own ACK.
If you go this route, you will have to track the client invocations along with their respective ID's on the server. You can then execute whatever logic you would have done after a synchronous call in the ClientMethodCompleted method on the server.
This should be fairly simple if you are invoking the method on only one client. If you are invoking the method on multiple clients you will have to keep track of which clients you are invoking your method on so you can ensure all the clients have acknowledged the invocation before running your followup code.
I would also make sure that you periodically clean up the data structure storing unacknowledged client invocations if you are at all worried about a DOS attack, since this would be an obvious attack vector that could allow a malicious client blowup memory consumption.
Meteor's documentation states:
In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node
Do they actually mean?
A) the server is running multiple threads in parallel (which seems unusual within the Node.js ecosystem)
or
B) There is still only a single thread within an evented server and each request is processed sequentially, at least until it makes calls to resources outside the server - like the datastore, at which point the server itself is handling the callbacks while it processes with other requests, so you don't have to write/administer the callbacks yourself.
Brad, your B is correct.
Meteor uses fibers internally. As you said, there's only one thread inside an evented server, but when you do (eg) a database read, Fibers yields and control quickly gets back to the event loop. So your code looks like:
doc = MyCollection.findOne(id);
(with a hidden "yield to the event loop, come back when the doc is here") rather than
MyCollection.findOne(id, function (err, doc) {
if (err)
handle(err);
process(doc);
});
Error handling in the fiber version also just uses standard JavaScript exceptions instead of needing to check an argument every time.
I think this leads to an easier style of code to read for business logic which wants to take a bunch of actions which depend on each other in series. However, most of Meteor's synchronous APIs optionally take callbacks and become asynchronous, if you'd like to use the async style.
I am loading a gridview using a code based on this:
http://msdn.microsoft.com/en-us/library/ms366515%28v=VS.80%29.aspx
I am using callbacks to populate the grid, sometimes there is a lot of data or the user wants to cancel.
How can I cancel the callback from being processed on the server when user hit cancel??
thanks
Searched quite extensively and found that it is possible to Cancel Server Tasks with ASP.NET & AJAX
Although I'm not good with AJAX, Found some links that will help you,
Here's how to Canceling Server Tasks with ASP.NET & AJAX and here's a forum thread on something similar to your problem.
Hope it helped !
AFAIK, you cannot cancel the server side call back processing once initiated. At the most, you can have some client (browser) side logic that will ignore callback results.
Regardless, I will suggest you to use ASP.NET AJAX (UpdatePanel or Script Services) rather than using ICallbackEventHandler. It's quite simple to use and more flexible. Besides, you also have options such as cancelling callbacks : see this article for cancelling update panel callback (note that cancel really means stop waiting for (& ignoring) callback results, the server side processing would happen).
Once you've initiated a request to the server, the client cannot cancel it. Ignoring the mechanics around any possible "cancellable method", you've started a request with the server. Any further communication will result in a new request, so that original request will continue until it has finished. Remember HTTP is a stateless protocol, each request has no knowledge of any previous request, and because of that, how could it cancel a previous request?
You're best bet would be to just ignore the server response, or if you actually need to cancel a long running task that may still be processing on the server, you need to bake in that support yourself, as the web server will not natively support it. To do that, you'll likely need some way of persisting the task state across multiple http requests, and have the original request (the one running that task) be monitoring some sort of cancellation flag.
Just remember though, in the above scenario, you wouldn't be cancelling the request, but the task the request is running.