The SharePoint App Model
As a provider of SharePoint Apps like Work365 Suite we are often asked about how our applications are built. This often leads us to the conversation about the SharePoint App Model. What is it? How does it work? When should I use each of the apps? To answer these questions, we will be featuring a multi-part series on the SharePoint App Model, starting with the basics.
What is the SharePoint App Model?
The SharePoint 2013 app model is the next step in the evolution of incorporating user code into the execution of a SharePoint environment.
Early in SharePoint development, IOTAP developed full farm solutions. Our code ran server-side and directly interacted with out of the box features. For better or worse, we could deploy any code we wanted. Often, this wasn’t a good thing leading to security and performance issues.
Microsoft’s first step in addressing these issues was allowing for sandboxed solutions. While this forced us to make design decisions we didn’t always like, it also ensured that the code we wrote wasn’t going to negatively affect the other SharePoint subsystems. In this model, our code still ran alongside out of the box features. So, the only way that Microsoft could ensure safety was to limit the features to which we had access.
With SharePoint 2013, Microsoft introduced the app model. For us, the app model has been a great step towards having custom code safely run with access to a large variety of SharePoint functionality, including the following:
- (Almost) 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 to in user interface as apps, to create a more unified experience.
- No custom code on SharePoint server: While there are different SharePoint app models, none of them execute code in the process. The different models tackle this in different ways from running client side to running on your provisioned infrastructure. The end result is your code cannot interfere with an otherwise healthy SharePoint farm.
- Easier to upgrade to future versions of SharePoint: The SharePoint App Model provides a level of abstraction. All calls are made against exposed REST services providing low coupling. You can be assured these will continue to improve since they are the same APIs used by the workflow and other services.
- 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 servers such as IIS server OR any other infrastructure) you can leverage built-in SharePoint features like lists and workflows to speed your development. This allows you to focus on your custom business logic while using the SharePoint features you’ve grown to love. This provides more flexibility – further than what can be done with farm/sandboxed solutions
- Provides an additional approach for development: The app model does not replace the solution based approach of development/deployment. It is an additional option. So in SharePoint 2013, for development, we can use any of the following approaches: SharePoint Apps Fully trusted solutions or sandboxed solution.
While these changes enable a lot of new solutions that we couldn’t build before, they come with added complexity. As we model our applications we need to consider SharePoint like a distributed data store. (Look for more on that in a future post.) For now, it is important to know that all app types interact with SharePoint in the same exact way.