Semergence

Google App Engine was just announced. Scalable, integrated applications hosted on Google’s cloud. I’m particularly interested in the Datastore. Take that, Amazon SimpleDB, Datastore supports ordering result sets!

After a tour through the examples, it’s safe to say that App Engine is not a direct competitor to Amazon’s general purpose cloud offerings, such as EC2 and S3. App Engine is targeted directly at request/response web applications. Amazon’s offerings are much more generic, allowing you to run whatever you want on EC2.

App Engine’s data store is closer to a traditional database than Amazon’s SimpleDB. With App Engine, you have a query language that looks and smells familiar. SimpleDB is a distributed hash. Both technologies are useful, but if you’re comfortable with SQL, you’ll find App Engine’s Datastore more friendly.

Also interesting is that App Engine has direct support for Google Accounts. Don’t want to write Yet Another Account System? With just a few lines of code, you have deep support for Google Accounts. Note that nothing prevents you from writing your own account management features. Too bad App Engine didn’t have direct support for OpenID.

What’s kind of cool is that you can lock down your application to users of a particular Google Apps domain. This might be useful if you wish to write an application for your company or organization. Nice touch.

Now, if I can only get my beta account approved! My account is approved! I can’t wait to test the scalability of the Datastore.

When you register an application with App Engine, you have the option of binding your own top level domain (eg example.com). You do this through Google Apps. If you don’t have your domain yet, it’s trivial to purchase the domain name through Google Apps (via GoDaddy). This is very handy because all the work is done for you behind the scenes. I registered and new domain name, bound it to Google Apps, and then to my App Engine application within 10 minutes.

Time to downloading the SDK to full domain registration and application upload to running application: 1 hour. That was amazing. Of course, it doesn’t do anything yet. But that’s pretty cool.

Proper web architecture dictates that a you should “Assign distinct URIs to distinct resources.” And Cool URIs for the Semantic Web states that:

There should be no confusion between identifiers for Web documents and identifiers for other resources. URIs are meant to identify only one of them, so one URI can’t stand for both a Web document and a real-world object.

So we know that a URI should refer to one and only one resource. (Of course, you may have many URIs all referring to the same resource.) So why do so many web sites have URIs like http://www.example.org/myaccount? That same URI is used to refer to any account in the system, depending on who is logged in. And that makes Baby Semantic Web cry.

Why is the baby sobbing? A generic URI like http://www.example.com/myaccount isn’t useful on the semantic web, because it’s very difficult to make meaningful statements about that URI. Let’s go and try.

http://www.example.com/myaccount is the account page of "Seth Ladd".

and

http://www.example.com/myaccount is the account page of "Bob Smith".

Hmm… so http://www.example.com/myaccount is the account page for both Seth and Bob? That doesn’t make much sense!

A better URI for an account page would be http://www.example.com/accounts/23232, which is easily unique for every user.

The moral of this story is that every one of your URIs should be unique. So let’s bring this all the way back to Rails and resources.

When building your resources, ask yourself, “If I GET this URI, will I see the same thing no matter who is logged in?” If the answer is “No” then you need to nest your resources so that the URI is unique and the same representation is returned no matter who you are logged in as.

For example, a typical URI would be http://www.example.com/books, which could easily be a collection of books for the user. The contents of that URI are relative to the person logged in, so we have a problem. To fully qualify the URI, we need to nest books inside of the user collection. We end up with http://www.example.com/users/1/books, which is unique and follows web architecture best practices. Now we can say unambiguous statements about the URI, thus populating the semantic web with more useful and meaningful triples.