MongoDB Stitch – Back End as a Service

Alright I wrote more than I thought I would. Please feel free to ask me any specific questions about the following.

Good question. I'll explain how it differs from Firebase and Parse respectively. For Firebase, you're given a rooted document model where everything exists in this one large tree of data that you access via paths. The underlying storage is completely abstracted away from you with no way to get at your data. Not a bad model but a different way to think about how to structure everything. With Stitch, you get to define the namespaces as you would for MongoDB databases and collections and use documents as you would with the normal database. What we're providing for you on top of that is a security system that lets you define document/field-level rules dynamic to every invocation of CRUD actions. So in these rules you can say something like, the transactions field within a document is only visible to a user when the owner_id field in the document is equal to the current user's ID (%%user.id). Then you can say that the writes are only accessible to a user who's role is "teller".

Obviously the rules is similar to Firebase's model except it is scoped to documents whereas in Firebase being able to read/write a path implies you can read/write everything below it which is sometimes hard to conceptualize.

Regarding Parse, I'd say it's closer to Stitch than Firebase in that Parse exposes Models with some ACL permissions whereas Stitch exposes the Documents from MongoDB with fine-grained field-level rules. Parse does provide a way to run JS code functions before a document is updated in order to facilitate more secure interactions.

Overall though, Stitch is letting you get almost direct access to MongoDB but it's always from the perspective of data that an individual user can see, not what's in the database. So that's one problem it solves: avoiding creating API servers that have to handle the logic of deciding who can read and update what documents.

The next area where we differ is services. Firebase and Parse are pretty limited in terms of what they integrate with. In order to use other services you typically would want to use Google Cloud Functions for Firebase or Parse Cloud Code. We also allow you to do this via our HTTP service to call Google Cloud Functions, AWS Lambdas, or what have you. The differentiator is that we are providing services to 3rd parties and will keep adding more over time while always giving you the escape hatch via the HTTP service. That means you could implement your own Sendgrid service with HTTP and write rules such as { "%%args.host": "sendgrid.com", ... } where you limit access to the service via the host and other arguments you can reference from the invocation of that service's action.

What brings all of this together is pipelines where you can enable a client to execute something like (in mostly correct format):

      [ 
		{
			"service": "mongodb-atlas",
			"action": "find",
			"args": {
				"database": "myApp",
				"collection": "friends",
				"query": {
					"name": "Bob",
					"phoneNumber": { "$exists": true }
				}
			}
		},
		{
			"service": "twilio",
			"action": "send",
			"args": {
				"from": "%%values.our_number",
				"to": "%%vars.phoneNumber",
				"body": "Hey!"
			},
			"let": {
				"phoneNumber": "%%item.phoneNumber"
			}
		}
	]

This lets us find all documents in a friends collection where the person's name is Bob and they have a phone number. Then for each of those documents, we send a text on Twilio to that phone number. Rules will be executed for both stages individually against the arguments used. That means the rule will check that you see only friends you should see and that you can only send SMS messages to numbers you've been permitted to.

One thing I use Stitch for internally is our GitHub stitch server repo has all GitHub pull requests hit an Incoming Wehook on Stitch where we store the PR info, submit a patch build to Evergreen (our CI tool), and allow Evergreen to hit another webhook to fetch PR information so it can submit a build status to a PR.

So I think if you're a fan of using MongoDB, Stitch is great for letting you access data in a more direct, secure fashion without writing server code. Then the concept of services and pipelines allow you to augment all that and manipulate data all on the server side on behalf of the client. Of course pipelines won't solve everything and I'd encourage the use of Lambda like functions. Even having a server beside Stitch works where you have the server directly accessing the database and using Stitch for clients of some application. It's just a different way to think about building your applications; as are Firebase and Parse. Later on this year or next we will introduce Change Streams to facilitate realtime updates from the database which will allow you to build more reactive applications.

Sorry, that was a lot.

EDIT: Code formatting