QueryAPI

The package devextreme-query-mongodb exports a function called query. Call this and pass a MongoDB collection with a loadOptions structure, and optionally processing options. Here is a simple example:

const MongoClient = require("mongodb").MongoClient;
const query = require("devextreme-query-mongodb");

async function queryData() {
  MongoClient.connect("mongodb://localhost:27017/testdatabase", (err, db) => {
    const results = await query(db.collection("values"), {
      // This is the loadOptions object - pass in any valid parameters
      take: 10,
      filter: [ "intval", ">", 47 ],
      sort: [ { selector: "intval", desc: true }]
    });
		
    // Now "results" contains an array of ten or fewer documents from the 
    // "values" collection that have intval > 47, sorted descendingly by intval.
  });
}

Processing options

In addition to the collection and loadOptions parameters, the query function accepts an optional configuration object. These are the available options:

Option	Details
replaceIds	replaceIds is set to true by default. The effect of this is that _id field values are returned as strings, instead of using the MongoDB internal object representation. The default value is set under the assumption that data will be passed on to parts of the application system where the origin of the id values should not be visible. Since MongoDB doesn't have a built-in way (as far as I know) of returning id values as strings, there is a certain overhead associated with this approach. In cases where you are going to process the data further using other MongoDB queries, or if you use your own structures for id values, it might be beneficial to pass false for replaceIds.
summaryQueryLimit	summaryQueryLimit is a safety-net style workaround for a situation where group queries are executed to return large result sets, and group summaries are required at the same time. Separate queries need to be executed internally to calculate various summaries, and if this is accidentally done for all groups it can result in an increase in processing time to the extent that other parts of your architecture encounter timeouts. Realistically this shouldn't happen as long as group queries are combined with reasonable take values. But with certain combinations of flags (server-side grouping and summaries, but no groupPaging) the Data Grid executes queries that result in this issue. The default summaryQueryLimit prevents more than 100 summaries from being calculated, which should suffice in most cases. In case you want to deactivate this mechanism, you can set summaryQueryLimit to 0 (zero).
timezoneOffset	timezoneOffset is set to 0 (zero) by default. It is relevant if you use field postfixes like Month or DayOfWeek (see loadOptions) for either filtering or grouping. MongoDB stores Date values in UTC time, using the server time zone to convert, and for the aggregation pipeline features that are used by devextreme-query-mongodb, it does not do anything to convert the values back to a client time zone. (There is an outstanding issue recorded for MongoDB to fix this behavior.) By setting timezoneOffset to your client offset, you instruct devextreme-query-mongodb to modify the stored Date values by the offset before extracting the Month, DayOfWeek... details. The value used for this parameter should have the "format" returned by the function Date.getTimezoneOffset(). For instance, if your local time is one hour ahead of UTC, you should use -60 for timezoneOffset. Note that this feature does not help in situations where your client time zone is different from the server one. In such cases, you need to convert time values on the client before persisting them, and convert them back after querying them.

For clarity, a query call that passes processing options might look like this:

const results = await query(db.collection("values"), {
  filter: [ "intval", ">", 47 ],
}, {
  // these are processing options
  replaceIds: false,
  timezoneOffset: new Date().getTimezoneOffset()
});

Technical details

Details of the implementation (as of March 24th 2017) are described at the bottom of this blog post.