MongoDB GraphQL release points to broader revamp of serverless platform

With support of the GraphQL lightweight query language entering preview, MongoDB is taking the next step toward a broader evolution of its serverless application cloud platform with a nod to mobile and web apps.
Written by Tony Baer (dbInsight), Contributor

This week, MongoDB is announcing the preview of support for the GraphQL language for accessing its serverless application platform. The benefits of utilizing GraphQL, an open source query language originally developed at Facebook, is that it is far more efficient for the types of "reactive" or "dynamic" apps that are common in web and mobile development.

But the GraphQL preview is just the tip of the iceberg for the changes that are on MongoDB's roadmap for its application platform. Hold that thought.

GraphQL is an alternative, both to MongoDB's own query language, and to the REST API for accessing data in JSON format.

Compared to MongoDB query language, GraphQL is stripped down; it is designed for issuing simple queries that retrieve only the minimum amount of data necessary. By contrast, MongoDB query language is a more full-functioned traditional database language, designed to support more complex queries – exactly the opposite of what you expect when interacting from a smartphone.

As to API, there is a comparison with REST because GraphQL combines query language and an API. Its API is far more efficient than REST; while GraphQL can typically get data with just a single request statement, REST often requires multiple back and forth statements and therefore eats up a lot more bandwidth.

Facebook created GraphQL for its now ubiquitous mobile client. It required an efficient query language for JSON that, behind the scenes, could probe the intricate relationships between documents represented by the knowledge graphs that power Facebook, and then populate your news feed, fast. That explains the name: while GraphQL was not designed as a graph database query language per se, it was meant for crawling knowledge graphs.

GraphQL is a key cog in the wheel for MongoDB's application strategy that got a major refresh with last spring's Realm acquisition. Realm is a mobile database that provides developers with an alternative to SQLite and CoreData.  Realm and its synchronization platform will replace MongoDB's existing Mobile database and mobile sync offering as part of the managed Atlas cloud service.

MongoDB has been very public about the MongoDB Realm roadmap that will include the fusing together of several parts. Besides GraphQL as the query language, Realm as the mobile database and synchronization platform, MongoDB is also blending in its serverless platform which includes functions and triggers, authentication, data access rules, and server-side code deployment. Serverless platforms are popular with mobile developers because they don't have to worry about having to provision servers for unpredictable and highly spikey workloads.

The roadmap will unfold in several stages over the course of this year. Currently, Realm is available in private beta for manual deployment; GraphQL, being announced today for preview, will provide simplified client-side access. Later this spring will be the public beta of Realm, which at that time will supersede MongoDB Mobile and MongoDB Sync. In the summer, the plan is to integrate Realm into the serverless back end with SDKs, although some odds and ends such as consolidating all the billing for mobile sync services and query-based sync will come later on.

There are a bunch of moving parts in all this as, for instance, Realm objects are different from the JSON objects that are persisted in the MongoDB mother ship, and often carry different dependencies. The unified SDK will hide all the complexity under the hood.

This is not the first time that MongoDB has taken advantage of a new acquisition to make a technology leap. Just over five years ago, MongoDB acquired WiredTiger, and then used the new acquisition to replace its original MMAP storage engine that had scaling issues a year later in the 3.0 version. Arguably, that was a much more radical shift, as it entailed migrating the entire installed base.

Editorial standards