SharePoint Development Options: What are the Differences?

Editor’s note: This is a guest post by Andrew Connell, Founder of Voitanos. For more information about Andrew, visit his website and follow him on Twitter: @andrewconnell.

---

Microsoft SharePoint, both the on-premises version SharePoint Server and the hosted online version SharePoint Online, offers developers multiple options for creating custom solutions that either extend and customize the experience or to leverage the data and services in the product within external applications.

Applications deployed external to SharePoint can be implemented using any technology and development stack. These applications can leverage the multiple endpoints provided by Microsoft to read and write data to SharePoint as well as leverage services offered by the product, such as search and collaboration.

For applications designed to be deployed to and hosted within SharePoint, developers must work within specific guidelines for the types of applications and development models available to them. SharePoint on-premises and SharePoint Online offer developers multiple options to customize and extend the product. The different development models were introduced with each new version over the last 10+ years to address different challenges and technologies available at the time. All of these development models are available today, albeit some are only available within specific environments.

These different development models apply to the scenarios when a customization will reside within SharePoint. This includes cases such as web parts or extending the user experience. In addition to the different development models, developers building custom solutions to extend SharePoint must decide, if applicable, where their application-specific data will be stored.

In this post, I will cover the different development models and customizations available to developers and the different options for where data can be stored for developers to communicate with SharePoint on-premises or Office 365 – SharePoint Online.

Stay tuned for my next post where I will cover the different APIs available for developers to interact with SharePoint and Office 365, regardless if the custom applications are deployed and hosted within SharePoint or if they are hosted external to SharePoint.

SharePoint Development & Customization Models

When building a custom solution to customize or extend SharePoint, Microsoft provides developers with four main options to choose from:

• SharePoint Solutions
• SharePoint Add-ins
• JavaScript Injection
• SharePoint Framework

Each option has different advantages and disadvantages, and some are limited in where they are available. These options all apply to applications that are deployed and hosted within SharePoint. Applications hosted external to SharePoint have no limitations as they will communicate with SharePoint using well-known and standards-based REST APIs or SDKs.

SharePoint Solutions

The first customization options introduced in SharePoint Server 2007, and extended in SharePoint Server 2010, are solutions. A SharePoint solution is a deployable package that may contain compiled code, pages, style sheets, client side code and images. Solutions usually include SharePoint features, a collection of files comprising a declarative set of actions to perform or configure the target SharePoint environment.

Certain changes, such as creating a list within a specific SharePoint site can be narrowly scoped. Other changes can go wider, for example deploying a web part to all sites within a site collection or globally scheduling a timer job across the entire SharePoint farm. Only certain customizations are available within specific scopes, while some can are applicable to multiple scopes.

A solution package is deployed to the SharePoint environment. Once deployed, SharePoint puts the files within the solution package in the necessary locations on the SharePoint server. Administrators or site owners then apply the changes in the solution by activating features included in the package.

Solutions come in two flavors:

Farm Solutions

SharePoint Server 2007 introduced farm solutions that are deployed to the server and allow developers full access to SharePoint’s server-side managed API. Developers can use these packages to deploy custom server-side web parts, timer jobs, event receivers, features, feature receivers… basically anything SharePoint supports.

Pro: The wide range of options is the big advantage for farm solutions because they have full access to the server-side SharePoint API.

Con: The disadvantage to farm solutions is they are only useful in SharePoint Server on-premises deployments. Microsoft does not allow farm solutions in SharePoint Online. The reason is obvious: With full access to the SharePoint API, one farm solution can impact the SharePoint Online multi-tenant environment, and thus impact other customers.

Sandbox Solutions

To address the downsides to farm solutions, Microsoft introduced sandbox solutions in SharePoint Server 2010. Unlike farm solutions, sandbox solutions are supported in both on-premises and SharePoint Online deployments from SharePoint 2010 to the current versions (SharePoint Server 2016 and SharePoint Online). The biggest difference with between farm and sandbox solutions is that sandbox solutions can only be scoped to a site collection. This means all changes can only impact a single site collection and not expand to a larger scope.

