Using App Engine and Google Apps as a CMS

Ed Crewe

http://geug12.port.ac.uk/

Google APIs - in transition

Google's RESTful APIs are moving from Atom XML to simpler JSON

Google APIs - basics

• Data APIs are in transition (e.g. simpler Drive API) but older Atom based ones currently have more functionality.
• Feeds are query generated lists of entities, these may have lists of child feeds.
• Could be content, ACL, revisions, templates, provisioning etc. 
• Read, edit, upload and delete are Atom XML and get, post, put or delete HTTP requests. From suspending a GMail user to creating a new website. 
• gdata libraries wrap this, usually for at least Python and Java
• Javascript APIs for dynamic client orientated tools, eg. Maps
• Google SAML (Shibboleth compatible) or OpenID for authentication.  �OAuth for authorisation.  
• APIs console for overview and management of newer APIs usage�

NB: All content (emails to youtube videos) lives in NoSQL Big Table on GFS - sharded across global data centres

�

Google App Engine basics

A cloud hosted Python 2.7 WSGI or JVM 6 Java servlets environment (with a subset of the JRE libs)

Default web framework is adapted django 1.3 and maths tool is numpy - but with a little effort you can add someother Python (or Java) frameworks 

On demand automated multiple load balanced web server instances

Big table - PetaBytes size hash table (dictionary) store behind Google apps - with limited 'SQL'  = GQL, but MySQL is coming for traditional RDBMS apps.

Map reduce and blobstore (python only but java soon).

Memcache memory caching for any data or pages

�

Google App Engine console

Getting started with App Engine

Develop

• Download, copy new template to helloworld, run django startapp and edit main.py to point to it
• dev_appserver.py helloworld to see your app on http://localhost:8080 ... now code away
• Add a basic ORM model and populate it, or use the upload tools
• http://localhost:8080/_ah/admin is the development console to manage the datastore, interactive console, memcache, tasks, cronjobs, xmpp and mail.�

Deploy 

• Sign up and create a new application (up to 10 for free)
• Now you can run appcfg.py update helloworld to have it running at http://helloworld.appspot.com
• The Google app engine console gives you a production console plus all your usage stats etc.

Example - a personal site

This personal site* demonstrates integration of Google content across six different Google systems:�

• Django App Engine content - custom content types = projects - equates to using GAE as the CMS (like Vosao)
• Google sites content - used to pass through content not matched by any links in GAE django.�/edit goes to gsite, which has drag and drop embedding of Docs etc. out of the box
• Docs content - automated listing from tags
• Picasa / YouTube content - image explorer
• Blogger content - latest posts
• Feedback - GMail

​

* NB: In a recent blog post, I give a detailed technical look at upgrading this site to the current GAE python environment.�

Integration mechanisms

• Docs - simple API usage generates standard data query of entities - e.g. latest posts or doc list.
• Google sites - used as the main CMS - middleware catches urls not in App Engine and pulls the content from GSites�(sites already has embedding tools for many other Apps content)
• Just by the chrome - Blogger
• Established Javascript / AJAX client APIs - eg. Maps

�

• Add the gdata or google-api libraries to the application. 
• Blogger example demonstrates how the API simplifies direct Atom / RSS handling.
• Docs illustrate login access and tag querying.
• Google sites is the most complex acting as a replacement for django's flatpages - so providing most of the sites edit interface for standard CMS content types.

�

ABC demo of how it works as a CMS

GAE Django custom content:

�A. Go to projects and select a project

​

B. /edit the project - redirects to login and then edit

​

C. Modify the project and save

�

Google Sites content:

�A. Add a new page to sites or /edit an existing page

​

B. Edit text, or take a photo and insert it into the page

​

C. Go to the new page on the front end�

�

�

�

�

ABC demo screenshots ...

App engine django form

Sites page edit

What are the wider implictions ...

• Explosion of web and cloud content as the majority of content authoring is moving towards the web from the desktop. With Ajax and HTML5 providing equivalent rich client applications.�
• Generates a need for web content integration tools and frameworks. �
• An example of both source cloud content CMSes and integration framework are Google Apps and Google App Engine, respectively.�But what institutional scale CMS could Apps and GAE comfortably deliver?

​

​

​

... so in more detail ...

Explosion of cloud content

• There is a vast swamp of data that can be tamed via Google's APIs and knitted into web sites and applications.

​

• Currently it is likely that this is occuring in a piecemeal manner across HE, whether or not they are institutional Google customers - so Bristol has had YouTube channels, Blogger sites, Maps and other App content in use for our public web for some years, before we became one.

​

• If Google's collaboration tools are adopted by an institution then this stream ie likely to become a flood, as older  desktop apps users - ie staff ;-), generate much more web / cloud content to keep pace with student's use.

​

• The shared data store and APIs of GAE make it a good tool to prototype integration applications with built in scalability.

�

�

�

Integration framework

• There is a requirement for a more sophisticated and secure content integration approach than proxying in, or even worse iframe hacks, to merge cloud content in HE institutions - as CMS platforms multiply.�
• This requirement for a common integration strategy and platform exists irrespective of it being GAE or the cloud content just being in Google Apps. �
• For APIs, (other than perhaps for authorisation) web services, SOAP and bulkier XML are increasingly being replaced by light weight RESTful approaches and JSON formats. Since they perform better with the future javascript / HTML5 rich client, real-time web.�
• Following this trend, Google Apps GData Atom XML based APIs are now being superceded by simpler Google-API JSON based ones.

Apps and GAE use as CMS

• Google Apps differ substantially in their scale and features - Docs may surpass Sharepoint as intranet software, eg. its cross platform so works on phone and tablet, iGoogle approaches the features of leading portal software. Sites doesn't really equate to even smaller scale generic CMS, such as Drupal so is clearly unsuitable for larger institutional public web CMS. �
• Google offerings work as institutional intranet and portal solutions, maybe even form a large part of your VLE - but for public sites its best limiting their use to mopping up all those smaller local sites via a common integration framework - eg. teaching, research groups, personal - rather than replacing the main University public site.�

So next time a request comes in to display some seminars from Calendar on a website, along with the Docs presentations and Blogger blog - maybe its time to use an integration platform for that site...?�Any bespoke features? then maybe add them via App Engine.

Abstract 

Google Apps provides a range of large scale targeted CMS solutions, via Google Docs, Blogger, Sites, YouTube, Picasa, Circles, Calendar etc. that enable collaborative content creation.�App Engine, whilst not designed to act as a CMS itself - is ideal as a rapid application development / deployment environment (on to a global infrastucture) - to knit together these CMS components to provide custom website or web application solutions powered by Apps.��This talk runs through the basics of App Engine and how it can leverage Apps to create bespoke solutions - an example personal website. This is followed by a brief outline of Google’s RESTful data APIs and protocol standards for integration of its 50 or so Apps. Finally a quick look at the site, which I rather hastily threw together a year ago, to trial this approach!�The idea behind it was to test the water that perhaps bespoke CMS software - especially locally hosted - is becoming an outdated approach. Most CMS features are available from cloud hosted provider’s components, can such cloud mash ups provide as customised and integrated, a user experience - at a lower cost?