Un café con leche

Vamos a ver un ejemplo al que he llamado cowboy-coding. Lo puedes clonar desde el repositorio.
 La estructura de ficheros es como sigue:
 .
├── client
│   ├── index.html
│   └── main.coffee
├── lib
│   └── collection.coffee
├── server
│   └── publications.coffee
├── smart.json
└── smart.lock

Y pasamos a explicar cada cosa. Lo primero es que aquello que está bajo la carpeta client se empaqueta y se manda al cliente. Al servidor por el contrario se le enviará un paquete con todo aquello bajo la carpeta server. Lo que está en la carpeta lib se manda a ambos: aquí es donde se pondrá todo el código que debe ser visible para ambos lados, como las colecciones de datos o las funciones de validación de un objeto, que debe ser validado tanto en el cliente como en el lado del servidor.

Veamos el fichero collection.coffee:

Se ejecuta tanto en el lado del cliente como en el servidor. En el cliente se trata de objetos proxy (minimongo) que redirigen las llamadas al servidor, el cuál ya insertará los datos en BDD. Meteor se basa en el concepto de latency compensation, que significa que en el lado del cliente, por ejemplo, se acepta el insert y se pinta en pantalla antes de tener noticia desde el servidor que efectivamente ha sido exitoso el insert. En las raras ocasiones en que no lo es, simplemente el sistema de renderizado del template ya no hace visible al objeto (se elimina de minimongo por supuesto).

Continuamos con el servidor, publications.coffee:

En el lado del servidor especificamos un sistema simple de permisos (lo podemos hacer más granular; ese es el propósito de mi paquete code-permissions) y las publicaciones de datos. En este caso permitimos a los clientes subscribirse a una publicación de todos los items que comienzan por la letra que se especifique. Así, si el cliente A se subscribe a los items que comienzan por la letra 'a', y el cliente B inserta un nuevo item que comienza por esa letra, el cliente A verá inmediatamente el nuevo item.

Veamos pues el lado del cliente:

y:

En el lado del cliente hay que filtrar de nuevo por los items que comienzan por la letra subscrita (en lugar de hacer items.find({}) ). Esto es debido a que si estamos subscritos a otra publicación (por ejemplo los que terminan por otra letra), si no hacemos el filtro en el lado del cliente, se pintarán en pantalla todos los items que están en el minimongo del cliente.