Is Client Side Scripting a Good Way to Access SharePoint Data?
People reach out to me all the time to ask my advice on how to accomplish certain things with SharePoint. Sometimes I can help, and sometimes their questions are way beyond me. One of the benefits of being reasonably well known in the SharePoint space is that people tend to come to me with questions that are up my alley.
When the questions aren’t something I can handle, I usually suggest that they use one of the public forums out there. My favorite is SharePoint StackExchange and in a distant second, the MSDN Forums for SharePoint.
Other times, either due to how they found me or based on the content of their questions, things stay in an email exchange.
The other day, my friend and colleague Christina Wheeler (@cwheeler76) passed along some questions from someone she knew [I’ve edited each part of the exchange a little for clarity and anonymity]:
I was wondering if you have a good resource within your network that might have published a blog about the different ways to access Sharepoint list data (client side scripting using something like SPServices or server side scripting using a deployable web part). Also, are there any other ways to accomplish this? I know the data view web part is another method, but it has its limitations.
A good example would be wanting to combine data from a SharePoint list and an external list and display both back to the browser window. I thought SPServices would be an excellent alternative to the data view web part, because it wouldn’t require taking the server down to deploy or redeploy. However, there are concerns coming from my team that client side is not as fast, secure etc. So I am just looking to see if there are any resources out there that have addressed this as it relates directly to Sharepoint.
Well, she certainly arrived in the right place with those questions. Since SPServices is mine, I can certainly answer any questions about it better than most people. The first thing I did was refer her to the post that Mark Rackley (@MrAckley) and I wrote together called When to Choose SPServices vs. the Client Side Object Model (CSOM). That post has gotten a lot of reads and Mark and I still think it covers the topic pretty well.
That prompted the next set of questions:
Thank you so very much for pointing me to all this valuable information! […] mentioned the SPServices […], and from then, I was hooked. Honestly, it was the number one thing I took away […] because of its potential to get around some Sharepoint limitations. To give you an example, we have a […] calendar that is managed under the IT site for the Sharepoint intranet. We like to display a summary of the daily or upcoming downtime to appear on the home page. The only way to display this data from another sub site (before) was with an RSS feed. The problem with the RSS feed is when we get into reoccurring events on the Sharepoint calendar. Now, I abandoned the RSS feed in favor of SPServices and it works beautifully.
My problem comes in with trying to get everyone on board that client scripting is okay to use for returning SharePoint list data. This argument is a perfect example. I am familiar with both client side scripting (javascript, xslt, jquery) and server side scripting with C#, but I don’t claim to be an expert. The argument that has been presented to me is that server side scripting is preferred because:
1.) It’s more secure
2.) It’s browser independent
3.) It’s better from a performance perspective
I tend to disagree that server side scripting is always the better answer for Sharepoint solutions. For one, we are not talking about writing an ERP payroll system where I plan to return thousands and thousands of records, so the amount of data I plan to return from a SharePoint list is minimal enough that I don’t think performance is a concern. For browser independence, that’s why I use jquery. And I don’t really know the answer about security. I think it comes down to what I want to do with the javascript. I am talking about using js to return a Sharepoint list. In this scenario, there is no increased threat of any kind by choosing to use client side javascript over a custom deployable web part written in C#. The case I am trying to argue is that using client side scripting to access a Sharepoint list is now possible, and in some cases, more desirable because it is easier to test, deploy, update and would not require any server downtime. I would just like to know your thoughts on this, or perhaps any resources…another blog or white paper you wrote that touches on best practices for when to use client side scripting vs server side development? Please bear with me because I have only been using Sharepoint for 6 months. Are there any other options to displaying Sharepoint list data other than using client side scripting like SPServices or CSOM, or to write an ASP.net page or deploy a custom web part that uses the Sharepoint Object model reference? I’m sure this is such an obvious answer that I have never really understood the answer to!
We plan to debate this issue tomorrow and I am just trying to make sure I understand the concerns/risks about coding for Sharepoint, specifically. There are lots of resources that touch on when to use client side scripting vs server side coding, but I think it’s not so black and white when it comes to working with Sharepoint.
And my reply was this:
You’re spot on in your thinking. This is a classic “it depends” scenario, of course. A good architect looks at all of the possible tools to solve the problem and decides where and when to use each one. Client side scripting is an excellent option for some things and just downright a bad idea for others.
The security argument is moot. The Web Services fully respect the permission model. If the user can’t access something through the UI, they can’t through the Web Services, either. QED. In a way, it’s even *more* secure than server side code since it’s impossible to elevate permissions, which many developers do as a common practice whether it’s needed or not.
Here are some more posts which may be helpful [each here on my blog]:
http://sympmarc.com/2011/05/27/elevating-permissions-with-sharepoints-web-services/
http://sympmarc.com/2011/06/06/using-script-to-hide-content-not-always-a-good-idea/
http://sympmarc.com/2011/05/18/sharepoint-myths-part-2/
Finally, the best argument that you can make is that Microsoft is going to a distributed, client side development model in SharePoint 2013, relying on (you guessed it) JavaScript and jQuery much of the time. If they are baking it into the product set by expanding their version of the API (versus mine with SPServices) how can someone argue that client side development is flat out a bad idea?
I don’t know if this little exchange will be useful for anyone else or not. However, it seems like every time I answer questions like there, it helps me to crystalize my thinking a little more. If it’s helpful to others, great. Otherwise, at least I had a little fun writing it up.
I think some people argue about the “security” of the code because they are doing more than “Reads”. You *do* have to worry about security in client-side code if you are processing data along the way. It’s trivial to modify the underlying code to something completely different. One example: Use Javascript to fire a workflow.
If I prevent that workflow from occurring and my whole process relies on that, then the house can cave in. I do say the approach has some caveats, but so does coding in any other language. They just have to be addressed in a logical fashion as with anything else.
Cheers,
Matthew
Matt:
I agree with you BUT… Since anyone can paste any arbitrary script into the console in their browser, the things you point out can always be a problem even if *none* of your development is client side. It’s a matter of understanding what you are doing and what the possible complications are. *Every* approach has some downside.
M.
I am the traditional SharePoint WSP developer but more and more I will happily use SPServices /CSOM/REST jQuery to solve certain business problems. In fact I prefer to use client side wherever possible now, faster to deliver, minimal iterations, happy punters. But I cant always use it, sometimes doing something client side is the wrong answer, I don’t like state management in cookies, I might prefer wep part properties, especially for repeatable configurable solutions, but those same solutions might still employ lots of client side stuff,
If you do not employ client side code in your user interface based solutions it will look rubbish, your users will hate you, they wont come back.
I cant wait for 2013 at my place even more will be client side. If they add groupby/count(*) into caml then I’d be made up. :-)
I’m thinking I should have said: PreSaveAction() as an example. ;-)
That can be a very insecure point if *all* of your validation/automation logic is there and your processes depend on this logic to be tamper-proof.
Cheers,
Matthew
As always, it depends. However I will say that I use CSOM frequently especially where I have something simple to display (say items from a list). I can very quickly just dump out my items into an unordered list, toss a quick jQuery script together with say the accordion plugin and in 10 minutes have a really nice UX for the users. I would not use it for something like a heavy duty solution where I was interacting with backend systems (for example BCS) but I tend to try to keep my UI to a minimum most times and task oriented so users only have to deal with one thing at a time. There are other places where you really want to do server side stuff like search, CAML, and anything where errors are likely to occur. I’d rather have a simple C# webpart with a robust exception handler than trying to sprinkle it all over my JavaScript. In any case, use it but use it wisely. With some common sense you can really leverage the system and get some great low-hanging fruit solutions out with little effort.