bell.jpg

SharePoint 2013 App Models Considered – Part 4

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.

Up to this point I’ve introduced some high-level considerations for SharePoint app development (part 1), and two App Model variants that don’t have real legs in my opinion:

  1. App Web Apps (part 2) are restrictive, offer reduced productivity, and create un-SharePoint-like data silos
  2. Host Web Apps (part 3) are restrictive, offer reduced productivity, and are frustratingly fragile (so far)

This brings us back to the thesis of this series:

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.

This post marks the inflection point in this series: for the first time I’m covering an App Model that I believe has serious potential. And the potential isn’t just serious; it’s broad and proven. The truth is, the Provider-Hosted App Model is just a SharePoint-flavored version of modern best practice throughout the rest of the industry: our custom code lives in app environments we control, and we consume other services via their public REST (or similar) APIs. This is the way developers build SalesForce apps. This is the way developers build LinkedIn apps. This is the way developers build Farmville. It has been the industry’s best practice for product integration for years, and SharePoint has finally caught up 1. Huzzah!

To wrap this back to my furry, duckbilled metaphor:

Breathe a sigh of relief and be glad! Now the platypus can stay happily in his backwater, and your app doesn’t have to crawl in with him just to collaborate.

As usual I’ll try to make this palatable and predominantly pain-free for the mildly interested (my entire audience?):

  1. Provider Hosted Apps Overview
  2. Real World Sample App
  3. What’s Good About Provider Hosted Apps
  4. What’s Bad About Provider Hosted Apps
  5. Where Provider Hosted Apps Fit
  6. “But I Don’t Want To Go To The Cloud…”
  7. Pro Tips for Provider Hosted Apps
  8. Notes

Provider Hosted Apps
As covered in my first post, one of Microsoft’s primary drivers for introducing the SharePoint 2013 App Model was to make SharePoint customizations cloud-friendly. To do this they had to get custom code off the SharePoint server. Period. The first two App Models we reviewed (App Web Apps and Host Web Apps) did this by completely eliminating server code from custom solutions. SharePoint 2013 offers a beefed up REST API, beefed up JSOM, and you can get a lot done in SharePoint with nothing more than that. Or at least it seems so on paper.

The difficulty with this approach is that getting rid of the server is a drastic move for most web applications. Most applications need server code for private logic, security, and/or to give the application “agency” beyond a user’s web browser request (i.e. for lifecycle events). And most web developers are more productive when they can write some part of their apps in server code.

So if your SharePoint app needs server code, but it can’t run on the SharePoint server, bring in another server!

This is the exact premise of Provider-Hosted Apps: let SharePoint focus on doing SharePoint things well, and bring in another “Provider” to host custom features and services. I’ll try to frame this in the physical-logical block diagram mash-up (with App Web and Host Web Apps provided for comparison):

Let’s cover the highlights:

  1. The SharePoint-Hosted App Remains. Whether you deploy anything inside it or not, your app needs this beachhead in SharePoint to provide an access point and to participate in whichever version of the “identity dance” you choose.
  2. The Provider Makes It Good. Okay, I’ll admit that’s rebuttable, but my opinion leans heavily in that direction. At any rate, the external provider defines this model, and that’s where I’ll focus my attention.
  3. BYO Web App. Your app is all grown up now. What dev stack are you going to use? Frameworks or services? 3rd Party Services? Dev environments? It’s all up to you.
  4. Server-Side Goodness, A La Carte. Being an adult means you get to order from the full menu. You can order a relational data store, or a non-relational one, or pig out with both and a side of your favorite message queue. Mmmm…message queueing.
  5. BYO Web API. I won’t go into to detail here, but SharePoint’s OAuth implementation is a bit non-standard, and SP.RequestExecutor is WAY non-standard. Many important browser frameworks work OotB with standard OAuth or REST, but break with SharePoint. Writing your own API may sound like a headache, but it’s one I’d gladly take versus the headache of shimming JavaScript frameworks. Besides, a clever app can find a number of delicious uses for a fresh API.
  6. Dump That Heavy Browser. Your app has a full middle-tier now, so the browser can eliminate the extra business logic burden, and focus on presentation logic, i.e. what it was designed for.

Are you hungry for a Provider-Hosted App yet?

The (Doubly) Real-World App
In my second post of the series, I mentioned that ThreeWill had rewritten the Fab 40 “classic” Absence & Vacation Request app as technology demonstration of an App Web App. I also mentioned that it turned out to have some glaring flaws due to the limitations of that model. In the wake of that and several other bad trips with SharePoint-Hosted variations, we decided to try another Fab 40 app, but this time as a Provider-Hosted App: Help Desk.

Following are some screenshots of the much-improved Help Desk application:

 

