This is a guest post by Mike Johnston and Fred Cheng, co-founders, Simperium. This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O. It's also cross-posted to the Google Code blog which will have similar posts for all sorts of Google developer products.
We originally created Simplenote both as a learning exercise and to address what we thought were shortcomings in the original Notes app for the iPhone (Marker Felt font, no ability to search, etc.) The very first version of Simplenote didn't even have syncing!
We've certainly come a long way since then. The Simplenote backend now synchronizes data across devices, the web, and third-party apps while also handling in-app purchases, sharing, and basic metrics. About a year ago, we were accepted to the Y Combinator startup accelerator with something like 20,000 users. Today, with hundreds of thousands of users, we're currently serving 15 million requests daily and providing access to over 500 gigabytes (!) worth of text notes.
Google App Engine is at the heart of it. We made a decision early on to use App Engine so we wouldn't have to worry about scaling, or deploying more servers, or systems administration of any kind. Being able to instantly deploy new versions of code has allowed us to iterate quickly based on feedback we get from our users, and easily test new features in our web app, like the newly added Markdown support.
We consider our syncing capabilities to be core features of Simplenote. They are, in and of themselves, largely responsible for attracting and retaining many of our users. Our goal is to give other developers access to great syncing, too. The next version of our backend is named after our company, Simperium. As a general-purpose, realtime syncing platform intended for third-party use, Simperium's architecture is much more expansive than the Simplenote backend. Yet App Engine still plays a key role. It powers the Simplenote API that is used by dozens of great third-party apps like Notational Velocity. And it continues to power auxiliary systems, like processing payments with Stripe, while bridging effectively with externally hosted systems, like our solution for storing notes as files in the wonderful Dropbox.
We suspected we might outgrow App Engine, but we haven't. Instead, our use of it has evolved along with our needs. Code we wrote for App Engine a year ago continues to hum along today, providing important functionality even as new systems spring up around it.
In fact, we still come up with entirely new ways to use App Engine as well. Just last week we launched an internal system that uses APIs from Twitter, Amazon Web Services, Assistly, and HipChat to pump important business data into our private chat rooms. This was a breeze to write and deploy using App Engine. Such is the mark of a versatile and trustworthy tool: it's the first thing you reach for in your tool belt.
Come see Simperium in the Developer Sandbox at Google I/O on May 10-11.
Mike Johnston was a senior designer and programmer at Irrational Games where he worked on numerous games and prototypes for PC and Xbox 360. Before that he built security software at Entrust.
Fred Cheng hails from Cantaloupe Systems, a venture-backed startup, where he built their infrastructure for wirelessly tracking tens of thousands of vending machines.
Posted by Scott Knaster, Editor
Here on the App Engine team, we’re always looking for new ways to make it easier for developers to build applications and services. Today, I’m happy to introduce ProtoRPC, a new tool for creating simple Python services, which requires minimal set up and configuration to create new services.
What can you use ProtoRPC web-services for? Most web applications have the need to send and receive data between different components and/or applications. Typically, developers come up with ad-hoc ways of doing this as quickly as possible. As the application grows larger and the need to share information across components grows, it becomes more difficult to manage. URL end-points are defined and appear inconsistent from one another and a lot of boiler plate code is added checking parameters. This quickly becomes a maintenance nightmare and is a problem that ProtoRPC is built to solve.
ProtoRPC makes it easy to write consistent, reliable web interfaces that can be used, for example, to do the following:
Using ProtoRPC, you can define structured web-services right in the application’s Python code without having to first learn and write a new interface definition language such as Thrift and Protocol Buffers, however still retain the same powerful features such as interface introspection and automatic client generation.
The way to go about defining a web service should be familiar to you if you already have experience working with App Engine db.Models and the webapp framework. The data sent between client and web service are defined in a similar way as Datastore models. The services classes that handle requests are defined similarly to webapps RequestHandler classes. Let’s take a look at a simple example from the ProtoRPC getting started guide. This simple web service says hello to its client:
class HelloRequest(messages.Message): my_name = messages.StringField(1, required=True)class HelloResponse(messages.Message): hello = messages.StringField(1, required=True)class HelloService(remote.Service): @remote.method(HelloRequest, HelloResponse) def hello(self, request): return HelloResponse(hello='Hello there, %s!' % request.my_name)
If this web services was used as the URL end-point for an AJAX based form, Javascript to communicate with the service might look like this:
$.ajax({url: ‘/helloservice.hello’, type: 'POST', contentType: 'application/json', data: ‘{ my_name: Bob }’, dataType: 'json', success: function(response) { // The response is { hello: “Hello there, Bob!” } alert(response.hello); } });
As you can see from the example, ProtoRPC can speak JSON right out of the box. In addition, it is compatible with the protocol buffer binary format and can therefore communicate with clients and servers written using traditionally compiled .proto files.
Right now, ProtoRPC is available as an separate project that can be downloaded here. It’s still considered experimental and may change in substantial ways before being integrated in to the SDK. But even though it’s in preview, it already has a number of useful features, such as a remote service discovery mechanism and a forms interface for easy testing. At the moment, ProtoRPC is only available in Python. As always, we plan to offer it for Java developers in the near future.
Check out the getting started guide for a more complete overview to try out writing a few services of your own!
Use promo code NEXT1720 to save $300 off general admission
Follow