SharePoint 2013 Apps basics

What are Apps?

Apps for SharePoint (or SharePoint App) is the offi cial name for apps you build and deploy to SharePoint. For those familiar with SharePoint, think of the SharePoint App as the evolution of the SharePoint Solution (that is, WSP).

 

The SharePoint App is a move toward a more cloud-centric development model — one where the code does not reside on the same server as SharePoint. This is a result of a greater migration of code to the cloud and a need to architect a platform to support smother updates and code that is loosely coupled to SharePoint and deployed to the cloud, as well as to mitigate the growing problems that server-side code typically presents

 
The following diagram illustrates two potential application architectures, reflecting on code that is deployed to Windows Azure or code that is deployed to IIS.

 

In the noncloud application, you’re using IIS — which could be an entirely on-premises installed and deployed app (which might be the case if you’ve installed the full SharePoint Server version on-premises). In the cloud app, the Windows Azure domain is off-premises (for example, in the public cloud data centers that Microsoft manages). However, both types of apps have two components: the configuration fi le (.APP), and the assemblies that execute your code, which are deployed into a separate server domain. Thus, you’re either running these new SharePoint Apps in your or your customer’s premises or the Internet.

 
There are three types of apps available in SP 2013.

1. SharePoint hosted
2. Auto hosted
3. Provider hosted

SharePoint hosted

The SharePoint-hosted deployment type represents a way to deploy client-side, lightweight apps to SharePoint 2013. The easiest way to think about the SharePoint-hosted app is as an application that has no server-side code. It is an application made up of static application fi les or pages that reside on your SharePoint tenancy or instance. Think of HTML and JavaScript fi les that enable client-side coding. When users access the SharePoint-hosted app, they are redirected to the page that contains your application. The SharePoint-hosted deployment type is good for lighter-weight apps such as branded list views, media apps, or weather apps.

Auto hosted

The Autohosted deployment model is a signifi cant departure from previous SharePoint applications. In this model you build Apps for SharePoint, but the code is seamlessly deployed to Windows Azure in the background — so SharePoint automatically creates the cloud-hosted app for you.

Thus, for all intents and purposes code looks like it’s running on SharePoint, when in fact in the background it’s deployed to a special Offi ce 365 Windows Azure instance (so in effect a different domain) and registered as an authenticated and authorized app with SharePoint. You don’t have complete access to the entire platform capabilities of the Windows Azure platform with the Autohosted deployment model; however, you do have enough of the platform to build some interesting applications.

 

Provider hosted

 

The Provider-hosted deployment model is a richer and more fl exible version of the Autohosted deployment model. In this model, your code runs in a different domain — often framed in the context of cloud deployment. For example, you can deploy your code to Windows Azure and then register it to authenticate and integrate with SharePoint 2013.

 

When users access a cloud-hosted application deployed using the Provider-hosted app model, they are redirected to a web page that resides in an external domain or server — where the application code resides. One of the key reasons this is relevant is that the external server doesn’t necessarily need to be a Windows Server–based application; you could be running a PHP app on a Linux/ Apache server and still have that web application integrated with SharePoint.

 

In the next article I will show you, how to create and deploy SharePoint hosted apps in detail....