The features are stripped down, but under the hood this app has some nice specs: The server code runs ASP.NET MVC5, with Web API 2.0 providing services to the browser. In the browser it’s running Angular and Bootstrap for a SPA2 with a responsive user experience. This is a modern stack that is a pleasure to work with, and I don’t miss the platypus even a little bit.

In addition to that, it includes some key demonstration points that a new-to-Provider-Hosted-Apps developer will find useful. Things like application lifecycle event handling, and some helpers for identity management and navigating SharePoint security in both MVC and Web API controllers3. Trust me—those alone are worth the price of admission.

Just as we have for the Absence & Vacation Request app, we’ll be providing the full source code of this app for anyone who’d like it. It’s still too alpha to post to GitHub or similar, but you can request a zip of the code from me via email.

What’s Good
The Provider-Hosted App Model has a lot to recommend it, not only in comparison to the SharePoint-Hosted app models, but in some cases on an absolute level:

  1. Full Middle Tier. You gain so much here it’s difficult for me to overstate its value. Let me put it this way: remember the list of “bad things” about App Web Apps? This alone cancels out or significantly mitigates the first six of those seven issues. For most web developers, this will drive the value of Provider-Hosted Apps well past that of any SharePoint-Hosted variation. More on that below.
  2. Best-Of-Breed Dev Stack. You may have picked up that I’m a devout believer in the power of the right dev stack. Provider-Hosted Apps give you full control here, at every tier of your application.
  3. Design Freedom. The set of architectural and design controls for browser-hosted code has become significant, but it’s still tiny compared to what you can do when you have control over one or more servers or services. The only real restriction is you still need a SharePoint beachhead, but you have several choices on how you use it.
  4. High Availability. Remember my gripes about our downtime with SharePoint-Hosted apps? This is your best bet for high-availability customizations, period. Even more so than Farm Solutions, which have their own issues. More on high-availability below.
  5. Longer Reach (Into SharePoint). SharePoint 2013 has greatly expanded and improved its REST API, and expanded JSOM access with it, but CSOM can still scratch itches that REST and JSOM can’t. It’s nowhere near the coverage you get with Farm Solutions, but it covers a wide array of activities.
  6. Lifecycle Management (ALM). Seasoned JavaScript developers can manage ALM convincingly with tools like Jasmine or Mocha. But from my experience, most developers can get further faster with test automation, requirements management, and other ALM activities when they have access to the server tools of their choice in addition to these excellent frameworks.
  7. Performance Controls. When you only have code in the browser, your have meager controls for app performance. Adding a server or service to your mix opens up significant options. If that service happens to be running in a cloud environment, your control goes from significant to tremendous.
  8. Revenue Options. If you have any desire to derive revenue from your app, please don’t try it as a SharePoint-Hosted app. You’ve got no private IP (i.e. someone will steal your code), and very poor revenue controls. If you want revenue, the SharePoint-Hosted path offers nothing but headaches and heartaches.

What’s Bad
Nothing’s perfect, right? That’s at least as true with application architectures as anywhere else. Here’s what I find most troubling—or maybe not—about Provider-Hosted apps:

  1. More expensive than SharePoint-Hosted Solutions…Maybe. I concede that a Provider-Hosted app is going to have higher operational costs than a SharePoint-Hosted app4. But if you consider the big picture of how SharePoint apps provide value, and what drives costs in application development (hint: developer productivity is almost always a huge factor), the picture improves. If you’ve got questions about that math for a specific project, you know where to find me.
  2. More complicated than SharePoint-Hosted Solutions…Maybe. You definitely have more moving pieces and operational support requirements. But in my opinion you simplify your architectural and ALM picture because you’ve regained the most productive and mature part of your dev team’s stack: the server.
  3. More up-front effort required. Once the farm and site collections are configured for apps you can crank out a hello-world App or App Part about 15 minutes after you install the Office Developer Tools extension. For most organizations, getting the provider infrastructure setup and configured will take two to four weeks, varying by IT overhead.
  4. Steep learning curve. This will vary based on current skill sets. Anyone who’s been a full-time SharePoint developer for the last several years will need a significant firmware upgrade. Refer back to my app dev timeline—full-time SharePoint devs like me have been creating solutions with a strange brew of platypus, tribal knowledge, and black magic. The Venn diagram of Farm Solution dev skills and SharePoint 2013 dev skills has significant non-intersects:
    The SharePoint Developer's Dilemma

    The SharePoint Developer’s Dilemma

  5. Missing tooling & rough edges. We experienced some higher-than-expected pain with managing user identity and the SharePoint context, especially when moving our server code to the Session-less Web API controllers. As of this writing, the community is rallying around this issue with some community-sourced solutions, including the ones featured in the Help Desk Application.
  6. They give up ground to Farm Solutions. There are still a number of areas, especially in Farm administration, where Full-Trust code is required. I expect to see and recommend solutions that wrapper these basic functions in Farm features and then expose them via custom APIs. Only the logic that requires Full-Trust code will be deployed directly to the Farm; all other logic is free to move to the new App Model.

