Last night, Google announced App Engine, a hosted web application platform. We’ve now tested the service directly by writing and deploying a test application called appengine.crunchbase.com—a HotorNot popularity contest for startups. Our experience with building and launching an app is below.
Google promises developers two things with App Engine: to reduce the time from writing code to deploying it on a web server, and to leverage Google’s massive infrastructure. We decided to write a simple app on the platform, deploy it, and get some traffic to really see how easy App Engine is.
Looking at the developer documentation, App Engine boasts a powerful API. The platform comes with a Python scripting runtime, static file serving capabilities, easy and tight integration with Google user accounts and email services (obviously a big play), simple access to a powerful persistence engine with queries and transaction support (aka a really good database), near real-time site monitoring and statistics, and the promise of consistent high performance and essentially linear scalability.
Despite its potential power and underlying sophistication, App Engine was surprisingly easy to get started with. Now, being Ruby on Rails guys, the fact that the only currently supported language is Python was a bit humbling. Still, the SDK provided by Google proved dead simple. Our first application was contained within a single Python script, making the path the code was taking to produce responses very clear. We incrementally added features: first accepting input from the users through forms, then storing and retrieving that data using the provided persistence API, and finally breaking out the user-facing web page code into a proper Django template.
The web app we came up with is super-simple, shamelessly self-promoting, and easily game-able. It’s a one-page voting site using company logos slurped in from CrunchBase, our main project. The app has only two requests: one for rendering the page, the other for recording a vote (one GET, one POST request). The first real issue was getting our initial data, some URLs and names, into the database. While we later found that Google provides a slick bulk-update tool, we got going with a simple action that manually parsed our comma-separated values into the database. Another thing we wanted from the service was it to be served from our own domain. By default, Google hosts all App Engine projects on your-project.appspot.com (think blogspot), but they do offer domain services through Google Apps, which was pretty painless to setup if you just want App Engine functionality.
The SDK provides a server that emulates the App Engine platform, making it possible to easily develop applications locally that will later deploy to Google’s cloud. Once we had a presentable first app coded up and tested locally, we deployed the app to Google’s server easily from the command line. This was particularly compelling; we’ve spent hours or even days deploying web apps to comparatively trivial servers.
Overall, the process from sign-up to deployment took about 4 hours, with the vast majority of that figuring out what we wanted to do and remembering how to do things like sort arrays in Python (we also spent an embarrassing 15 minutes on some poorly formatted hidden HTML fields). The rapid prototyping of the app and the ease of deployment is clearly the real power of App Engine right now. The scalability of App Engine is exciting but elusive; most apps won’t need it for a while. It’ll also be interesting to see how truly scalable it is, considering the linear scaling efforts on Amazon EC2. The redundancy and ease of deployment should be the immediate attraction for developers.
Try our app out: appengine.crunchbase.com.
Mark McGranaghan took the lead on coding for the site and contributed heavily to this article.
Update: Looks like our app was a little bit too popular:
Update #2: Back up now. Great success!