Feb. 27, 2011, 7:49 a.m.
I was dissatisfied with the lack of shopping list applications that were cross platform, could share the list with many users, and learned the isle order of the store based on your trips. I also really just wanted to play around with Google App Engine hosted Java.
Key features of GDocShop:
- Stores and shares your shopping list in plain text on Google Docs. You can revoke access to the application in your account settings at any time and retain the list and its shared users.
- Learns category (isle) order from the order that items are placed in the cart.
- Categories (isles) can also be manually rearranged.
- Uses Google Maps to locate your handset and show stores you have visited before.
- Also uses Google Maps and location of your handset to drop markers for your favorite retailers.
- Learns items from the community so that once created, they are shared.
- Items will not auto-complete until you type them fully the first time, even if they already exist. This is designed to keep people from getting profanity into the system and sharing it with others.
- By the same token, sharing of retailers is done by the administrator only. Once a retailer has had its categories stabilized and is not named something profane, it will be shared with the community by its official name.
The guts of the app are essentially Google's take on JavaEE. They strip down Java somewhat to limit what damage you can do once inside their cloud. The instances of your application are fired up dynamically on demand. They also shut down after a period of inactivity causing an expensive re-deployment on the first request. Because your time is billed as CPU time in the milliseconds, you will see a lot of 5000+ ms warnings when the first request is made and you are pulled from disk(?) and instantiated.
They also have made a proprietary JDO backend which is actually stored on their highly available GFS storage. I believe it is Big Tables but I can only find references that to say it is "schemaless" and is essentially a huge, replicated key-value store. In practice this limits your queries to GQL and makes a lot of normalization hard or impractical. I'm a big fan of normalization but ended up needing to de-normalize many relations in order to increase efficiency of queries against a key-value store. They do redeem themselves somewhat with the ability to create custom indexes which let you query against more than just one value at a time. I could go on about this forever, email me if you're interested.
I learned my way around those caveats fairly quickly. The one thing that really pounded me initially was that I chose to store the shopping lists in Google Docs. The pros: You get versioning and sharing ACLs built right in. I never have the problem of storing information that could identify people and their shopping lists. They can revoke this access at any time as well and keep their shared shopping list and its network of people.
The cons: There is versioning latency between the query list you get by asking for a document by name, and the actual latest version. This only happens on rare occasions, but once it happens you are locked out of modifying the document...unless you catch the exception and re-query the document entry directly. I will admit it took me a few hours of troubleshooting my own code before I realized that I was not the problem.
If you install the 1.4.2 version of the App Engine API in Eclipse, go to their site and get the zip version. Otherwise any attempt to pull a resource over HTTPS from your app while running the development VM is doomed to failure.
With those obstacles in mind, overall it was a positive experience. If you are considering Google App Engine, you should read their documentation on JDO and GQL. You will not have the flexibility of *SQL backends, but you may not need it.
tags( #jquery #code ) Tweet