Evolution of SharePoint! From Server side to Client side

Woohoo! So, we all are excited about the new framework of SharePoint which got released on 24^th Feb, 2017. Since August last year, the SharePoint framework (SPFx) was released in the developer preview edition and have undergone through many phases. The framework was drastically improved from until Drop-6 and with the RC0, the entire framework is bundled and packed properly and finally after closing all the bugs it got released for General Availability.

But most of us, will also like to know about the background which led to the development of this new framework. What all happened in the past, how it affected the market and to what extent.  So, let’s start our walk through the older development processes in SharePoint and their advantages and disadvantages. This entire era can be discussed under four main topics which are Farm Solutions, Sandbox Solution, Client Side Solutions and SharePoint Add-In.

Farm Solutions (Full Trust Solutions)

From the beginning of the SharePoint, one of the widely-used development technique and I think most loved way of customizing the SharePoint is Full Trust solutions. Using full trust solutions, you can almost do anything and everything related to SharePoint. In a full trust solution, all the computation part is handled by the server only, whether its Web Part, Event Receiver, Timer Job, Workflow or any other component. The SharePoint servers receives the request, executes it and finally sends the response. In this cycle, where all the business logic is executed by the server only, a bad code (bug) is potential enough to damage the complete Farm. Another downside of this approach is, it requires permission access to deploy the solution. Also, to develop the farm solutions, you need a developer environment running on Windows Server OS with SharePoint installed on that, and yes the only developer tool Visual Studio is also required on the same box.

Sandbox Solution

It is considered as an alternative approach of Farm Solution, which got introduced along with the SharePoint 2010 version. Sandbox solutions are almost like farm solutions (except limited functionalities like Site Definitions, Workflows, User Controls, Application Pages etc.) but the way they get deployed is different. To deploy a sandbox solution, you only require a Site Administrator privileges. The sandbox solutions are uploaded in the solution gallery and the solution is activated by the Site Administrator. Whenever a user requires a resource using these solutions, the assemblies are unpacked and with the help of User Code Host Service they get stored to file system (UCCache folder).

The main advantage of this approach over the farm solution is that a bad code can only damage the site collection and not a complete farm. But like farm solution, it also runs only at server side so the execution load is on server only.

Note: In SharePoint 2013 the sandbox solutions are deprecated and in Office365 only declarative sandbox solution are allowed now.

Client Side Solutions (C# Object Model, JSOM and REST API)

The client side object models are very effective when it comes to the development of small components.  These components live outside the SharePoint environment and interact with SharePoint only when some data or script is required. Also, to develop the client side solution, one don’t require fully configured SharePoint farm as it can be developed on any machine. In this, the complete execution happens on the client machine and with a bad code, only the client machine is at potential risk leaving behind the SharePoint Farm safe. The main problem with this approach is that we don’t have any deployment mechanism.

SharePoint Add-In (Formally SharePoint Apps)

With the release of SharePoint 2013, Microsoft came up with another approach i.e. SharePoint Apps later renamed to SharePoint Add-In model. This development model was widely promoted by the Microsoft because of Office365, as Microsoft don’t want server code to be executed on their machines/environment (which we had seen, when they completely stopped support for code based sandbox solution on Office365 and only declarative sandbox solution are allowed now on O365). The Add-In model was an alternative approach for farm solutions, but the difference is, Add-In model code lives outside the SharePoint unlike farm solution and interact with SharePoint for data or scripts only. With the Add-In model, developer had a choice to pick any of the backend technology they love to work (like PHP, Java etc. even APS.NET). but like other development model, it also comes with disadvantages like, one need to have authenticate mechanism (OAuth), it uses the old iFrame technique to display inside SharePoint, you need to have an environment where you’ll host this (including SharePoint itself for SharePoint hosted Add-In).

As, we live in a society where we look out for a better option always, so in the same trail Microsoft came up with a new SharePoint framework with better user friendly aspects.  In my next blog, I will talk about the SharePoint Framework in detail. So, keep yourself updated for my next blog.

Please visit the Part:2 of this blog where I have : “Discussed in detail about the new SharePoint Framework along with its advantages, disadvantages and how it will add a value to the current SharePoint scenario.”