Part 2 - Introduction to SharePoint 2013 App Model

This post is in continuation to my previous post "Part 1 - Why Apps are needed for SharePoint 2013", wherein I had explained that there have been some issues with fully trusted SharePoint 2010 applications, they can destabilize the whole farm and they are difficult to migrate to newer versions of SharePoint.

The new SharePoint 2013 application model not only addresses concerns around solution packages, custom code on server, but also introduce a lot of new capabilities.

Key points about SharePoint Apps

• Everything is in a SharePoint site is now an app
  • Yes, everything in a SharePoint site is an app. This includes lists and libraries. Though the actual implementation of lists and libraries has not changed. They are referred in user interface as apps, to create a more unified experience. For e.g. if you would like to create a new document library, you need to create an app and pick document library and then name it.

 

• No custom code on SharePoint server
  • As per the new SharePoint 2013 App Model, SharePoint apps do not live in SharePoint, rather they execute within a browser client, or in non-SharePoint server such as IIS server or in cloud server such as Windows Azure. SharePoint apps are granted permissions to get back into SharePoint sites via OAuth and communicate with SharePoint via REST/CSOM.

 

• Easier to upgrade to future versions of SharePoint
  • This is possible because the apps are running against client side service 

 

• Reduces the ramp-up for those developing apps
  • Developers building SharePoint apps don't need to be familiar with SharePoint specific things  e.g. object model. If they want to work with data from SharePoint, then they have the option to leverage some of the standard services or CSOM.

 

• Leverage hosting platform features in new apps
  • If you develop an app which is going to run in another hosted platform (like Windows Azure OR non-SharePoint server such as IIS server OR any other infrastructure) but it's going to use SharePoint UI such that end user feels that he is in SharePoint and the app looks like SharePoint. However, since the app is running in another environment like Windows Azure, then you can use the capabilities of hosting platform i.e. Windows Azure, which you normally cannot do in SharePoint.
  • This enables taking SharePoint apps to different levels - further than what can be done with farm/ sandboxed solutions

 

• Provides additional approach for development
  • The app model does not replace the solution based approach of development/deployment, it is an additional option. Thus, in SharePoint 2013 for development, we can use either of the following approach:
    • SharePoint Apps  
    • Fully trusted solutions
    • Sandboxed solutions

 

Which development approach to use - SharePoint Apps, Farm Solution or Sandboxed solution?

It is important to understand the differences between the three development models which we have i.e. SharePoint Apps, fully trusted solutions and sandboxed solutions.

 

	Farm Solutions	Sandboxed Solutions	SharePoint Apps
When to develop?	Use farm solutions only when you cannot achieve the same via apps	SharePoint sandboxed solutions are deprecated in SharePoint 2013 in favor of developing apps for SharePoint, but sandboxed solutions can still be installed to site collections on SharePoint 2013.	Recommended approach - Develop an app whenever you can
Use Server-Side SharePoint API	Fully trusted solutions allow developers to write code that can use server side API.	They are also called as partially trusted solutions. Server side code runs under a strict CAS policy and provides limited capabilities.	Server side code running of SharePoint server is strictly prohibited in apps. Any server side code that needs to be used within your app needs to run and hosted outside SharePoint on a different server such as cloud or a different IIS server.
Use Client-Side SharePoint API	Yes	Yes	Yes, and the capabilities provided by client side SharePoint APIs in SharePoint 2013 is much more as compared to previous versions.
On-Premise Deployment Friendly	Custom code in these solutions is deployed to the bin directory or to GAC. Code can be secured using CAS policies but is typically runs inside full trust.  These type of solutions are deployed by farm administrator.	They can be uploaded and deployed by site collection admins and owners. It has limited set of APIs available from server side SharePoint. In addition server side code cannot make request to externally hosted web services or databases. Though developers can use client side solutions to call external services and even make cross domain calls.	Yes
Hosted Deployment and Cloud support	Farm trusted solutions cannot be deployed in hosted SharePoint deployment. They are only available in on-premise deployment.	Sandboxed solutions are the only type of solution that can be deployed to hosted SharePoint installations.	Yes. In addition, developers will be able to publish their apps to a public marketplace for download & purchases. In addition organizations will be able to create a private corporate marketplace where the apps would be available to the organization.
Install/Upgrade/Uninstall	With these type of solutions, developers should manually code each of type of activity logic when solutions are upgraded or uninstalled	Similar to farm solutions, developers need to write code to write logic when solutions are upgraded or uninstalled.	Microsoft has made a lot of investments in install/upgrade and uninstallations of apps to make it end user friendly experience and to ease out developer challenges.
Server Outages	When error occurs in these, they can affect the service app pool and in worst case can even host server outages.  These are the most unrestricted type of solutions that can be deployed in SharePoint 2013.	Runs on the server farm, but in a dedicated isolated process. Thus, they are considered safe and cannot cause server outage.	Apps run isolated from a SharePoint farm and cannot cause SharePoint server outages.
Authentication Options	The components in the solution can, and usually do, run in full trust.	The components in the solution run in partial trust.	Before you can call SharePoint APIs from your app, you need to authenticate to SharePoint. Which authentication mechanism you use depends upon where the code of your app is running.   Inside SharePoint: You have to use HTML and JavaScript, and authentication is already taken care for you.   In the cloud:    Use client-side code along with the cross-domain library Use server-side code along with OAuth REST APIs
What can be developed?	Almost all components can be deployed as Farm solution.	Refer to this link to understand in detail what can be implemented in Sandboxed Solutions in SharePoint. Some of the most common things a sandboxed solution cannot do are:  Connect to resources that are not located on the local farm Access a database Call unmanaged code Write to disk    Access resources in a different site collection	What Can be Created as Apps -   Custom Web Parts (remote pages that contain custom Web Parts)     Event receivers and Feature receivers(remote event receivers) Custom field (column) types Custom web services built on the SharePoint Service Application Framework Application pages   What cannot be created as Apps -   Custom site definitions Custom themes Custom action groups and custom action hiding User controls (.ascx files) Delegate controls

 

In my next post, I will discuss Apps Hosting and Branding - wherein I will mention about app hosting options, different types of apps, entry points, user experience and branding.