Where It Fits
In the previous checklists for App Web and Host Web Apps, they were all inclusive: you needed to be able to answer “yes” to ALL of the questions before I’d recommend that model. Except for the last two questions, the following Provider-Hosted App checklist questions are independently qualifying: if you answer “yes” to ANY of the first seven, I’d strongly recommend a Provider-Hosted App. Why are the last two questions exceptions? They’re crucial organizational gut checks .

  1. Your Use Cases Exceed UX. If your app has concerns beyond user experience (business logic, dependencies on external services, its own lifecycle, etc.), the extra security, privacy, and productivity will make this your best (or only) option.
  2. You Need Private Logic. You just can’t get there with an app written in 100% client-side JavaScript.
  3. You Need App-Specific Security. Other than the Task & Time Entry app, I can’t remember the last time I worked on an app that didn’t need some kind of app-specific security. And as demonstrated in the second post of this series, the lack of private, tamper-resistant logic in JavaScript makes real security unattainable. But on the server you can lock features down all day long. Sometimes without even coding5.
  4. You Need Complex and/or App-Specific Data. If your app needs complex relational structures or large data sets, SharePoint lists will disappoint you pretty quickly. Add a server, and you have tremendous storage options to meet all your data needs.
  5. You Have Strict Availability Requirements. JavaScript running in a browser against an API that’s still a bit squishy is no place for a high-availability app. Configure up some geographically redundant, load-balanced servers or services, use message queueing for your cross-service communication, and you’ve moved a couple of orders of magnitude up the high-availability food chain.
  6. You Want To Leverage Server-Side Code. If you have existing server-side customizations or libraries that you want to leverage, you need a server to host them. This might seem obvious, but it’s worth calling out because it’s an extremely prevalent issue. In spite of Atwood’s Law, there’s a lot of high-value, server-only code in the world.
  7. You Need Agency Beyond A Browser. Many apps have concerns that can’t be reasonably transposed to the app user browser request context: lifecycle events, scheduled activities, state monitors, batch processes, long-running asynchronous tasks, compute-intensive processes, etc.
  8. You Have Tolerance For Additional Complexity. Gut check #1: if you choose the Provider-Hosted path, you will own the care and feeding of another server or service. It very well may be a value-add that pays for itself, but it’s still another moving part. You should fully consider the implications of this.
  9. You Have Time To Learn. Gut check #2: if you saw the Venn diagram above, and you or your team are not already in the distributed app cognoscenti, then you’re going to be playing catch-up. If you’re a long-time SharePoint developer, my advice is to lean into it. You proved yourself once with your platypus-husbandry-black-magic chops. This will be better, and at the end you’ll have two sets of very marketable skills instead of one.

“But I Don’t Want To Go To The Cloud…”
Okay, then here’s my advice: don’t go to the cloud. At least not until you’re ready. And if you’re never ready, that’s fine, too. What’s the worst that happens? Microsoft goes all-cloud after the next SharePoint release, 6, and in 2026—WAY too far into the future to speculate on effectively—you’ll lose all support for SharePoint 20167. You’ll have better options before then. Heck, you’ll have multiple generations of better options before then. Keep your investment on-premises for as long as you think it makes sense for you.

The truth is, I’ve been purposely quiet on the On-Premises vs. Cloud issue throughout this series because I don’t believe it matters for a discussion about app models. I don’t think it matters because regardless of where your SharePoint infrastructure is located, I’d strongly urge you to plan your move to the SharePoint 2013 App Models now. Not because they’re shiny and new, but because they’re better—legitimately, straight-up better—for many applications, even those confined to private networks.

Yes, Farm Solutions still have advantages at the edges. If your customization needs are light, Farm Solutions will get you there much quicker, especially for seasoned Farm Solutions developers. They may look odd and have poisonous claws, 8, but they’ll win those short-distance footraces. On the other end, if your app needs deep access into the SharePoint API, beyond what CSOM offers, Farm Solutions are the only way to get there. Between those edges lies significant territory where the 2013 App Models are competitive: apps with more than a handful of user stories that require customization or domain logic, but don’t need an all-access pass to the SharePoint API. I estimate that 50-75% of the apps I’ve worked on for SharePoint 2010 could have been written as Provider-Hosted Apps, and almost all of them would have been better for it. Your mileage may vary, but it’s worth serious evaluation.

