Meteor - Database - Miscellaneous


What are the advantages of having database on the client side?

By default, Meteor comes with a version of MongoDB that works both on the server and the client. On the server, it works as you might expect it to, but the database on the client is more of a pseudo-database. What I mean by this is that Meteor has an API written to mimic the Mongo API, but for a custom database that is cached in memory on the client. This allows you to send subsets of data. For instance, if you only want the user to have certain rows, or you don't want to send the password column, Meteor allows you to simply "publish" the info you want, and Meteor will treat it as a database on the client, allowing you to make your application faster.

By putting the database on the client, you can feed the database straight into your HTML page. For instance, in the previous example, instead of getting the products from an array, we can feed in the products database. So anytime the database changes, your updates will be pushed in realtime to all the clients.

Another plus for having the database on the client is that it allows you to use MongoDB's sorting API to automatically sort the elements on the page at the database level, which, again, saves you that much more time, when developing your application.

You can either add records in code or in your browser's console. Either way, you would use the insert command on the Products variable. Here is an example:

Products.insert({Name : "Hammer", Price : 4.50, InStock : true});
Products.insert({Name : "Wrench", Price : 2.70, InStock : true});
Products.insert({Name : "Screw Driver", Price : 3.00, InStock : false});
Products.insert({Name : "Drill", Price : 5.25, InStock : true});

To optimize for responsiveness, when the user interact with the page, meteor may do the following:

  1. update the UI, then update the database on the client side, which then send the change to the server.
  2. update the database on the client side, then update the UI, and then send the change to the server.

By doing this, Meteor doesn't need to wait for the database to update, and your users will see the changes immediately as they make them. On the rare occasion when your update doesn't reach the server, Meteor will reconcile your data and push the updates to the browser, without you needing to write a single line of code.

What is a collection?

Collections are Meteor's way of storing persistent data. The special thing about collections in Meteor is that they can be accessed from both the server and the client, making it easy to write view logic without having to write a lot of server code. They also update themselves automatically, so a view component backed by a collection will automatically display the most up-to-date data. You can read more about collections in the Collections article of the Meteor Guide.

Creating a new collection is as easy as calling MyCollection = new Mongo.Collection("my-collection"); in your JavaScript. On the server, this sets up a MongoDB collection called my-collection; on the client, this creates a cache connected to the server collection.

To create the collection, we define a new tasks module that creates a Mongo collection and exports it:

import { Mongo } from 'meteor/mongo';
export const Tasks = new Mongo.Collection('tasks');

How does this publication and subscription thing work?

In a traditional, HTTP-based web application, the client and server communicate in a “request-response” fashion. Typically the client makes RESTful HTTP requests to the server and receives HTML or JSON data in response, and there’s no way for the server to “push” data to the client when changes happen at the backend.

Meteor is built from the ground up on the Distributed Data Protocol (DDP) to allow data transfer in both directions. Building a Meteor app doesn’t require you to set up REST endpoints to serialize and send data. Instead you create publication endpoints that can push data from server to client.

In Meteor a publication is a named API on the server that constructs a set of data to send to a client. A client initiates a subscription which connects to a publication, and receives that data. That data consists of a first batch sent when the subscription is initialized and then incremental updates as the published data changes.

So a subscription can be thought of as a set of data that changes over time. Typically, the result of this is that a subscription “bridges” a server-side MongoDB collection, and the client side Minimongo cache of that collection. You can think of a subscription as a pipe that connects a subset of the “real” collection with the client’s version, and constantly keeps it up to date with the latest information on the server.

How can we find related documents?

As we discussed earlier, it’s very common in Meteor applications to have associations between documents in different collections. Consequently, it’s also very common to need to write queries fetching related documents once you have a document you are interested in (for instance all the todos that are in a single list).

To make this easier, we can attach functions to the prototype of the documents that belong to a given collection, to give us “methods” on the documents (in the object oriented sense). We can then use these methods to create new queries to find related documents.


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License