Sean is a senior consultant at ThreeWill. He has over 16 years of experience developing web applications. His primary passions are in usability, group collaboration, project and process automation, data visualization, and social media tools. He is an MCSD in Web Applications and an MCTS in SharePoint Application Development.
Over the last year, one of the hottest topics of discussion at ThreeWill has been the new SharePoint 2013 App Models; and specifically where each model might make the most sense given a particular solution requirement. Choosing an App Model is a critical decision for your solution, and as I worked with each of them, I hit a number of gotchas with their architecture that weren’t obvious at the project outset. These gotchas happened despite the effort I put into researching them in SharePoint blogosphere.
My top takeaway from the experience so far is simple but provocative:
The number of “real world” business cases where SharePoint-Hosted App Model variations make sense is very small; most solutions are going to require a Provider-Hosted app.
You can find a number of big names in the SharePoint community—people I have tremendous respect for—who’ll disagree with that statement. I don’t like offering unsubstantiated opinions, so over the next few blog posts I’m going to share my experiences developing apps for SharePoint 2013, across three App Model variations.
Here’s the roadmap for the series:
- Part 1: Introduction, a.k.a. “This Post”. A high-level introduction to SharePoint 2013 App Model considerations with some thoughts on why we’re here and a word of encouragement.
- Part 2: App Web Hosted Apps. My thoughts on SharePoint-Hosted Apps with app data stored in the web, and where the app deploys to and runs in.
- Part 3: Host Web Hosted Apps. My thoughts on SharePoint-Hosted Apps with data stored in the web that activates/installs the app. The differences between Host Web and App Web may seem subtle, but a couple of the distinctions are critically important.
- Part 4: Provider-Hosted Apps. Apps where the primary logic and runtime are in an application external to the SharePoint site. Bringing secondary environments to your solution has complications, but it offers tremendous power.
- Part 5: Observations and Conclusions. I’ll wrap up the series by offering a high-level comparison of each app model across some common application features, requirements, and concerns. I’ll also provide a matrix you’ll be able to adopt and modify for making App Model architecture choices in your own apps.
Note that the three App Models I’ll investigate in this series are not a comprehensive list. There’s plenty of room for variation and nuance, and in all likelihood hybrids (in multiple senses of the word) will be the most common solutions. But the three architectures I’ll feature are certainly representative of the SharePoint 2013 App Models, and they cover two of the most basic decisions you’ll need to make for any App Model-based solution:
- In SharePoint, where will the data for my app live: in the App Web or in the Host Web?
- Am I going to need to use an external provider? If you start without one, I’m betting you’ll want one before release 1.1.
As I cover each App Model, I’ll provide code in one format or another from a real app that I’ve worked on. I’ll offer my thoughts on the strengths and weaknesses of each model. I’ll also provide “pro tips” (I’ll allege that they’re pro tips) based on my experiences and battle scars.
But First, Some Background
Before we dig into the specifics of each model, I want to set the table. We’re standing at the most significant inflection point in SharePoint’s product history for a handful of converging reasons. The most obvious is SharePoint needed a plausible story for cloud-hosted custom development. Sandbox solutions didn’t inspire tremendous adoption in the industry, and even in their unappealing state they relied too heavily on the server to be truly Microsoft 365 friendly. In contrast, both SharePoint-Hosted and Provider-Hosted solutions completely remove custom code from the SharePoint server while still offering an effective presence and broad support for customizations. If the primary goal of the SharePoint 2013 App Models was to provide cloud-friendly customization routes for SharePoint, mission accomplished. They’re not without limitations and corners, but overall they’re a success.
From my perspective, the new App Models pursue a more intriguing secondary goal. When I’m feeling cheeky I sum it up like this:
Pre-2013 SharePoint was the platypus of the Microsoft middleware stack, and in desperate need of an evolutionary reboot.
SharePoint Is A Platypus
Pre-2013, SharePoint had been stuck in a strange evolutionary backwater. It’s architecture was still firmly rooted in concepts from ASP.NET version 1 and 2: Web Forms, Web Parts, Server Controls, etc. Concepts more than a decade old at this point, and to me they feel even older than that. And though Pre-2013 SharePoint may be highly adapted to certain environments, there are steep capability edges if you need to grow beyond its natural habitat.
Outside of this backwater, the rest of the Microsoft web development world has enjoyed amazing progress courtesy of the ASP.NET and .NET framework teams. The advances I miss most when writing pre-2013 (i.e. Farm) Solutions are:
- ASP.NET MVC
- Entity Framework
- Visual Studio Test Automation
- Single-Page App Frameworks like Angular and Backbone
- Web API 2
In short, the web development world has been passing SharePoint by. To illustrate how large the gaps are, I’ve worked up a timeline comparing SharePoint’s product release cycle with major milestones in web development tooling:
The kicker is that these advances aren’t just available; they represent the prescribed best practices for the web development community at large. We might disagree about the impact of these developments, or how workable the workarounds are, but I can make a strong case that SharePoint has been perpetually riding the tail of web development technology curve, and that story wasn’t going to improve much without drastic intervention.
The good news is that the SharePoint 2013 App Models are that drastic intervention: they’re an end-run around the platypus’ limitations. Even within the constraints of an App Web Hosted solution, the choice of UX tools and frameworks feels liberating compared to the nip-tuck approaches to client-side development for Farm Solutions. And with a Provider Hosted architecture, you’ve got complete access to the latest versions of your preferred development stack and community tools. You’ll run out of time to research your options well before you run out of options.
If you’ve stuck with me this far, let me offer you one last word of encouragement: Don’t Panic. Almost always good advice, but now it’s particularly apt for the seasoned SharePoint developer who’s been paying bills by writing custom features, web parts, app pages and server controls for for the past 3+ years. You know – those of us who’ve been riding the Platypus. We’re all having a serious who-moved-my-cheese moment over SharePoint 2013, but in the long run, I think our lives will improve as the new App Model adoption rates climb. Yes, we’ll have to invest time learning new tools and development patterns. But those tools and patterns are going to make us more productive, align our skills more closely with the larger web development community, and offer us opportunities to extend the reach and value of our solutions.
Next Up: App Web Hosted Apps
In my next post, I’ll take a deep dive into my experience working with App Web Hosted Apps, and try to explain where I think they make the most sense. Spoiler alert: it may be User Experience related.
1: TL;DR is geek shorthand for “Too Long; Didn’t Read”. It’s used either derisively by commenters as a response to an over-long post, or pre-emptively by authors to indicate a quick summary of an over-long post.