CloudKit: Hacking the Open Stack with Ruby and Rack – Jon Crosby
Thanks for the votes, his talk is here because of GoGaRuCo attendee votes.
He works for Engineyard, and they are hiring.
This talk will be “lightning-talk” style, so that means it will be very fast (and also means this live-blog will be pretty sparse)
Cloud Kit is an Open Web JSON Appliance
Can quickly and easily spin up an API for
RESTful Collections of JSON Documents
Similiar to CouchDB and Perservere
Implemented in Ruby (unlike CouchDB)…
Now Frameworks are basically another MVC framework
So why wouldn’t you want to do a new MVC architecture?
gem install cloudkit
“If your RESTFUL API cannot be accessed with curl, you lose”
Resource Composition in the Browser
If you have two widgets in the browser doing different tasks, you can point them at different resources.
Mobile apps can benefit from this style of restful architecture as well.
ESI caching layers – like Old Skool SSI, except that they are cache includes.
Cloudkit is built on Rack. Rack is awesome.
HTTP Intermediaries – such as Rack Middleware.
Rack Is The Web
The spec for rack middleware is runnable and readable
Build an App! create config.ru
expose :todos, :profiles
Cloudkit bootstraps so you can query it
You can ask it for it’s Options and it’ll tell you what you can do with it
Hypermedia as the Engine of Application State
Cloudkit is read-optimized
No SQL, no ORM, uses Tokyo Cabinet Tables instead
Schema Free, HTTP and JSON are the schema
Can do a PUT to place a new record at a specific location
Can do POST to update. By supplying the version etag the server can solve the “lost update” problem
Auto-versioning, any time you update a resource, the previous version is archived. That’s reflected in the url – :collection/:version. This is solves the last-update problem when 2 users update the same document at once. If you try to update a resource without providing the version, it will return 400 bad request. If two clients try to update the same version, the seconds get 412 precondition mismatch response.
Cloudkit also solves the batch GET problem, where you can access the resource with id “_resolved” to get multiple documents at once (and their complete contents).
Finally, with DELETE, you can’t delete things that out of date, similar to update. The 410 Gone response will get returned in this case.
“Rewrite in Scala… or solve the problem”
The ability to ask questions
Querying – solved with JSONQuery. (/todos[0:10][?priority=3])
jQuery plugin for Cloudkit
All code is up at Jon’s Github
Because it’s OpenWeb, you can easily add OAuth, OpenID, etc. A desktop application might use OAuth, whereas a web application could use OpenID for authentication.
Q: Isn’t querying slow?
A: Yeah, it can be slow. There’s indexing work that needs to be done on write to optimize read. Tokyo Cabinet might come to the rescue here about searching data with regular expressions.
Q: Are there real world apps using cloudkit?
A: Not that I know of. One company might be trying it.
Q: What kind of apps are good for cloudkit?
A: I’m personally using it for Actiontastic, a synchronizing web service that provides a REST interface.
Q: Are there plans to abstract away the key/value storage system so other systems can be used?
A: Yehuda has a library called Moneta that’s an abstraction for Key/value stores that I’d like to move to.
Q: How does CouchDB map/reduce company to cloudkit’s JSONQuery?
A: It first started as a Sinatra app that sat between couchDB, but I found JSONQuery to be better suited.