Cómo simular la latencia en la inserción/actualización/eliminación de la colección de meteoritos

Cuando llamo Meteor.methods uso

var wait = function(sim){
  if (!sim) {
    var Future = Npm.require('fibers/future');
    var future = new Future();
    Meteor.setTimeout(function() {
      future['return']();
    }, latency * 1000);
    future.wait();
  }
};

para simular latencia en el servidor. ¿Hay alguna manera de simular latencia cuando se trata directamente con Meteor.collections?

update:

quiero llamar

mycollection.insert({whatever:iwant}, function(error, result){   
   ... show that the server collection is updated now ...
});
... show that the server collection is not updated yet ...

Para probar este comportamiento, quiero simular la latencia en el servidor como lo hago para las llamadas a Meteor.method.

0
lo siento, creo que no explica lo que quiero hacer, correctamente. actualicé mi publicación.
agregado el autor fastr.de, fuente
Se compensa automáticamente en el cliente. Eso es lo que sucede con Meteor: incluso si simula latencia para DDP, no notará nada, a menos que defina diferentes reglas de permiso/denegación en el cliente y el servidor. El cliente alimenta colecciones a través de minimongo, por lo que el cliente nunca espera la respuesta del servidor para realizar una acción; solo utiliza la respuesta del servidor para reparar el Minimongo DB si no está de acuerdo.
agregado el autor sbking, fuente
La latencia se simula automáticamente en el cliente con métodos de recopilación como insertar/actualizar/eliminar, pero ¿qué significaría simular latencia en el servidor ?
agregado el autor BenjaminRH, fuente

1 Respuestas

También puedes simular la latencia usando métodos del lado del cliente

Llamada del lado del cliente

Meteor.call("something");

El lado del cliente 'método virtual'

Meteor.methods({
    something:function() {
        Collection.insert({this_is_virtual: true});
    }
});

Método del lado del servidor

Meteor.methods({
    something: function() {
        wait();
        Collection.insert({this_is_virtual: false});
    });
});

El método del lado del cliente creará datos falsos en aras de la compensación de latencia con el valor this_is_virtual como true . Tan pronto como lleguen los datos reales, cambiará a falso.

Puede usar esto para crear datos simulados en el cliente. Los mismos métodos también se pueden usar en el lado del servidor. Puede usar this.isSimulation para determinar si se trata de un método de compensación de latencia, 'virtual'.

Las colecciones del lado del cliente se agregan usando esta 'compensación de latencia'. De modo que incluso si tiene latencia simulada, no haría nada .

Este es uno de los principios fundadores del meteorito. Si quieres evitarlo, deberías usar un método/llamada como el anterior, pero sin un talón de simulación del lado del cliente. Pero sospecho que esto no valdría la pena porque la compensación de latencia es una característica útil.

0
agregado
@Mitar el _id se genera en el cliente y espera que el servidor lo confirme. Ver github.com/meteor/meteor/blob/devel/packages/mongo-livedata/& zwnj; & hellip;
agregado el autor Akshat, fuente
gracias por su respuesta, pero sé cómo funcionan los métodos y que las colecciones son Meteor.methods también internamente. Espero que mi actualización ayude a aclarar lo que estoy tratando de hacer.
agregado el autor fastr.de, fuente
¿Cómo se sincroniza _id s entre el cliente y el servidor? Si llamo a Collection.insert en la simulación, ¿cómo ocurre que Collection.insert genere el mismo _id en el servidor?
agregado el autor Mitar, fuente
Pero esto solo ocurre cuando llamas Collection.insert directamente, no desde dentro del método. Ver github.com/meteor/meteor/issues/881
agregado el autor Mitar, fuente