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
- 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:
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.
|
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:
|
What Can be Created as Apps -
What cannot be created as Apps -
|
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.
Anonymous
March 21, 2013
Very very nice post. I am impressed with your post and wrote my understandings on SharePoint app modelwww.sureshpydi.blogspot.in/.../sharepoint-2013-app-model.htmlAnonymous
December 03, 2013
Great post for people who are starting with SharePoint App Models. Thank you for providing such clear and comparable concept.Anonymous
January 31, 2014
Thanks Amit, you are just playing the role of Sharepoint 2013 teacher for many of usAnonymous
March 18, 2014
Very good and easy to start...!Anonymous
May 05, 2014
Thanks.Good article ,very useful for beginners in SP2013 app development .Anonymous
May 11, 2014
Awesome post... just what is needed for a beginer in APP Model!Anonymous
June 15, 2014
Thanks.... its very useful for a beginer in sharepoint App model.Anonymous
December 02, 2014
Great stuff :) really helpful to understand I am also looking for learning Sharepoint core solutions - biggner level please share me some resource like thisAnonymous
January 11, 2015
Thanks for sharing. this is very useful information.Anonymous
May 20, 2015
excellent...this is what I was looking forAnonymous
July 05, 2015
Great article. thanks.Anonymous
January 28, 2016
Good article. There is few more additions to App-limitations that I could think about -
- SharePoint Custom Timer-Jobs cannot be deployed as Apps in SharePoint-2013
- Custom List-Definitions cannot be deployed as Apps
- Also converting a simple event receiver (list) to a remote event-receiver is an unnecessary overhead.