I have been using SPServices (along with jQuery and Knockoutjs) for about a year now working on Rich Internet Applications and Single Page App (SPA) for my organization using SharePoint as the repository. In essence my overall approach is to use the ASMX services (CRUD through SPServices) and underlying lists as an ad hoc relational database to support rapid prototyping and then move the application to WCF services and SQL server once the requirements stabilize. So far it has worked well, with my only complaint being that for each list I have to build what I call a Client Side Model defining the list and the behaviors and found that I was repeating the same code over an over. I stumbled across John Papa's SPA tutorial on Pluralsight and his proposed architecture seemed very modular and extensible which is a requirement in that we have to support distributed and isolated development teams for building applications that can be maintained when the original development team is no longer under contract (for whatever reason). In Papa's SPA, he used Amplify to expose an interface to what he calls dataservices allowing the view models to get the information without knowing much about the information. The issue is that Amplify only supports ajax/json natively and it seems to be extendible (through amplify.request.types and amplify.request.resources) to ajax/SOAP/XML. All the building blocks seem to be there within SPServices (e.g., getListItems and XMLtoJSON) and Amplify to do the integration, but curious if there are other more mature ways for accomplishing what Amplify provides (client storage/caching, data connection, simple api, etc.). At the end of the day what I would like is a generic dataservice file based on SPServices that allows me to pass in or reference the URL, list's GUID, mappings, etc., so that I only have to write the SPServices code with all the error handling once and easily add a new list merely with a mapping, URL and GUID.
Any thoughts, suggestions, concerns, fears, risks or ideas appreciated!
Couple things to note:
(1) I don't have full access to our SharePoint 2010 instance in that I can't easily build and deploy anything more than straight JS without having to go through a long lengthy process hence the rapid prototyping approach.
(2) The lists are resident across the site collections all under a common root domain which SPServices has worked great for pulling data from throughout our domain which it didn't seem like the CSOM was able to do in my brief experimentation.
(3) In the future I need an easy, painless transition for the app from the ajax/ASMX data provider to the ajax/WCF data provider
(4) Our most restrictive browser is IE7 which is still widely used with our next most popular being IE8; however, we do have many using modern browsers as well so need a solution that works across a large number of browser. Hopefully this can maximize the applications lifespan.