Overview
SharePoint Online is a Software as a Service (SaaS) offering from Microsoft which is part of Office 365 suite. In the SaaS model, we only consume the service provided by the service provider that we need to run our business. These services or applications run on the provider’s cloud infrastructure. We can consume these services on various devices including browsers and mobile devices. As we only consume the services, we do not have any control or permissions on the infrastructure.
This means a lot in SharePoint development. As we cannot deploy our solutions or assemblies to the server, the only possible way of development is remote development. SharePoint has provided numerous client-side APIs, REST APIs to connect to the SharePoint site remotely and perform the work.
End of Server Side Development?
There are two major scenarios to consider while developing the solutions for SharePoint irrespective of whether it is OnPremise or Online version.
Point 1 - Future compatibility of your solution
While developing the solutions for SharePoint OnPremise, we can use the full trusted farm solutions by making use of most server-side APIs. There is nothing absolutely wrong in it. But, what are the CONS of this approach?
- The server-side code is version dependent. That means the same code might not work for the next version of SharePoint or the APIs used might get deprecated.
- The server-side code needs to be tested every time after the cumulative updates to the server.
- How to migrate this code when the business decision demands SharePoint version upgrade or moving to cloud (SharePoint Online)?
Point 2 - Future directions from Microsoft
The future directions from Microsoft are to develop solutions using remote APIs. The major advantage of this is the code will work independently of the SharePoint platform being used. It may be any version of OnPremie or SharePoint online. The same code will work effectively irrespective of the SharePoint version it is running on. The future OnPremise version of SharePoint i.e. SharePoint 2019 has more focus on client-side development.
Commonly used SharePoint Client Side Development Scenarios
To have the solutions developed in future ready manner, here are few approaches being commonly used by SharePoint developers.
Approach 1 - SharePoint Framework (SPFx)
Although SPFx launched recently, it attracted the attention of all developers. SPFx offers easy development option for Modern sites in SharePoint. Microsoft has started to support SharePoint framework based development on SharePoint 2016 OnPremise environment by releasing Feature pack 2 and are promoting the development using SPFx on both OnPremise and Online environments. Microsoft has also announced that SharePoint Framework will be an integral part of the new OnPremise version of SharePoint i.e. SharePoint 2019. SPFx development is purely based on HTML and JavaScript, which offers faster performance.
Approach 2 - Client Side Object Model (CSOM)
CSOM offers remote APIs to connect to SharePoint environment and perform the operations. It is generally used to perform CRUD operations with SharePoint.
Approach 3 - Client-Side JSOM
JavaScript Object Model (JSOM) supports performing operations remotely against SharePoint using JavaScript. JSOM is used widely by web developers.
Approach 4 - Content Editor (CEWP) and Script Editor WebParts
Content Editor (CEWP) and Script Editor WebParts are more close the SharePoint developers. These WebParts are used very commonly to perform an operation on a single page. These can be effectively used to add HTML content on SharePoint page, as well as running scripts for any DOM (Document Object Model) manipulation on SharePoint page.
Although heavy usage of these webparts brings in the governance issues, these webparts are most popular in SharePoint developer community.
Approach 5 - PowerShell
The PowerShell scripting tool also offers APIs to connect to local as well as remote SharePoint and perform the complex tasks. Initially, PowerShell was of only SharePoint Administrator’s favorite tool. However, over the time it catched the attention of developers too.
Approach 6 - REST APIs
REST APIs offers to perform basic CRUD operations against SharePoint objects such as lists, libraries, and sites. REST APIs can be combined with any of the above-mentioned approaches to achieve the certain functionality in SharePoint. SharePoint out of the box supports a vast range of REST APIs for developer needs.
Approach 7 - SharePoint Designer (SPD)
SPD is being used since ages now. The SharePoint Designer tool allows to connect to SharePoint environment remotely and customize it. SharePoint Designer is the obvious choice for developers to customize SharePoint forms, develop workflows, copy or move the documents.
Microsoft did not release the SharePoint Designer version after 2013, but the same can be effectively used against SharePoint 2016 and Online version.
Approach 8 - JS Link
JS Link supports customizing rendering of list views and list forms. This is replacing the approach of directly adding content or script editor webparts on-page and helped bring some governance around how JavaScript can be injected to SharePoint site.
Approach 9 - Graph APIs
Microsoft Graph provides unified APIs to securely connect to Office 365 applications including SharePoint Online and fetch the information. Graph APIs are not yet available on the OnPremise version of SharePoint.
Approach 10 - Use of supporting infrastructure
SharePoint development can be effectively combined with additional supporting infrastructure like MS Flow, Power Apps, Power BI, MS Azure, etc.
Summary
In SharePoint development, there is a slight trend inclined towards the use of client side based development to be version independent and future ready. This brings up the question – “Is Server Side Code Dying in SharePoint?”