The SharePoint 2013 App Model is better than Farm Solutions

Almost seven months ago, after everyone got access to the public beta of SharePoint 2013 I wrote a post titled SharePoint 2013 Preview – Apps or Crapps?. My conclusion at the time was ‘too soon to tell.’ Since then I’ve been re-implementing a complex sandbox solution I originally wrote for the first version of Office 365. I never released the product because I was almost done building it when I found out there was to be a new model in SharePoint 2013. After many months I have a more or less complete architecture and a great deal of code.

Unfortunately, I am not a rich man and I can’t spend every day (or even most days) writing code for myself and I’ve kept busy building farm solutions for other people. The split time has helped me consider which I prefer from an objective standpoint as I’ve worked with the good and the bad of each. I like farm solutions and demand for my services to build them has only improved since I started building them full time in 2007. There is no pressure to switch to the app model in my consulting practice. I have customers that are using it for pilot initiatives, but the farm solution practice is strong enough that it is still not uncommon for us to turn away business because we are too busy.

Farm solutions have been very good to me, but I’ve had enough experience with the app model to now say that, generally speaking, it is objectively better for most scenarios.

‘Better’ is a Dangerous Word

What makes ‘better’ so dangerous is that it is usually subjective and even when it is objective it depends on how you frame the questions and weight the answers. So I should be clear that the question of which is easier is one I am discounting because it depends as much on the tooling as anything else and I will say right up front that, if your main goal is to build something quickly then a farm solution is the way to go. Visual Studio makes it easy to build and test farm solutions and it offers the most complete API with the best documentation and an internet full of blog posts for just about any situation you are likely to encounter.

On the other hand, if you want to build the most robust and scalable solution possible that provides the widest array of options with architecture that is most aligned with modern client-side techniques and with distributed cloud architecture, you should seriously consider an app. The problem is that there is a good deal of pain to suffer and work to do for your first non-trivial solution. One reason it’s taken me so long to make up my mind is that I’ve had to do lots of setup and write lots of plumbing code – work I won’t have to do on subsequent apps. The architecture and framework was definitely not trivial and represents a significant investment. Fortunately it isn’t a recurring cost.

The questions I will ask and answer as I make the case that apps are better than farm solutions are as follows:

(In this post)

  1. Which better supports modern web development techniques?
  2. Which has better scalability?
  3. Which is easier to version and maintain?

(In future posts)

  1. Which provides better experience for users?
  2. Which provides more flexibility, control, and security for farm owners?
  3. Which provides more flexibility, control, and security for software vendors?
  4. Which is easier to integrate with other systems?


One Other Qualifier

The app model allows integration of completely alien systems and platforms into SharePoint sites. You could make an app that embeds a video game based on HTML 5 into a SharePoint site via an App Part and serve it from a potato-powered web server running assembly language on a Z80 processor if you want. The app I am using as the basis for this article is a traditional SharePoint business solution consisting of lists, libraries, user interface, and automation based on said lists, libraries, and UI. It is an app that started life as a sandbox solution and that could easily be implemented as a farm solution.

Which better supports modern web development techniques?

This is actually a tie. You can (and in my opinion should) use the same UI development techniques with either model via HTML 5 and JavaScript. Farm solutions also give you the option to use traditional ASP.NET Web Forms with traditional server side rendering while the app model will force you to use HTML and JavaScript on the client. However, you can and should be using these client-side techniques with Web Forms in SharePoint 2013 – SharePoint 2013 does. Lists, libraries, and search are now rendered by JavaScript by default in 2013 and the simple fact of the matter is that there is much more energy going into browser based UI than in Web Forms because it’s much easier once you master the required techniques.

Which has better scalability?

On balance, apps provide better options for scaling than farm solutions because they force custom code to exist in the browser and/or on a server outside of the SharePoint farm. In either case the custom code automates SharePoint using a set of abstract web services. Farm solutions are all about running code directly in the farm. If this code is poorly written, it will affect the performance of the entire farm. However, even when the code is properly written, it runs on the farm and consumes resources. An app offloads this work to the browser and/or other servers.

On the other hand, the client-side API’s involve a (potentially big) network hop(s) with a corresponding time delay. If you write the code poorly or routinely move large amounts of data across the wire you will be faced with a slow system. Solutions that need large amounts of data from SharePoint will perform better as farm solutions. So, a timer job that reads data from a database to build a large PDF file for placement in a document library will work better, and indeed may only be possible, as farm solutions.

So, to be precise, apps provide better potential for scalability in many cases, but bad code is bad code.

Which is easier to version and maintain?

This question is easy to answer and the answer is unambiguous: apps are easier to version and maintain.

The downside to farm solutions is that they use a very powerful but comparatively rigid combination of file systems and a SQL databases in conjunction with lots of XML files. In order to use a solution, it must be installed on a farm and put files directly on each server. The XML files are features, site templates, list templates, and a wide variety of other artifacts. This system works really well unless the same solution is installed on multiple farms and used by many site collections and needs to change to accommodate new features or bug fixes. Furthermore, some things, like site and list templates, are very dangerous to change once sites and lists exist that use the templates.

The app model makes it possible to centralize and serve content to as many farms as is necessary and if you use CSOM to provision everything instead of XML you remove the coupling between concrete instances of sites and lists and their definitions. CSOM allows the creation of fields, content types, lists, web part pages, and other types of files. In my app everything, with the exception of one page, is provisioned by the application server running on Azure. The app server is capable of updating these items and of adding new items. It makes no difference how many farms use the app from an update perspective, each can be patched centrally whenever a user launches the app.

Here is a screen shot of the actual app package in Visual Studio 2012. It consists of the app manifest and a single module.


Here is a screen shot of the (not yet unveiled) app in an app web on Office 365. As you can see it has more than just one page!

A Note on Background Processing and Elevation of Privilege via Impersonation

Farm solutions provide a relatively easy facility for creation of background jobs via the SharePoint timer service. In my app background processing is done via Azure service bus and worker roles. The centralization of application services makes it easier to scale, monitor, diagnose and recover from problems because I don’t have to suffer through the lack of access ULS logs in Office 365 – logging happens on my end. However, to do this sort of work requires the ability to connect to the SharePoint site without a user doing the work in a browser.

As it turns out, this is pretty easy to do in an app but you need to store some information about the admin account that installed the app or allow the admin to specify an account. Apps use OAuth and there are a variety of tokens involved in getting a context to a site. In this case there are two tokens of interest, the access token used to connect which is good for twelve hours and the refresh token used to get a new access token which is good for six months. If you have these pieces of information for a user you can open a context as that user. The app model gives you some help in the form of the TokenHelper.cs class, but it is up to you to figure out how to persist and manage these values. The only thing the model does to help you with this is to provide an immutable cache key for each user along with the tokens so that you can store them without having to store information that identifies the user in human readable form.

In my app this is done on the start page which is in my application server, not in the app package. This start page captures and persists the tokens and keys when the user launches the app and then redirects either to the initial landing page which kicks of the provisioning process or to the app’s home page which only exists once the initial setup is complete. At that point I can act on behalf of the user from the application server as needed and I can put the complicated (and proprietary) code in my app server as c# instead of in the browser as JavaScript.

So, you can elevate privileges in a low-trust app via impersonation and do work on behalf of the user or run a scheduled process. It does not require a high-trust solution (but high trust makes it much easier). Most people think you can’t. There are many misconceptions about the app security model that I plan to touch on in the next post when I take a crack at answering the rest of the questions in my objective criteria.

Until then, happy coding!


P.S. If you’d like help or training building an app, I’d love to hear from you.

Author: Doug Ware