While initially Microsoft supported managed code in sandbox solutions that was scoped to run only within the context of a site collection, they have since restricted them further and no longer allow custom code in sandbox solutions to be deployed to site collections in SharePoint Online. They can still be used to deploy declarative and client-side customizations to SharePoint Online.

Developers can use sandbox solutions to deploy custom pages with custom JavaScript and CSS as well as declarative customizations such as list templates and instances using sandbox solutions.

SharePoint Add-ins

After solutions came SharePoint Add-ins, initially called apps. Add-ins are supported in both SharePoint on-premises and SharePoint Online starting in SharePoint 2013 to current versions.

When installing a SharePoint Add-in within a SharePoint site, SharePoint typically creates a new subsite with a unique URL (top-level domain) to isolate the code from the rest of the customer’s SharePoint environment. The Add-in is also given a first class identity, which can be used to assign unique permissions to the add-in irrespective of the users consuming the add-in.

These are available in two flavors, the SharePoint Hosted Add-in and the Provider Hosted Add-in.

SharePoint Hosted Add-in

SharePoint Hosted Add-ins run exclusively within a client-side context. Any custom business logic has to be implemented using JavaScript as the files deployed to SharePoint while stored in SharePoint, are not run on the server. They are rendered in the client and run there.

Provider Hosted Add-ins

Provider Hosted Add-ins are more open ended. The developer, or provider, of the Add-in, deploys a web application external to SharePoint and can thus use any web development techniques at their disposal.

Regardless of the type of add-in you create, any time your add-in needs to communicate with SharePoint will do it using one of the client-side APIs Microsoft has included in SharePoint; either the CSOM or robust REST API.

When an add-in is manifested within a SharePoint site as a client part, it is done using an IFRAME. This is due to the fact the add-in execution context is externalized from SharePoint, running either in the provider hosted web application or within the special SharePoint site that hosts the SharePoint Hosted Add-in.

When you, as the developer, package up a SharePoint Add-in, you take the resulting package file and upload it to the SharePoint tenant’s app catalog. Once this is done, the SharePoint Add-in can then be installed within any SharePoint site in that tenant and associated with that app catalog. Therefore, it is scoped to the tenant as far as where it can be used, but its’ functionality is scoped to the site to where it was installed.

Developers can use SharePoint Add-ins to create web parts, but not web parts the way we used to with solutions. Instead these are created as web pages that are surfaced within SharePoint sites using IFRAMES.

Developers can also create event custom workflows and declarative workflows based on Workflow Manager and deploy those with add-ins. While the logic and implementation is hosted in an web application external from SharePoint, add-ins can also register remote event receivers.

JavaScript Injection

Another SharePoint customization option is JavaScript injection, which is used to customize existing SharePoint sites. Developers can use the content editor web part, or more recently the script editor web part, to get the customizations onto the page.

Because of the very nature of JavaScript injection, these customizations will always execute within a client-side context. This means they leverage the user’s context and are rendered in the native page DOM.

By extension, because JavaScript injection involves client-side based development, these customizations have can leverage SharePoint’s client-side APIs to leverage SharePoint data in the customizations.

JavaScript injection does not involve specific developer tools. All developers need is a text editor and a way to upload the files to SharePoint. This is typically done using the browser, so developers are free to use any tool that they normally use to create their customizations when leveraging JavaScript injection.

These customizations are added to each SharePoint page on a page-by-page basis, meaning these customizations are scoped to a specific page.

Because JavaScript injection customizations are done on a manual basis, typically there is no packaging model, there’s no deployment model, and there’s no provisioning model provided by Microsoft.

SharePoint Framework

The most recent addition to the SharePoint developer’s toolbox is the SharePoint Framework. The purpose of the SharePoint Framework to make client-side customizations an official development model for SharePoint developers. Developers are able to create client-side customizations that are packaged and deployed to SharePoint sites just like SharePoint solutions and SharePoint add-ins were in previous versions.

These customizations will also have easy access to SharePoint data using APIs included with the SharePoint Framework. But this does not mean they will be limited to accessing just SharePoint data… they are client-side solutions that can use any technology to access other data sources, including the Microsoft Graph, Office Graph, or other accessible APIs.

