Choosing between Google Apps Script and Google App Engine

Choosing between Google Apps Script and Google App Engine is not always a clear choice. These two tools are not mutually exclusive in their functionality and could, in many cases, be used conjointly. Fundamentally, they are very similar. Both are platforms on which to build applications, both run within Google’s infrastructure and both allow for integration into other Google services. Similarities abound.

Differences abound as well. First is the difference in languages used. Apps Script is JavaScript and only JavaScript. So, if you want to program in only this most eccentric and fascinating of languages, Apps Script is the way to go. App Engine is a virtual Tower of Babel, with its language options including Python, Java, Go (a Google developed language), and most recently PHP. If you or your development team are more comfortable with these more traditional, usually server-side, languages, App Engine is more likely to be a better fit. If the most important aspect of your project is the language used, then the choice is pretty clear.

The second most important aspect to consider is that of scalability. App Engine has many case studies documenting it successful use in large scale, very popular applications. If handling many concurrent users is critical to your application (or the ability to do so in the future), App Engine is the more suitable choice. While Apps Script is capable of acting as a traditional web application server, its quotas are a very real consideration for even modest projects. Apps Script quotas can be viewed here and for anyone considering using Apps Script for an application with many users, it is an important document to view.

The first two questions cut a very clear path to choosing between Apps Script and App Engine but after that the water gets murky. In terms of functionality and data storage, the two do not sit at cross-purposes.

Let’s talk about data first. Both Apps Script and App Engine have multiple options for persisting and retrieving data. Apps Script has four options:

Script and User Properties are simple key-value pairs suitable for settings and preferences.
ScriptDB is a JavaScript object database with attribute querying capabilities.
Spreadsheets – you can save, extract and use data found in your spreadsheets.
JDBC – this allows you to connect with external databases. For instance, you can use this to connect with Google Cloud SQL.

Apps Script is far more limited in the amount of data which it can internally store (think megabytes). However, with a JDBC connection to something like Google Cloud SQL, the amount of data you could view through Apps Script is just as expansive as it is in App Engine.

With App Engine, you can use its internal, schema-less datastore, file (blob) store, Google Cloud SQL or Memcached. All of these options allow for much larger amounts of data to be accessible to your application. Quotas for the datastore and file store start at one and five gigabytes, respectively and can grow as needed. The size limit for an individual Google Cloud SQL instance is 100 gigabytes.

Both Apps Script and App Engine have options for caching temporary application data. Both have timing mechanism for running code not triggered by a user (think CRON jobs). Both can be used to connect to external databases such as MySql. Both have quota considerations for reading and writing data.

If you are looking to tightly integrate with some existing, popular Google Apps, such as Gmail, Drive, or Calendar, Apps Script is likely your best option. Apps Script provides built-in services to help you couple with Calendar, Contacts, Drive, Forms, Gmail, Maps, and Spreadsheets with relative ease. If you can describe your desired application as a workflow or if your organization extensively uses Gmail, Calendar or Drive, Apps Script is a good place to start.

With App Engine, you can use IMAP/SMTP to interact with Gmail. You can use the Google-built Python and Java libraries to easily interact with dozens of API’s across Google’s Cloud Platform, from forward-facing apps such as Calendar, to more administrative functionality such as the Directory and Admin API’s. App Engine shines in its overall flexibility and power. Basically, anything you can do with Apps Script, you can achieve with App Engine, but at many times the scale. However, that flexibility and power comes at a metaphoric cost – applications built on App Engine are usually more technically challenging to implement. Literal costs of using App Engine can be viewed here. App Engine quotas can be viewed here.

Unless you are confident that your application belongs in App Engine, I would suggest you start looking first at Apps Script. There are many use cases in which Apps Script would provide a much easier path to fulfilling requirements. However, if you wish to integrate across the breadth of Google’s API offerings, are building something administrative, or need massive growth potential, App Engine is the better place to start looking.

Both Google Apps Script and Google App Engine have their advantages, differences and similarities – the full extent of which is too large to go over in one or even several blog posts, but I hope that this brief introduction gives you and your team a beginning point from which to plan your next project.