Serverless development just got easier — today’s release of Cloud Firestore with event triggers for Cloud Functions combine to offer significant developer velocity from idea to production to scale.

I’ve worked on dozens of mobile and web apps and have always been dismayed by the amount of boilerplate code needed to shuffle data between client and server and implement small amounts of logic on the server-side. Serverless APIs + serverless compute reduce the amount of code needed to write an app, increasing velocity throughout the development cycle. Less code means fewer bugs.

Cloud Firestore + Cloud Functions with direct-from-mobile access enabled by Firebase Auth and Firebase Rules combine to deliver something very new in this space. Unhosted Web apps are also enabled by Web SDKs.

It is not a coincidence that I’ve worked on all of these technologies since joining Google last year. My first coding project at Google was developing the initial version of the Firestore UI in the Firebase Console. I then stepped into an engineering management role, leading the engineering teams that work on server-side code where Firebase enables access to Google Cloud.

Cloud Firestore

  • Realtime sync across Web and mobile clients: This is not just about realtime apps. Building user interfaces is substantially easier: using reactive patterns and progressively filling in details allows apps to be ready for user interaction faster.
  • Scales with the size of the result set: Simple apps are simple. For complex apps, you still need to be thoughtful about modeling your data, and the reward is that anything that works for you and your co-workers will scale to everyone on the planet using your app. From my perspective, this is the most significant and exciting property of the Cloud Firestore.
  • iOS, Android and Web SDKs

Cloud Functions

  • Events for create, write, update, and delete (learn how)
  • Write and deploy JavaScript functions that do exactly and only what you need
  • You can also use TypeScript (JS SDKs include typings)

All the Firebase things

  • Free tier and when you exceed that, you only pay for what you use.
  • Zero to planet scale: no sharding your database, no calculating how many servers you need, focus on how your app works.
  • Secure data access with Firebase Rules: simple, yet powerful declarative syntax to specify what data can be accessed by client code. For example, some data may be read-only access for social sharing or public parts of an app, user data might be only written by that user, and some other data may be only written by server-code.
  • Firebase Auth: all the social logins, email/password, phone or you can write code for custom auth
  • Lots more Firebase things

All this combines to allow developers to focus on building an app, writing new code that offers unique value. It’s been a while since I’ve been actually excited about new technology that has immediate and practical use cases. I’m so excited to be able to use this tech in the open for my side projects, and can’t wait to see the serious new apps…..

SailsJS is a NodeJS MVC framework that we use for the OpenOpps Platform. Sails has some basic testing docs, but it doesn’t explain how to set up the framework nicely where the database is dropped in between tests. I find myself always re-figuring out these patterns when I write experimental apps.

With an in-memory database, this bootstrap.test.js will drop the database between tests:

var sails = require('sails');

before(function(done) {
  sails.lift({
    // test config
    environment: 'test',
    port: 9999,   // so we can run the app and tests at the same time
    hostName: 'localhost:9999',
    connections: {
      testDB: {
        adapter: 'sails-memory'
      }
    },
    models: {
      connection: 'testDB'
    },
  }, function(err, server) {
    if (err) return done(err);
    done(err, sails);
  });
});

after(function(done) {
  sails.lower(done);
});

beforeEach(function(done) {
  // Drops database between each test.  This works because we use
  // the memory database
  sails.once('hook:orm:reloaded', done);
  sails.emit('hook:orm:reload');
});

When I need to use postgres, Waterline doesn’t expose SQL truncate which would be much faster, instead this bootstrap.test.js will destroy all the models:

var async = require('async');
var sails = require('sails');

before(function(done) {
  sails.lift({
    // test config
    environment: 'test',
    port: 9999,   // so we can run the app and tests at the same time
    hostName: 'localhost:9999',
    models: {
      connection: 'postgresql'
    },
  }, function(err, server) {
    if (err) return done(err);
    done(err, sails);
  });
});

afterEach(function(done) {
  destroyFuncs = [];
  for (modelName in sails.models) {
    destroyFuncs.push(function(callback) {
      sails.models[modelName].destroy({})
      .exec(function(err) {
        callback(null, err)
      });
    })
  }
  async.parallel(destroyFuncs, function(err, results) {
    done(err);
  })
});

after(function(done) {
  sails.lower(done);
})

Xcode playgrounds are a delightful way to explore the Swift language — once you get them set up. I admit that I’ve grown to love environments where I can code with simple text files, however, I also love to develop iOS apps and so I find myself digging once again thru the byzantine Xcode GUI. It seems I always forget the magic incantations!

Here are the notes for my future self and other intrepid explorers:

Experimenting with Parse.com in Swift 2, Xcode 7.2, OSX 10.10.5 (Yosemite)

note: cocoapods 0.39.0 has issue with Ruby 2.3 (https://github.com/CocoaPods/CocoaPods/issues/4345) — likely fixed in the 1.0 beta, but I stuck with older ruby and released cocoapod for this exercise.

rvm use ruby-2.2.4
gem install cocoapods

Make a new Xcode project, and add a new Empty file to your project called Podfile (New > File… > Other > Empty), with the following contents:

platform :ios, '8.1'
xcodeproj 'ParsePlayground'
 
use_frameworks!
target :ParsePlayground, :exclusive => true do
  pod 'Parse'
end

back on the command-line:

pod install

This creates a new Xcode workspace, so we need to close the project in Xcode, then re-open Xcode with the file named something ending in .xcworkspace.

This new workspace should have both the original project and a new one called Pods. Now we can create the Playground, by selecting the menu: File > New > Playground… Then we save it in the root of our project directory, then add it to the project with the menu: File > Add Files To “ParsePlayground”

Now this code should compile:

import Parse
import XCPlayground
XCPlaygroundPage.currentPage.needsIndefiniteExecution = true

We want to set needsIndefiniteExecution so that the async commands will work.

I made a new Parse app to experiment, then in the parse docs, in the QuickStart Guide, they set up some sample code already customized with the app ID and client key, it should be something like:

Parse.setApplicationId("abunchofnumbersandletters",
clientKey: "morelettersandnumbers")

Then we can start coding! I made an item class in Parse with a string property “info.” Here some code that worked for me:

let testObject = PFObject(className: "TestObject")
 
testObject["foo"] = "bar"
testObject.saveInBackgroundWithBlock { (success: Bool, error: NSError?) -> Void in
print("Object has been saved: (success)")
}
 
var query = PFQuery(className: "item")
var items = try query.findObjects()
print("got some items")
for item in items {
var info = item["info"]
print(" item #(item.objectId!) info:(info)")
}
 
print("not the end... wait for the sync call to finish")

When I run the above code it works fine, but I do get some of the following errors. Not sure why…

Failed to obtain sandbox extension for path=/var/folders/hz/vnvkxt7x4236fp6nqt5zy2wr0000gn/T/com.apple.dt.Xcode.pg/containers/com.apple.dt.playground.stub.iOS_Simulator.experiment-3C8D4B75-8EA0-4BE8-8467-1B06C9B1F881/Library/Caches

I’ve posted the full ParsePlayground project on Github with some notes on how to set up the Parse app if you want to jump right in!