Components built using the SharePoint Framework will run in the current context, unlike their predecessor add-ins that ran within the context of an IFRAME. This means not only will they load faster, but they will run within the context of the current user and using the current connection in the browser.

SharePoint Framework customizations are also rendered in the current page DOM – again, not in an IFRAME – which eliminates the requirement, but not the ability, to host more involved customizations in another web site.

Because the customizations are rendered in the current page DOM and not in an IFRAME, they will not have the same baggage associated with them as IFRAMES have. One of the biggest benefits to this is that the customizations will be responsive and accessible by nature.

When creating customizations with the SharePoint Framework, you want to make sure you are not excluding your users from using them in legacy SharePoint sites.

Another aspect of the SharePoint Framework is that the customizations you create will work not only in the new current modern pages, but they will also work in the traditional classic web part pages as well as publishing pages.

First Party & Third Party

In the past, things like SharePoint add-ins were a third-party only customization tool; Microsoft did not create add-ins for SharePoint… they just baked their changes directly into the product. The downside to this is that Microsoft, the provider of the host and the development model, is not using the tools they give us to extend the product.

The term “first party” refers to people like Microsoft – not only do they create the host extensibility model, but they also use that extensibility model to extend SharePoint. When they want to create a new component or customization in SharePoint, from this point forward they will use the SharePoint Framework.

What does this mean for SharePoint developers? Well, they are clearly taking a strong dependency on their own extensibility model so they will be able to leverage the same benefits it provides that we use in our customizations but on the flip side, they will also be held back by its limitations. This is good because as they improve the SharePoint Framework for their use, we can benefit from it as well.

What About External Applications?

Now that I’ve covered the four major options for developing customizations with SharePoint, this list is by no means exhaustive. These are the four options available to developers who want to deploy customizations to SharePoint. However keep in mind that SharePoint offers multiple APIs enabling developers to build applications hosted elsewhere such as on corporate servers or in one of the public clouds (Microsoft Azure, Amazon Web Services, Google Cloud Platform, etc.). These applications can be built using any technology, any language, using any stack and leverage the standards-based REST APIs SharePoint and Office 365 offer to integrate with SharePoint.

Custom SharePoint Solutions and Data Storage Options

In the last section I talked about the different tools in the SharePoint developer’s toolbox that can be used to create and deploy customizations to SharePoint. But what about custom data that your application needs or creates… where should you put that?

This is a common question developers face, so let me offer some guidance and provide a few options.

The easiest option is to keep the data within SharePoint and Office 365. This includes using SharePoint lists, libraries and OneDrive for Business. The benefit to this option is that there are well-known APIs developers can use to create these customizations. However, the downside to these options, specifically SharePoint lists and libraries, is that they are not intended for highly transactional applications (i.e., lots of rapid reads/writes) nor are they well designed for holding lots of data. Taking it to the extreme, a SharePoint list is not a good target for logging data.

The other option which requires a bit more work is to externalize the data from SharePoint. If you are working with Office 365, the public clouds, specifically Microsoft Azure, make a lot of sense in these scenarios. From relational to document databases, message queues, file storage and caches, developers can combine these options with their custom applications to create compelling SharePoint customizations and extensions!

Conclusion

In this article, I detailed the different options for creating SharePoint customizations. Developers who want to build customizations that will be deployed and hosted within SharePoint have multiple options to choose from including SharePoint solutions, SharePoint Add-ins, JavaScript Injection, and the SharePoint Framework.

But what about applications that are created and deployed external to SharePoint? What options do developers have when creating custom applications that need to talk to SharePoint or Office 365? What APIs and SDKs does Microsoft provide to these developers and can they be used in the same SharePoint hosted customizations? That’s the subject of my next article so stay tuned!

SharePoint Framework Webinar

Want even more guidance on SharePoint customization and SharePoint Framework? Join me for a webinar at 2pm ET on Thursday, September 7 with AvePoint’s D’arce Hess to discover best practices and tips for choosing the right API and/or SDK for your custom applications.