This post presents just my thoughts about provisioning. If you’re looking for some useful technical information, skip to part 2.
During five years I’ve spent working with SharePoint I’ve seen a lot. I’ve worked with different companies and different developers and all of them have their own best practices…
Wait, best practices? Haha! Those were rarely good enough practices.
So, all of them had ‘their practices’. Oh man, in regard of data structure provisioning, I’ve seen some really exotic stuff.
To give an example
You can use SharePoint UI. That’s perfectly fine, if you’re a user.
You can use XML schemas and features. That’s what developers used to do in SharePoint 2010.
But to create data structures using UI, extract schemas using SharePoint Manager, pack them back into features and deploy again is… let’s say bad. All of this in year 2015 when Microsoft was already clear that we should provision using API, implemented by company that claims to be industry leader.
And so we’ve arrived at the actual topic of this post - provisioning through API.
First time I had to write a serious provisioning logic was back in 2013. New version of SharePoint was still fresh, we were all clueless about app model. In a perfect world we would start with research on the new technology, or some small app project. But of course we started with a big-ass automatic site provisioning remote hosted application. That’s far from reasonable and quickly proved to be impossible to implement.
I still have shivers when I hear HTTP POST…
Provisioning was a core aspect of the project and as employee with most CSOM experience I was responsible for the implementation. My creation was a ugly provisioning logic, hard to understand pattern, very verbose API and terrible performance. Well, it was proof of concept.
We’ve used this PoC in more than one project. Of course we did some changes - we added some more concepts and proved how bad it is. Refactoring? Naaaa.
At some point we noticed that SharePoint returns
429 Too Many Requests because of number of CSOM calls we were issuing.
Someone cared? No. After all we can increase limits. And when we had the same problem in O365, where we cannot increase limits? User can just try again.
I felt bad for poorly designing the code, for low quality implementation, for not standing up to my superiors and for my company shipping it to our customers.
Why do I even bring it up?
Because I’ve found something that has possibly worse performance and even more verbose and convoluted API.
Let’s see what creators of SPMeta2 have to say about their child:
SPMeta2 is a hassle-free fluent API for code-based SharePoint artefact provisioning. It offers a consistent provisioning API via SSOM/CSOM for SharePoin 2010, 2013 and O365. […] Sounds exciting? Have a look around, let us know how it goes.
Oh I’ll have a look.