Navigation

MongoDB Atlas Overview

Introduction

Stitch provides a first-class service interface for MongoDB Atlas that lets you securely query one or more Atlas clusters. You can use standard MongoDB query language syntax to access your data directly in your client application code or from a Stitch Function.

The MongoDB service secures your data with a dynamic, role-based Rules engine that proxies and modifies incoming queries based on rules that you define. There are three types of MongoDB collection rules: roles, filters, and document schemas.

Get Started

To get started with the MongoDB service, link a cluster to your application and define roles and permissions for a collection. After you’ve created at least one role, you can start to work with data in the collection.

Concepts

CRUD & Aggregation Operations

Stitch allows you to securely work with data in a MongoDB Atlas cluster directly from your client applications and Functions using standard, platform-idiomatic MongoDB query syntax.

The following guides demonstrate how to use MongoDB service actions to work with data in a linked cluster:

Define Collection Rules

Stitch dynamically determines which documents and fields in a collection each application user can read and write for all incoming query operations by evaluating collection rules that you define.

If you do not define rules for a collection, queries on the collection will fail.

Advanced MongoDB Queries

Stitch does not support all MongoDB CRUD and Aggregation operations when you query MongoDB as a specific user. You can bypass this limitation by querying MongoDB from a Function that runs as a system user, which has access to the full MongoDB CRUD and Aggregation APIs.

For more information on which operations are unsupported, see CRUD & Aggregation APIs.

Collection Rules

In traditional applications, an application server exposes an API to client applications and handles database queries on their behalf. To prevent malicious, improper, or incorrect read and write operations, clients don’t query the database directly.

Stitch provides a configurable and dynamic rules engine that enables you to run a MongoDB query from client applications while transparently preventing unauthorized reads and writes. Rules are defined for entire collections in a linked MongoDB Atlas cluster and apply to individual documents in the collection dynamically based on the application user that issued a query.

The rules engine handles incoming queries with the following 4-step process:

1

Find All Relevant Documents

Stitch evaluates the queried collection’s Filters in the context of the incoming request. Filters dynamically add additional query predicates and projections to incoming queries based on an expression that you define.

After evaluating, Stitch applies all relevant filters to the incoming query and then finds all documents that match the filtered query.

Query Filters

To learn how to configure a query filter for a collection, see Filter Incoming Queries.

To learn more about filters, explore the Query Filters reference page. There you’ll find more information, including configuration parameters and details on how Stitch applies filters.

2

Evaluate A Role For Each Document

Stitch evaluates a Query Role with specific read and write permissions for each document that matches the filtered query. You define the roles for each collection, including the permissions they have and the conditions under which they apply.

Roles

To learn how to configure roles for a collection, see Define Roles and Permissions.

To learn more about roles, explore the Query Roles reference page. There you’ll find more information, including configuration parameters, use-case examples, and details on how Stitch assigns roles to documents.

3

Run The Query With The Assigned Roles

Once Stitch has evaluated a role for each document, it runs the filtered query and prevents reads and writes on each document unless the document’s role allows them. If no role applies to a specific document, Stitch withholds that document entirely and prevents the query from reading or writing any fields.

4

Validate The Document Schema

If the query was a write operation, Stitch checks each affected document to ensure that they conform to the collection’s Document Schema. If any document does not match the schema, Stitch rolls back the operation and rejects the query.

Document Schemas

To learn how to configure a schema for documents in a collection, see Enforce a Document Schema.

To learn more about schemas, explore the Document Schemas reference page. There you’ll find more information, including schemas for common data types, configuration parameters, and details on how Stitch enforces document schemas.

Considerations

System-Generated Cluster Users

Stitch automatically creates a MongoDB user for each app linked to a cluster. These users are for internal use only and cannot be edited or manually deleted. If you delete a Stitch app, the associated user will also be deleted.

Users generated by Stitch have names of the form: mongodb-stitch-<your app id>

Accessing Application Data with Another Tool

Stitch connects to standard MongoDB Atlas clusters, which means that you can connect directly to a linked cluster using another tool such as the mongo shell or MongoDB Compass. There are no special considerations when reading data from a linked cluster with another tool.

While running update operations, Stitch temporarily adds a reserved field, _id_stitch_transaction, to documents. Once a document is successfully updated, Stitch removes this field. If you want to use another tool to modify data in a collection, ensure that you $unset this field prior to making changes.

For example, if you are using the mongo shell to update documents in the products collection, your command might resemble the following code:

db.products.update(
   { sku: "unknown" },
   { $unset: { _id_stitch_transaction: "" } }
)