SharePoint Online Development Options

One of the advantages of developing custom SharePoint applications is that there is a ton of help on the internet.  However, from a developer’s perspective I’ve found the cutting edge SharePoint Online resources to be scattered and confusing at times.  How do I know which language is best to use for my business application?  What’s the best way to implement the solution and how should it be correctly deployed?

At a glance

After a large amount of research I’ve boiled this decision making process down to a few considerations.  These considerations stem from the technological capabilities of the three main types of custom SharePoint Online applications.

SharePoint Hosted apps

  • Client-side applications written in HTML, JavaScript, CSS, etc.
  • Use the SharePoint REST API or Client Side Object Model (CSOM) for data fetching and modification in context.
  • Both the application and the user need adequate access to perform an action.
  • Hosted in SharePoint Online and the “.app” file can be deployed by the following approaches:
    • Individual Web Deployment: add-in gets deployed to one site at a time.  This option cannot be invoked programmatically.
    • Side Loading: should be only used on lower environment sites and not in production.  This option can be invoked programmatically but you still need to manually “trust” the add-in.
    • App Stapling: add-in gets installed in the App Catalog site and deployed to multiple site collections from there.  This option can be invoked programmatically.

Provider Hosted apps

  • Server-side development capabilities.
  • Use the SharePoint REST API or Client Side Object Model (CSOM) for data fetching and modification anywhere (cross domain).
  • Able to run the application with “App Only” permissions which allows code to access things that the users can’t.
  • Hosted/deployed either on premises using you’re own servers or in the cloud using third party services (Azure, AWS, etc.).

SPO-AddIn-Hosting

SharePoint Framework (SPFx) apps

  • A page and web part model that provides full support for client-side SharePoint development.
  • Use the SharePoint REST API for data fetching and modification in context.
  • Both the application and the user need adequate access to perform an action.
  • Microsoft has made it clear that the Classic UI experience will eventually be retired and the Modern UI experience will be the only option.
    • SPFx applications are compatible with the Modern UI experience and should be considered instead of developing custom Classic UI components.
  • Deploy as a “.sspkg” file to the app catalog.  You can configure the solution to be available everywhere or just on select sites.

In the coming months I will be diving deeper into the details of each approach above.  In the meantime, sleep easily knowing that Microsoft Patterns and Practices exists and is a solid place to learn how to develop your applications correctly.  Also, check out the references below regarding some of the topics I’ve glanced over.

Get started with SharePoint Hosted Add-ins

Get started with Provider Hosted Add-ins

SharePoint Framework Overview

Note: Somewhere along the line the term SharePoint “App” was changed to SharePoint “Add-in”.  You’ll see both when digging through documentation, however, they mean the same thing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s