I’m working on a new application that uses AJAX heavily on the front end, and catalyst/Class::DBI heavily on the backend. All in all, it seems to be working out relatively well. However, I realized the other day that it feels like my javascript frontend feels like it’s lacking sufficient abstraction. I find I’m writing a lot of code to make ajax calls, read in the results, and stick them in a javascript object
Instead, what I’d really like is something like Class::DBI for AJAX/javascript. I could give it a REST interface, and it would build me appropriate OO classes, for each object represented in the REST interface. I could then call CRUD methods on the javascript object, and have it perform the appropriate actions via the REST interface. I imagine this working very similar to the way Class::DBI currenly works:
- create - creates a new javascript object with the data I pass it, and tells the REST interface to create a matching object. Pulls an automatically assigned key back from REST and sets it in the javascript object, if necessary
- retrieve - retrieves an object by its primary key id
- accessors - these are lightweight and provide set/get functionality all in one function, and mark field dirty so they can get updated during an update call
- update - syncs the javascript object to the database, syncing whatever dirty fields there are. Autosync would also be an option that you could set, whereby syncs would happen as soon as a field was set. One thing to think about here is how to handle two different clients with copies of the same object in javascript at the same time. Should this OO mapper automatically handle syncing a change back out to the clients? Ie, if browser A has a copy of object b, and browser B also has a copy of object b, does an update from browser A to object b get pushed out to browser B? This could be pretty cool, but could be more complicated to build and use.
- delete - deletes the object in REST
Note that search isn’t in the above list. Not that I don’t think search isn’t important, but it seems less clear how to provide that in a generic way.
One thing that REST lacks is introspection. I gather that this is one of the features that SOAP provides, however (the whole discoverability thing). So you couldn’t do the equivalent of Class::DBI::Loader without extra syntactic sugar on the server end. However, I’m not sure that’s what you’d want anyway. Because AJAX calls are relatively expensive, it seems like you’d want to know ahead of time (ie, compiled into the javascript) what objects the interface supported, and what fields those objects had.
Also of interest here is the issue of access control. In Class::DBI, for the most part, there isn’t really a concept of permissions. The database is expected to handle it, or there’s simply the expectation that anyone who has access to the database via Class::DBI is trusted. However, when you push access out to the client side, all of a sudden access controls become a huge issue. However, I’m not sure it’s as big a deal as it initially sounds (though I could be wrong, and feel free to point out where). If you think of REST as being your database, then again, the database is in charge of access control. So build a relatively generic/uniform REST interface, and simply throw errors (which the javascript should be able to parse) if the client tries to do something it’s not allowed to do.
It seems like this could all be accomplised through a clever catalyst helper. The helper would be responsible for taking in a Class::DBI object, and spitting out a REST controller (and appropriate views, if needed), as well as a controller which could be called to get a javascript file which contained the appropriate javascript class for the object.
It all seems so simple. What am I missing?