Three ways to think about design options for apps for SharePoint

This article looks at the architectural choices for apps for SharePoint in three different ways. First, you learn about the most important categories of design choices; second; you view app architecture in terms of application tiers; and, third, you see a set of factors you need to consider when making your design choices.

But the first decision to make is whether your SharePoint extension should be an app for SharePoint or a classic SharePoint farm solution or sandboxed solution. Some parts of the SharePoint object model, mainly connected with customizing SharePoint administration and security, are not accessible from clients. Only custom code running on the SharePoint server can access them, and custom server-side code is not allowed in an app for SharePoint. (A rich set of client object models and a REST/OData service make it possible for apps for SharePoint to do almost any end-user–oriented SharePoint extension.) For more information about deciding between classic solutions and apps, see Apps for SharePoint compared with SharePoint solutions. Also helpful for making this decision is Choose the right API set in SharePoint 2013.

There are three major categories of choices that need to be made when an app for SharePoint is designed. As always, application design involves trade-offs; choices you make in one category may limit your options in another. Not every possible combination of choices is feasible.

• Hosting: Apps for SharePoint can be usefully divided into two major types based on how they are deployed and hosted. For developers, there is a crucial distinction within the cloud-hosted category between provider-hosted and autohosted.

  • Cloud-hosted apps include components that are hosted outside the SharePoint farm.

    • Provider-hosted apps have their primary data storage and business logic deployed and hosted by you—the developer—outside of SharePoint in servers or a cloud account that you provide. You are responsible for enforcing isolation between the accounts of the various customers who purchase your app. Such apps can have SharePoint components too. These are hosted in the customer's SharePoint farm. This type of app provides you with the most flexibility in the other categories of design choices. It also enables you to use non-Microsoft platforms for the external data, logic, and web user interface (UI). (Within the category of provider-hosted apps, you also need to distinguish between apps whose remote components are within the same corporate firewall as the SharePoint farm and those whose remote components are outside of that firewall. The authorization systems for these two scenarios are different, which, in turn, makes a difference in which programming language you use to access the SharePoint data. For more information, see Cloud-hosted and high-trust app design considerations in SharePoint 2013.)

    • Autohosted apps relieve you of the need to host external app components. Instead, you add websites, (either Microsoft ASP.NET or non-Microsoft, such as PHP) and SQL Azure databases to your app with simple XML markup. The installation architecture of SharePoint 2013 automatically provisions these components in a Windows Azure Web Site account that is associated with your customer's SharePoint Online account. Such apps can have SharePoint components too. Certain kinds of Windows Azure components, including worker roles, table storage, and blob storage cannot be included in this type of app. This kind of app cannot be given away for free.

      Note
      The infrastructure for autohosted apps will remain in preview status for a period of time after SharePoint 2013 releases. Autohosted apps (which includes all apps that depend on Microsoft Access) will not be accepted by the SharePoint Store during this preview phase. We will update dev.office.com with information about autohosted apps as it becomes available.

  • SharePoint-hosted apps consist entirely of SharePoint 2013 components, such as lists, content types, workflows, and Web Parts. There are no external components. For more information about the kinds of SharePoint components that can be included in apps for SharePoint, see Host webs, app webs, and SharePoint components in SharePoint 2013.

  For more detailed information about the hosting options of apps for SharePoint, see Hosting options for apps for SharePoint.

• Connectivity: SharePoint 2013 supports three kinds of secure create/read/update/delete (CRUD) access to data.

  • External web applications in an app use the OAuth protocol to access SharePoint data. For more information, see Authorization and authentication for apps in SharePoint 2013.

  • JavaScript can access data in a SharePoint app web and data on other websites within the same tenancy by using a special JavaScript library that enables secure cross-domain scripting. For more information, see How to: Access SharePoint 2013 data from remote apps using the cross-domain library.

  • An app for SharePoint can also access external data through Business Connectivity Services (BCS) or a web service proxy. For more information, see Business Connectivity Services in SharePoint 2013 and How to: Query a remote service using the web proxy in SharePoint 2013.

  For more information on data storage and access in apps for SharePoint, see Data storage options in apps for SharePoint, Data access options for apps in SharePoint 2013, and Work with data in SharePoint 2013.

• UI: There are three ways to surface an app for SharePoint in SharePoint: at a minimum, all apps are surfaced in a full web page. Optionally, an app can also be surfaced through an app part, and through a menu item or ribbon button. For more information, see UX design for apps in SharePoint 2013.

  Note
  Apps for SharePoint can be installed by your customers to multiple site collections in a tenancy, or on a website-by-website basis. The former are called tenant-scoped apps. If you want your customers to have the tenant-scoped option, you may not include a custom ribbon button or an app part. For more information, see Tenancies and deployment scopes for apps for SharePoint.

Another way to think about your app architecture options is to think of the app as having three logical tiers: the UI, the business logic, and the data access. Each layer has multiple implementation options; again, choices made for one layer limit the options for others. The following tables describe some of the some of the options, and their uses, for the remote components of an app and the SharePoint components.

The app for SharePoint model enables so many possibilities for design that a simple decision tree is not possible. The following are some of the most important factors to consider when constructing the architecture of an app for SharePoint.

• Most importantly, of course, is the functionality you want to make available to customers—the use cases. For example, if your app includes processor-intensive functions, such as converting video files to another video format, that would be argument for creating a provider-hosted app in which the processing is done on one of your servers or a Windows Azure worker role.

• Because one kind of app for SharePoint, provider-hosted apps, requires you (or your customer) to host the non-SharePoint components and to enforce tenant isolation, you need to consider whether you have the hardware and IT staff to do this (or whether your targeted customers do).

• Which customers you are targeting is also a crucial consideration. If all your apps will be used in-house (that is, you have no external customers), provider-hosted apps are significantly easier to implement and maintain than when you have external customers. If you intend to sell the app publicly, you should also consider whether you will market it to businesses that have SharePoint Online accounts or those with their own SharePoint farms, or both.

• You need to think about whether you want to give away the app, or a simple version of it, for free. Autohosted apps cannot be given away. There is always a charge for the Windows Azure Web Sites cloud that hosts the remote components.

• You should also consider your existing skills or the skills of your development staff. For example, if you are an experienced ASP.NET developer, that would be a point in favor of creating a remote web application (which could be autohosted) and surfacing SharePoint list data in a grid control on an ASP.NET page. On the other hand, if you are an experienced SharePoint developer, that would be a point in favor of using a custom SharePoint list and site page, with JavaScript to perform processing.

• Design apps for SharePoint

• Important aspects of the app for SharePoint architecture and development landscape