webapp integration?

[Liam Staskawicz]

Hi - just stumbled across CloudKit, which looks *very* similar to a
layer that I'd like to provide for some models in my app. I'm hoping
to use MongoDB (http://www.mongodb.org), a schema-free JSON-based DB,
as storage for the rest of a Merb or Rails based app, and it would be
excellent to be able to expose my app models via a layer like
CloudKit. Is this kind of approach viable, or is CloudKit really
designed to work more standalone?

It would be nice to be able to hook into/override some of the CloudKit
API methods at the model level to provide any custom processing that
might be required, and it might be nice to be able to expose things on
a per property kind of basis as well. Again, I'm not sure if this is
at all appropriate for CloudKit as it stands so please let me know if
this way off the mark! Otherwise, I'd love to hear your thoughts on
the feasibility of or issues associated with this kind of approach.
Thanks.

PS - is there rdoc hosted somewhere, or is a build-your-own-from-
source kinda thing?

[Liam Staskawicz]

Oops - can't believe I asked for rdoc...*slaps forehead*

[Jon Crosby]

On Wed, Mar 25, 2009 at 10:34 AM, Liam Staskawicz <lst...@gmail.com> wrote:

Hi - just stumbled across CloudKit, which looks *very* similar to a
layer that I'd like to provide for some models in my app.  I'm hoping
to use MongoDB (http://www.mongodb.org), a schema-free JSON-based DB,
as storage for the rest of a Merb or Rails based app, and it would be
excellent to be able to expose my app models via a layer like
CloudKit.  Is this kind of approach viable, or is CloudKit really
designed to work more standalone?

CloudKit can work standalone or integrated into another framework using CloudKit::Resource. See this Gist for an example of integrated use:

http://gist.github.com/76145

It would be nice to be able to hook into/override some of the CloudKit
API methods at the model level to provide any custom processing that
might be required, and it might be nice to be able to expose things on
a per property kind of basis as well.

Depending on what you are looking for, you might be able to achieve some of this using a small piece of rack middleware in front of CloudKit. Can you provide an example of custom processing or the exposing of properties that you are thinking about? I may be able to recommend an approach for either CloudKit or for using a different framework if CloudKit is not appropriate.

-Jon

[Liam Staskawicz]

On Mar 25, 2009, at 9:16 PM, Jon Crosby wrote:

On Wed, Mar 25, 2009 at 10:34 AM, Liam Staskawicz <lst...@gmail.com> wrote:

CloudKit can work standalone or integrated into another framework using CloudKit::Resource. See this Gist for an example of integrated use:

http://gist.github.com/76145

I'm starting to think that I might have the wrong idea, but here's roughly what I had in mind - please excuse my half-baked planning.  

It would be great to be able to mix in a cloudkit-style module to normal (DataMapper or ActiveRecord) models in order to provide a discoverable/navigable rest interface to them.  This could provide default implementations for GET PUT POST DELETE endpoints (which could be overridden by the model), provide the machinery to respond to OPTIONS & HEAD, and to include the model in responses to GET /cloudkit-meta queries.  An additional query (GET /%collection%/_definition ?) might return a class definition, as the class currently exists (members, methods, etc.)  Depending on the backing store, versioning may or may not be appropriate.  This module might also ideally help manage the last-modified status of model instances.  

As far as the custom properties, all I really had in mind was the notion that there might be elements of your model that you'd prefer not to be exposed - maybe this is aligned with private methods/members, but maybe it's a separate concern.  Some way to specify this on a per method/member basis would be necessary, I think.  

Again, I'm not sure if this misses the point of the existing cloudkit implementation a bit too much, but I think something like this could go 

a long way towards converting existing apps to being open web json appliances as well.  Thanks again for your thoughts. 

Liam

[Jon Crosby]

On Fri, Mar 27, 2009 at 8:58 AM, Liam Staskawicz <lst...@gmail.com> wrote:

On Mar 25, 2009, at 9:16 PM, Jon Crosby wrote:

On Wed, Mar 25, 2009 at 10:34 AM, Liam Staskawicz <lst...@gmail.com> wrote:

CloudKit can work standalone or integrated into another framework using CloudKit::Resource. See this Gist for an example of integrated use:

http://gist.github.com/76145

I'm starting to think that I might have the wrong idea, but here's roughly what I had in mind - please excuse my half-baked planning.  

It would be great to be able to mix in a cloudkit-style module to normal (DataMapper or ActiveRecord) models in order to provide a discoverable/navigable rest interface to them.  This could provide default implementations for GET PUT POST DELETE endpoints (which could be overridden by the model), provide the machinery to respond to OPTIONS & HEAD, and to include the model in responses to GET /cloudkit-meta queries.  An additional query (GET /%collection%/_definition ?) might return a class definition, as the class currently exists (members, methods, etc.)  Depending on the backing store, versioning may or may not be appropriate.  This module might also ideally help manage the last-modified status of model instances.  

Thanks to the work that is going into Rails 3, defining APIs for ORMs as plugins, CloudKit could implement those APIs and become a provider as you describe. I have forked Yehuda's Rails repo to keep an eye on this and contribute where I can be helpful.

 

As far as the custom properties, all I really had in mind was the notion that there might be elements of your model that you'd prefer not to be exposed - maybe this is aligned with private methods/members, but maybe it's a separate concern.  Some way to specify this on a per method/member basis would be necessary, I think.

This is an excellent point. A fine-grained permissions model is planned for the 1.0 release and some experiments are underway. Once I have something in a workable state for others to hack on, I'll push a new topic branch to GitHub. Right now, it seems like it may be a combination of JSONSchema and JSONQuery on top of the existing store. In the context of the ORM idea mentioned above, the details may be abstracted so that most developers won't need to know the internals.

 

Again, I'm not sure if this misses the point of the existing cloudkit implementation a bit too much, but I think something like this could go 

a long way towards converting existing apps to being open web json appliances as well.  Thanks again for your thoughts. 

Likewise, thanks for sharing your ideas on the mailing list. Allowing CloudKit to grow into something that fits in with existing apps is a worthy goal.

-Jon

 

Liam 

[Liam Staskawicz]

On Mar 28, 2009, at 11:25 AM, Jon Crosby wrote:
>
> Thanks to the work that is going into Rails 3, defining APIs for
> ORMs as plugins, CloudKit could implement those APIs and become a
> provider as you describe. I have forked Yehuda's Rails repo to keep
> an eye on this and contribute where I can be helpful.

This would be quite interesting. Will definitely keep an eye on how
this progresses.

In the meantime, I'm trying to think through the implications of using
CloudKit as a parallel layer to a Merb app. Ideally, they would be
able to access the same DB layer which got me thinking about
CloudKit's compatibility with various backends. Is there a spec/API
for CloudKit 'adapters'?

Liam

[Jon Crosby]

I am working toward making the API match moneta plus a querying layer. Once the jsonquery branch gets merged into master, we'll know what might be added to moneta vs. what should be its own querying layer.

For now though, a working adapter would be anything that matches CloudKit::MemoryTable and CloudKit::MemoryQuery (both found in lib/cloudkit/store/memory_table.rb).

-Jon

 

Liam