Aptillon Blog
24Apr/14

ITUnity

Posted by David Mann

An exciting new venture led by my friend Dan Holme, assisted by many folks, launched yesterday and promises to revolutionize the way we publish and consume technical content on the internet.  If you haven’t heard of it, you need to:
  1. Crawl out from under the rock you’ve been under
  2. Visit ITUnity.com and register so you can get access to all the goodness
Things are just getting started, but it’s going to be very exciting as they progress.  I’ve been privy to some of their long term plans and the future looks very bright, even if they only pull off half of what they have planned and knowing Dan, they’ll get far past half of their ideas. I’ve been a tiny little part of this effort as an author supplying content on SharePoint 2013 and JavaScript: I’ve got several more articles in this series to be published over the next few weeks/months. Good luck to the whole ITUnity crew.
Filed under: David Mann
To post a comment, view the original posting.
27Mar/14

SPC14 Session Wrap Up

Posted by David Mann

The write up from my SPC14 session (Deep Dive: REST and CSOM comparison) is posted here: http://blog.mannsoftware.com/?p=1521.  I’m a little late getting this posted here (the post itself has been up for 2 weeks), but I wanted to make sure to point folks to it as I mentioned I would during the session. Also, if you’d rather watch the session recording, it is available here: http://channel9.msdn.com/Events/SharePoint-Conference/2014/SPC423. Rather than just summarize the session in my post, it’s actually a full write up of everything I covered in the session, plus a little bit more that didn’t fit in the time allotted for the presentation at SPC.  So I cover all of the elements that are important to consider when you’re choosing an API in order to access SharePoint from off-server:
  1. Technology Concerns
  2. Performance
  3. Testability
  4. Intellectual Property Protection
  5. Developer Concerns
The overall takeaway from the session is that there is no clear winner for all situations.  Depending on your particular situation, one API (REST or CSOM) might be better for you, and I lay out what those factors and situations might be.  For example, I talk about the fact that if you are accessing certain aspects of SharePoint (namely workflow and managed metadata) you have to use CSOM as there is NO REST option for those things. Technology Concerns covers things such as the server or operating environment your code is running in, the role SharePoint was playing in the application, how you were deploying your code (CAM vs. FTC) and a few other factors that are largely unchangeable so they can often play an important role in choosing your API. Performance was an interesting discussion point.  As expected, REST was exceedingly chattier than CSOM, but it also outperformed CSOM in total elapsed time for my tests.  Each CSOM call was considerably larger than the corresponding REST call, but there were far fewer of them and total network traffic was smaller for CSOM.  Also, for the REST calls, over 80% of the traffic was in HTTP Headers, not the actual call data we were sending over the wire. Testability listed highly in my estimation because its something I think SharePoint developers are sorely behind the curve with and so its an important factor for us to consider.  In the session demo, I used Telerik’s JustMock product, but you could likely use any suitable mocking product.  In the end, each API was sufficiently testable for most situations. Intellectual Property Protection is an up-and-coming factor that more developers are starting to pay attention to with the introduction of the App Model and the SharePoint Store for Apps. Last comes Developer Concerns – not because they’re not important, but because they are, unfortunately, the least important factor in our decision.  Too often, though, because it’s the developers making the decision, it is these factors which drive things.  I think that’s wrong.  Again, these are important, but they’re not more important than the other factors, and often they are largely a matter of opinion or preference. One final point I make in the session and post is that you don’t need to make an either-or decision on your API choice.  They can co-exist nicely if that’s what is appropriate for your situation.  You can use REST for one part of the application and CSOM for another without any problem. Overall, there is no bad decision here, provided that you actually make a conscious decision based upon each particular situation. The source code I used for all of the demos in the session is available at the end of the post. Again, the full session write up is available here: http://blog.mannsoftware.com/?p=1521   Dave
Tagged as: , , ,
To post a comment, view the original posting.
5Dec/13

Speaking at SPC14

Posted by David Mann

I’m happy to announce that I’ll be speaking at the SharePoint Conference in March. My session is Deep Dive: REST and CSOM Comparison, which fits in nicely with the Pluralsight course I made that just went live (and it’s successive parts coming in Q1).

Here’s the synopsis for my session: SharePoint 2013 is fully embracing the world of client-side technologies, both on-premises and in the cloud. This means JavaScript; but which API should you use - REST or CSOM? This session will briefly introduce each, and then quickly move into a demo-heavy comparison of both approaches, citing the pros and cons of each API. By the end of the session, you'll have a solid understanding of when and why you would use one over the other (and some situations where you combine them into a hybrid approach) as well as plenty of examples of each in action.

 

Details available here: http://www.sharepointconference.com/content/sessions/SPC423

 

I’ll post more information here as the conference gets closer.  See you in Vegas!

Tagged as: ,
To post a comment, view the original posting.