Based on the growing demand for a backend-as-a-service product, MongoDB decided to build Stitch, it’s own backend-as-a-service solution.

MongoDB Stitch is a single, document-focused API designed to handle day-to-day database tasks, as in storing and retrieving data, access control, security, and data privacy. In addition, developers can use it to integrate their database with the common services they use for things like payments, messaging, and user authentication.

At present (June 2017) developers can choose from a number of pre-built integrations with services that include Google, Facebook, AWS, Twilio, Slack, MailGun and PubNub. If a particular integration isn’t available, developers can add it through its built-in HTTP service.

MongoDB Stitch is based on MongoDB Atlas (MongoDB's Database-as-a-Service platform) and provides a:

REST API to MongoDB, letting client code interact directly with the databases configuration based access control system, to express which users can perform what operations on what data uniform, document-focused mechanism to connect services with custom application code.

This sounds useful and in fact my quick hacks worked out. I think it will turn out to be very useful to save time on copying all the boilerplate code we use again and again. When things go wrong, it becomes a liability ranging from costly to disastrous. MongoDB wants to target on this kind of aggravation and inefficiency as they say.

MongoDB Stitch consists of three main components:

Pipelines, Services and Rules.

Pipelines

Service pipelines orchestrate data across multiple services by configuring multi-stage pipelines, where each stage acts on the data before passing its results on to the next. Pipelines are reusable functions, stored within the Stitch platform, this can be called from the application frontend, from rules and other pipelines.

Services

Stitch provides a UI to MongoDB’s Database as a Service, MongoDB Atlas, and other 3rd party services. Rather than manually coding against the APIs for each of these services, with Stitch, one can access these external services through a native interface from the application’s frontend.

Rules

Stitch ensures that all aspects of an application can be tightly controlled with intuitive rules. Rules allow to decide whether a specific user has the ability to read or write data for a specific document or field. Also a service action must be run with a set of arguments or can be only run by specified users. A pipeline can be run by a certain user or only in certain scenarios. All of these rules can be defined with JSON, and have full access to globally defined Stitch variables and pipelines.





All in all Stitch seems to be able to get development tasks faster completed since the development can concentrate on the frontend logic and rather than dealing with implementing backend services. Beside that I see the concentration on supporting data access control as a real benefit since this is a often under estimated or even half way done part of applications.