Parse.com Cloud Code is like JavaScript Pseudo-Triggers on MongoDB

Using Parse.com allows me tremendous simplicity when writing mobile apps: it lets me focus on just writing the mobile code and the database, but lets me use an N-tier deployment model and a remote NoSQL database. However, there are times when I really want to run a tiny piece of code inside the database — the same way I would use stored procedures or triggers in a relational database — or inside the REST server as I would normally do with server-side business logic.

For example, one of my mobile apps (PatchTrader) enables Scouts to more easily trade patches at large Scouting events. In this app, whenever a Scout “checks-in” at a new location, any of their older check-ins should be marked as expired in the remote database. I could have the mobile app save the new check-in to the remote database, then retrieve any old check-ins for that user and reach back to the server to expire each one, but this is a terrible use of mobile bandwidth and battery life. It also very fragile. PatchTrader is used at campsites with bad cell service, so it is very possible that the app will be unable to successfully complete all that work, thus leaving old check-ins still showing as “active” in the database. In an ideal world, I’d want a database trigger to fire on the first update and mark the other rows as expired, or I’d have my “check-in” RESTful service handle this … but I didn’t build a REST server and I’m not on a relational database.

Enter Parse’s “cloud code” — it fills that need nicely, and once again saves me from having to write a full server application when I just need one little bit of server-side code.

Parse’s “cloud code” allows you to run custom JavaScript inside the Parse server rather than in your client app, but still without requiring you to build a real REST server. You can use that cloud code to do things such as providing custom server-side logic, doing more efficient database processing or specialized counts, sending push notifications, and most importantly in my “PatchTrader” case, it provides hooks for code that can be run before or after a database object is saved or deleted in the MongoDB database. Pseudo-triggers on MongoDB!

Admittedly these are not real triggers but instead merely server-side JavaScript that is called by Parse’s underlying Node.js engine, but they feel like database triggers so calling them triggers better fits my mental model. And while one could argue that database triggers are evil because they hide business logic inside the database rather than keeping it visible in the server-side code, my DBA hat would reply that there are valid cases for triggers. Then my developer hat would chime in and explain that in this case, PatchTrader is a free app with a very limited audience that I’m doing in my spare time and it is tracking nothing more serious than map check-ins while trading patches, and my time would be better spent enhancing the app rather than building a REST server for it, so the trade-off is acceptable.

To show a simple cloud code example, this is the “after save” code that gets fired off by the server whenever a new check-in is saved by a PatchTrader user:

Parse.Cloud.afterSave("Checkin", function(request) {

    // Skip the update if we are being updated by server-side code
    // (i.e.: if this afterSave call is being cascaded from a previous afterSave call)
    if (request.master) {
        console.log("Cascading afterSave ignored on ID: " + request.object.id);
        return;
    }

    // mark any other "active" checkins for this user as "inactive"
    query = new Parse.Query("Checkin")
        .equalTo("user", request.user)
        .notEqualTo("objectId", request.object.id)
        .notEqualTo("isActiveCheckin", false);
    query.find( {
        success: function(results) {
            console.log("Updating " + results.length + " items...");
            for (var i = 0; i < results.length; i++) {
                var checkin = results[i];
                console.log("   Updating ID: " + checkin.id);
                checkin.set("isActiveCheckin", false);
            }
            Parse.Object.saveAll(results, {useMasterKey: true});
        },
        error: function(error) {
            console.error("Error setting items to 'inactive'." +
                " Error: " + error.code + " : " + error.message);
        }
    });
});

As you can see, it’s very simple and it gets the job done without adding any extra burden to the mobile app or mobile bandwidth, and it prevents bad data from gathering in the database.

It’s very handy, when used appropriately. If you’re a Parse.com developer and you haven’t played with Cloud Code, I urge you to take a look!