Limitations of On-Premises Development in SharePoint
Are there limitations in what you can do in an on-premises environment? Will Microsoft drop CSOM in the future? Find out in this article.
This post is based on the Codementor office hours hosted by 10-time Recipient of Microsoft’s MVP award for SharePoint, Andrew Connell.
Limitations of On-Premises Development
SharePoint is an enterprise-collaboration portal tool where you can do business intelligence, content management, etc. We purchased the product, installed it on our own corporate servers and hosted it ourselves. So you can almost think of it as an ASP or ERP big financial package. We now call that an on-premises installation. Office 365 is a hosted/cloud installation.
I talked a bit about this in the beginning, but we’re moving from on-prem to Office 365 to have a more Client-over-HTTP model and away from server-side code. What this question was asking was about using fully trusted code on the server, and what things we’re losing or whether we’re limited in some things we can do with this new model. What we do just in the browser compared to working things running on the server.
The answer is yes, we definitely are limited in what we can do. Part of this is because the way product was architected and also in the way of the extensibility model where SharePoint was set-up for so long. SharePoint allowed us to hook into their stuff pretty deeply and to add our own custom code to how things are going to run. However, now the more that we look at it, Microsoft is kind of getting in the mode of telling us to get out of SharePoint and out of developing stuff in that environment. Instead they want us to develop in our own environment and talk to them through web services, REST-type calls, etc. Another thing we have is a client-object model, or the CSOM, which is a proxy API to a backend API.
Are there things that we can’t do? Absolutely. A lot of the things we, or Microsoft, look at now are things we really shouldn’t be doing in the first place. We had a concept of a thing called a “timer job”, which you could write a schedule process that would run in the context of SharePoint at certain intervals. We can’t do that in our new model because we can’t put our code deep into SharePoint as we’re now running outside of it.
However, there are ways to accomplish similar things where we build a process that lives outside AWS/Heroku/Azure/etc, and then have a job that hits at certain intervals. That thing would then go into your hosted environment, authenticate using OAuth, and then use the RESTful APIs or the CSOM to get data out or interact with SharePoint in that way.
So, we are losing some things, but it’s debatable whether we should be doing things in the first place. In addition, we have ways around some of those limitations. To put the cards on the table, there are things we absolutely won’t be able to do.
Office 365 is the entire directory part of Office 365. So all authentication for users and apps are backed by Azure Active Directory (Azure AD). You don’t have group policies for computers, but the user piece is right there.
If you want to build an Angular app with Office 365, authentication was a challenge. However, in early 2015 we got the ability from Azure to have support for the OAuth implicit flow, which allows us to have a full client-side authentication piece to it. So you can have an app that is 100% client-side with HTML/CSS/JavaScript and 0% server-side code, and it can authenticate with an Azure access token, and then you can use that to talk to SharePoint.
If you’re going to build a SPA that will run on a SharePoint on-premises environment, it won’t have the true OAuth support. It still essentially comes down to a claims-based model for our Windows Authentication Model, like NTLM. For that, the way the authentication is still going to happen is you either have to have your application be service-from-SharePoint so the app is going to assume the same identity as the page you’re currently logged into. Or, if your app lives outside SharePoint, it’s going to run on your own webserver somewhere in your organization, and you’re going to want to have some sort of server-side intermediary that can do the authentication and hand off an access token to your SPA, and your SPA can then use it to call the different RESTful APIs. Alternatively you can have some sort of RESTful or web API in your custom app that your SPA is going to talk to an intermediary to get to your on-prem SharePoint environment.
So, this is one of the hitches we have. We see Microsoft as improving things, and their building their hosted repositories first and then moving back to their on-premises product. We’re seeing more innovation happening much quicker in the Cloud, whereas the on-prem environment will only be updated every 2~3 year traditional release cycle.
Will Microsoft Drop CSOM?
For those who aren’t familiar with this, Microsoft has a raw REST API for SharePoint and Office 365, and it’s all based on the Odata V4 spec.
They also have something called the CSOM (Client-Side Object Model) that’s essentially an abstraction of the server-side object, but instead of going straight to the bare metal, it actually goes through a REST-styled service to interact with the data. This way, when client-side developers are working on their browser or a remote machine, they have a choice to either use the REST API or CSOM.
This is a bit of a religious war people go back and forth with where, but I don’t expect Microsoft to give up on CSOM. I say this because CSOM came from SharePoint, and the original API we had was from SharePoint, so it kind of came out at the same time. The CSOM was much more full-featured than REST was, and in the last release in SharePoint 2013 REST has caught up a bit. There’s still a gap where CSOM’s above REST, and since then we’ve seen a lot of APIs come out from Office 365 services such as things in exchange, contacts, calendar, mail, the video portal, their social story Yammer, OneDrive, etc. When you see them release these different things, you’re seeing native SDKs being released, which I would still consider as CSOM because they’re native wrappers to the REST API. But then they also released native REST APIs.
I don’t think Microsoft favors one over the other, but I personally see that the emphasis on the REST APIs before the native APIs that wrap the REST API, because the native APIs are calling the REST APIs for you. Developers are free to choose whichever they prefer. I personally prefer REST over CSOM when there isn’t any missing functionality that is only in CSOM and not in REST, just because I’m not tying into a specific implementation. I can get objects back and then I can bind them to anything I want because it’s just objects coming back in a JSON format.
On a side note, CSOM generally refers to just SharePoint, and native SDKs refers to Office 365. To me, CSOM is a native SDK to SharePoint, and SharePoint is one component of Office 365.
Other Posts in this Series:
About Andrew Connell:
A 10-time recipient of Microsoft’s MVP award for SharePoint, Andrew is a classic Microsoft developer who has been using .NET and writing C# on ASP.NET as server-side code. These days he spends most of my time building full client-side applications using Angular, specifically Angular 1.x, or doing server-side stuff with a mix of ASP.Net or Node.js. He specifically specializes in Office 365 and hosting stuff in Azure.
