Some tools are simply the right tool for the job. I imagine this must have been the thinking behind the wave of JSON-like NoSQL databases at their peak, and even so today. If we figure we’ll be passing information as JSON to an endpoint, to then have it structured into a schema, only to be promptly broken down again for our request seconds later, if you will, it’s fair to question the cost-benefit of schemas in some cases. A lot of those cases cover the apps we build for ourselves: ones that let us do stupid things like spamming selfies or filling the internet with vast mindless thoughts.

MongoDB Atlas is a hell of product in its own right, being a cloud NoSQL database with the ability to execute queries similar to SQL JOINs, countless aggregations, and more possibilities to work into a pipeline than I’ve even had time to explore (we’ll get there). If you’ve ever been tasked to build endpoints for yourself, chances are you already appreciate side-stepping the manual one-to-one key association that comes with passing JSON to Lambda Functions or what-have-you.

Take our situation at Hackers And Slackers, for instance. We’re running a Ghost blog, which is a young piece of software built by a non-profit organization: this software is constantly being updated and improved, which means if we want to modify the logic of our Node app at all, our choices are:

1. Modify the Ghost source and refuse future updates
2. Merge our custom backend with Ghost changes in the event of an update
3. Build a third-party API using a platform such as AWS

MongoDB Stitch gives us a new fourth option: extend our app without all the repetitive boilerplate. I say extend because it empowers us to build on top of things which were previously black-boxed to us, such developing a theme atop a blogging system.

Carrying on the Legacy

MongoDB Stitch extends the philosophy of avoiding repetition. In a similar way to how NoSQL removed a pain point for many developers, Stitch wants you to keep doing what you do best, which is probably writing NodeJS apps. Forever.

If I worked for Mongo, I’d sell the product like this:

MongoDB Stitch empowers you to build powerful features without ever switching gears to the menial aspects of development.

What I’m really saying is that MongoDB Stitch is Google Firebase. Both products target the frontend and mobile developer markets, and both are very young and early in fully achieving this goal. I’m watching the MongoDB product video for the first time, and it feels like what I’ve assumed from using the product aligns with their sell (good job on their part, I suppose):

As warm and uppity as that video is, Mongo has been rather bashful about their Cloud. I'm guessing that has something to do with an IPO.

On the other hand, Google Firebase has been tooting its own horn loudly for a young product, with a level of growth which feels almost reckless at times (I won't get into it):

Anyway, we're not here to compare. We're here to judge.

Getting Started with a New Database

Feel free to follow along by setting up a free tier cluster.

Proper Mongo accounts are managed at https://cloud.mongodb.com once created. This landing dash has plenty of useful info and stats regarding the cluster itself. We'll also need to be sure that a database exists before we crate any apps, otherwise we'll just be interacting with nothing.

I highly suggest using the MongoDB Compass desktop app to connect to your your cluster. It's easy to download, and even saves you the time of entering credentials by connecting with a copy+pasted URI:

Within Compass, simply create a database and collection:

Let's Get Stitched

With all that out of the way, head back to your account on the Mongo Cloud. Now our interest is entirely in the Stitch Apps link on the left side nav:

Create and name a new Stitch application, and we'll land on the "getting started" page.

Once we create our app, Stitch immediately throws us in to a quick 101 of how to interact with our database. We're going to use the exact example that Stitch gives us; it's important to have the "A-ha" moment where everything comes together.

Before getting to any code, the only two things we need to do are:

1. Enable Anonymous Authentication: This is fancy language for creating a user type where anybody who accesses our app can make queries
2. Pointing to our Mongo Collection: We need somewhere to store the data we'll be messing with.

Connecting Your App

We're going to copy and paste this code on to a page of our app. Once this is live, visit the page and keep an eye on the console:

<script src="https://s3.amazonaws.com/stitch-sdks/js/bundles/4.0.8/stitch.js"></script>

<script>
  const clientPromise = stitch.StitchClientFactory.create('hackerjira-bzmfe');
  clientPromise.then(client => {
    const db = client.service('mongodb', 'mongodb-atlas').db('HackersBlog');
    client.login().then(() =>
      db.collection('jira').updateOne({owner_id: client.authedId()}, {$set:{number:42}}, {upsert:true})
    ).then(()=>
      db.collection('jira').find({owner_id: client.authedId()}).limit(100).execute()
    ).then(docs => {
      console.log("Found docs", docs)
      console.log("[MongoDB Stitch] Connected to Stitch")
    }).catch(err => {
      console.error(err)
    });
  });
</script>

Checking this on the live sites looks like this:

It worked, but what exactly? The first thing the snippet tells the database to do is to upsert a row where "number" is equal to 42:

db.collection('jira').updateOne({
  owner_id: client.authedId()
}, {
  $set: {
    number: 42
  }
}, {upsert: true})

For sanity, let's check the database to see what's up:

Sure enough, a new entry has been added to our database in the collection we specified. That's fun and all, but what about our actual data? Isn't that what we came here for? Consider the next line:

db.collection('jira').find({
  owner_id: client.authedId()
}).limit(100).execute()

Ahhh, we’re querying based on entries only created from the current user! Because the sample code we pasted creates a record, we can then query the database for records created by that user. Let’s not ignore how cool that is having not actually done any work: we already have logic in place to allow anonymous users to create records and recognize them based on their session.

.find() is our bread and butter for retrieving records, much like SQL SELECT. So in theory, to show all issues from this collection we'd just need to run the following, right?

db.collection('jira').find({}).execute()

Slow down there, buddy- but yes, pretty much. We just need to make read permissions public on the MongoDB Stitch side first. Back in the Stitch UI, select "Rules" from the sidebar. Here, we can modify the rules for who can read/write which records from which DB:

We can create rules as advanced as we'd like, but the rules we need right now are simple enough to handle purely via the UI.

Get All The Records

Go ahead and add a bunch of records to your database collection. Experiment with importing data via JSON or CSV, or just add some records one-by-one.

When that's done, go back to your app and see what .find({}) comes back with:

There they are: every record from a database collection, grabbed with a single line of code on our frontend. Feel free to take a moment to reflect on this: we didn’t need to create an API, write logic, or log in to any shitty IAM policy management UIs. We didn’t even need to write a query; the ‘query’ in this case is just a JSON object.

Stitching it All Together

When I first reached this point, I experienced a rush of emotions: can creating new features truly be this simple? If so, what have we been doing with our lives until this moment- repeating the same boilerplate and relearning the same concepts as millions before us? Is this knowledge all worthless now? Does the existence of Stitch reduce our lives’ greatest accomplishments to something that can now be reproduced in minutes?

While there are a great number of things that come easily with Stitch, there are a fair share of headaches that come along with them. Many intricacies of complex flows and user management lack documentation or examples altogether. Creating a cloud based on ease-of-use even more frustrating: there’s not much that sucks more than knowing something should be simple, but lacking the few lines of code to do it.

That’s where we’ll be filling in the blanks. Next time, we’ll take a look into Stitch’s Serverless functions.