It’s been a while since MongoDB has felt threatened by another document database vendor. Historically, the closest contender for document database dominance was Couchbase, the offspring of the original CouchDB database, which arguably ignited the document database segment.
Couchbase adoption has long trailed that of MongoDB, though Couchbase still has a vibrant and loyal user base. Couchbase was also known for some technical innovations that MongoDB historically lacked. For instance, Couchbase has long offered a mobile synchronization capability, allowing an application to run CouchBase on a mobile device and periodically synchronize with a master server.
At this year’s MongoDB World, MongoDB announced mobile sync capability similar to that offered by Couchbase. MongoDB Mobile—in beta at time of writing—provides the ability for a mobile application to read and write from a locally cached version of a MongoDB database whose master copy resides on a server. When the mobile device re-establishes connectivity with the master database changes will be synchronized.
The application coding for the MongoDB mobile capability is very close to the patterns familiar to developers already working with MongoDB. In the simplest case, the application need only call a new “sync” method to synchronize changes between the mobile device and the server. However, as with any online/offline synchronization scheme, the developer is responsible for handling synchronization conflicts. What happens if two mobile devices both change the address of the same customer while in offline mode?
Behind the scenes, MongoDB mobile uses a technology called Change Streams. Change Streams were introduced in MongoDB 3.6 and allow applications to monitor and respond to any changes to collections. Change streams can be used to implement tailored replication flows between disparate databases. For instance, an application might monitor a MongoDB database for changes to addresses and send SQL UPDATE statements to a matching table in a relational database.
The MongoDB stitch service allows the application developer to deploy this sort of logic directly into the MongoDB backend. Stitch was originally described as a “backend as a service,” allowing developers to create integration routines and deploy them directly into the MongoDB cloud. Today, MongoDB described Stitch as a serverless framework for building cross-platform applications.
By now relational database veterans are likely to be thinking of RDBMS stored procedures and triggers. To be sure, Stitch functions are the closest thing to stored procedures offered by MongoDB and Stitch triggers are, well, triggers. However, there are some significant differences.
Stitch functions execute close to the database, but unlike stored procedures in Oracle or SQL Server, they are not running inside the database server. They do not, therefore, offer quite the same reduction in network overhead. Stitch triggers can respond to changes in the database, but unlike RDBMS triggers, they cannot be used to reject a change. So, you cannot use Stitch triggers to implement database integrity rules.
Stich is in some respects a confusing product offering—it’s not a database, but not an application server either. So, what is it? As we see MongoDB creating more an more services that rely on Stitch it is becoming clear that Stich is a tightly coupled layer on top of the MongoDB cloud database that offers the ability to run business logic and integration code. As more and more MongoDB deployments migrate into the cloud, expect to see more applications take advantage of the Stitch framework.