Before I move off this topic, I want to say a few words in favor of the cloud:

  1. Your data is *very* safe in the cloud. I’ll bet you a doughnut your data is safer in Azure or AWS than on your network. Cloud providers run tighter ships than the vast majority of internal IT organizations. That’s not a shot at your IT pros; it’s a realistic assessment of economies of scale and the value of focusing on core competencies. They stake their paychecks on a spotless security record, and they’re investing in it in ways which you can’t compete 9. No disrespect intended.
  2. There’s plenty of value in cloud hybrids. Maybe you have a data sovereignty issue. Or maybe you’re in a business where there’s value in the traditional subpoena process. Fine—but don’t throw the baby out with the bath water. Are there parts of your business that don’t require that coverage? Consider moving those to the cloud. Have you thought about solutions that outsource processes to the cloud but leave your data in place? These things are possible, and a great consultant can help you navigate complicated issues like this (hint: we’d love to help).

Pro Tips
Yet again, most of the pro tips from the previous posts (here and here) can be carried over. But now we’ve got some new server-side considerations. Some of these will be platform-agnostic, but I’m working with the explicit assumption that most SharePoint developers are going to favor .NET technologies. That will bleed through everything that follows, especially in the examples and supporting arguments.

  1. Learn From Others. There have been a number of trailblazers in this area, and they have tremendous insights (and code!) to offer. Not to slight anyone, or to state the obvious if you’re a SharePoint veteran, but these are the folks I’ve leaned on most heavily: Kirk EvansScot Hillier, Andrew Connell, Bas Lijten.
  2. Don’t Suffer In Silence. SharePoint developers, as brothers and sisters bound by the sacred vows of platypus-husbandry-black-magic, have significant simpatico and camaraderie. If you hit a tough issue, head to SharePoint StackExchange or tweet-out at somebody. Tweet at me (@seansageek) if you have to. If I haven’t covered it already in this series, I probably won’t know the answer, but I might know someone else here at ThreeWill or elsewhere in the community who will.
  3. Consider PluralSight. I can’t speak to all learning styles, but PluralSight fits mine very well. And for SharePoint developers committing to cross the chasm and join the cool kids, PluralSight has your back. Plus, if you want to maintain your SharePoint edge, Andrew Connell has hours of great content there, particularly for SharePoint 2013 workflow.
  4. Consider Dependency Injection and Inversion of Control. It’ll feel funny the first three or four times you do it, but using DI and IoC gives your app tremendous freedom and flexibility. And if DI and IoC are old hat to you, take a look at what IoC ninja Matt Honeycutt has done with StructureMap in his Build Your Own Application Framework with ASP.NET MVC PluralSight course. Yowza, that’s strong juju!
  5. Consider No-SQL Data Stores. If you’ve been in a SharePoint foxhole for years, No-SQL data stores like Mongo and Couch are the real deal at this point. If you need simple object persistence, check here first.
  6. Consider an ORM. If you checked your No-SQL options and couldn’t commit to that route, at least consider using an ORM like the Entity Framework or NHiberate. I’ve used both and found they’ve added tremendous value. Don’t spend time writing your own DAL if you don’t have to.
  7. Queue Activities for High Availability. If high-availability and recoverability is a concern, there are several good queueing options these days. Rabbit and Azure Service Bus Queues come to mind.
  8. Automate Your Testing. I’m not a TDD purist, but I am an automated testing evangelist. It takes time and discipline, but for most projects it pays huge dividends. Visual Studio’s own testing tools have made tremendous strides in the last several versions, and they’d get my nod as of now, especially if you’re a testing n00b.

Next Up: Conclusion & Next Steps
Have you already had your fill? Great! If not, I’ve got one last post in this series to top you off. The final course is dessert: I’ll draw some final conclusions about the SharePoint 2013 App Model, and offer you something for the road: a scorecard to help guide your thinking about which solution architecture offers the best fit for your applications.

Has this post given you heart burn? Let me hear about it! There’s always an open chair next to me in the comments or on Twitter (@seansageek).


Notes

  1. See my technology timeline from the first post for my take on how SharePoint has historically struggled to keep up.
  2. Single-Page Application
  3. These include customizations to the standard the SharePointContext and TokenHelper classes provided by Microsoft in the Provider Hosted App solution template. These customizations are necessary to extend access to the SharePointContext to Web API Controllers. This code owes a great technical debt to Bas Lijten–you can read more at his excellent blog on the subject here.
  4. Unless your needs are purely developmental, investigational or fairly trivial, in which case you might be able to skate by with a developer-oriented freebie from a friendly hosting provider.
  5. With ASP.NET MVC and Web API controllers, security can be as simple as marking methods with an attribute or two.
  6. There are exactly zero real indications that this will happen
  7. I keep hearing people say “SharePoint 2015”, but I’ve observed Microsoft release dates for a long time, and 2015 sounds stretch-y to me. It’s a judgment call.
  8. Male platypuses have poisonous claws. Yes, I’m running this metaphor into the ground.
  9. You can find the impressive details about Azure’s security posture here, and the even more impressive list of security certifications it holds here.


Related Posts

Sean HesterSharePoint 2013 App Models Considered – Part 4