
MongoDB Stitch – Back End as a Service - habosa
https://www.mongodb.com/cloud/stitch
======
erdaniels
Hey! I'm one of the engineers on this project. We're really excited to release
the beta of this today. If you have any questions about this, how we built it,
etc. let me know.

~~~
ohstopitu
Hi! I'm a bit confused as to what Stitch is and what problems it solves (the
website does not appear to give any solid problems and how this solves it -
apart from the usual generic marketing fluff).

Is this similar to how Firebase functions? or similar to Parse (Backend as a
Service)?

~~~
erdaniels
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

