Share and Enjoy !

Good afternoon folks. John Underwood here welcoming you to another webinar. I’m coming to you live from the ThreeWill offices in Alpharetta, Georgia, just north of Atlanta. I hope you’re having a pleasant day wherever you might be across the country or even in other countries.

A few quick introductory notes and then we’ll get started. First up, for those of you who’ve not attended one of our webinars before, my name is John Underwood. I hold the position of Technical Evangelist and ThreeWill. You can see a couple of contact points for me there. If you have follow-up questions after the event, you can reach me by email.

Also a couple of Twitter feeds that I participate in if you’re into using Twitter. I think you’ll see some pretty interesting and fun things come out there. One other thing, both for the sake of maybe some of your friends that didn’t get to join us today, or if you do have to leave us early, the video replay of this will be available at MIA website at the end of the event so please be sure and take advantage of that.

Today’s presentation’s a little different than some of my others in that I have to acknowledge another person. Generally when I bring you a webinar, it is content that I’ve created from scratch and had the good fortune to research, but in this case I’m actually covering material that was harvested and put together by a co-worker of mine named Sean Hester.

I’ve had the good fortune of working with Sean at a couple of jobs over the years and he’s just a really bright guy when it comes to researching and finding this, co what you’re seeing today is a derivation of a presentation he recently did at SharePoint Saturday. Again, all kudos to Sean there and some contact points for him if you’d like to follow him on Twitter as well or reach out to him with questions.

With that, let’s talk just a little bit about who’s attending today and what I hope to convey to you. Generally, my webinar audiences fall into 3 categories. The first of those being users, business leaders, IT management, people who aren’t programmers. For you, what I hope you get out of this webinar today is that if you do SharePoint customizations, you have some decisions to make in the near future.

While you will have to make those decisions, with the input of technical people, I think it’s important for you to understand the implications of what this will mean to you in your environment.

If you find yourself in an administrative role, either for SharePoint or other server products in your company, then the choices that your developers and you users and business leaders make about applications and customizations in SharePoint, they’re going to influence what happens to your servers.

I don’t think it’s a negative influence, but it is something that’s going to be important for you to know about and understand. Then most of all developers, this webinar really is going to talk about how if you’re a SharePoint developer, or you do SharePoint customizations, your world is changing in a pretty significant way.

We’ll talk about those changes and maybe some good opportunities that will come out of them. At the very least, what you’re going to see is that the choices of how we build SharePoint applications have changed significantly as are the tools that we’re going to use to build those apps. With that, here are the topics that I’m going to cover for you today.

First us, I’m going to kind of draw a line in the sand with a bold statement about what I, and collectively we, think here at ThreeWill about your application architecture choices when it comes to building SharePoint apps on SharePoint 2013.

Then from there we’re going to take a look at an evolutionary timeline of what it means to be a SharePoint developer. It’s not so much that I want to bore you with historical facts, but rather I kind of want to set up how we got to where we are and how this change that we’re facing, I believe, is mostly a positive change.

Then from there, we’re going to look at the various app models and obviously by the time we do that, I’m already going to have made a statement about which one we kind of collectively think is the best path. Having said that, we will look at both of the models and try to compare and contrast some of their pros and their cons and their intended usage.

Then finally some conclusions about what we’ve learned and covered in the webinar and how, perhaps, we can take that back to our companies and do something meaningful with it. When it comes to making a bold statement, again, you’ve got to be able to back it up with some facts, and that’s what I hope to be able to do for you over the next 45 minutes to an hour.

If you follow the Microsoft line when it comes to building SharePoint apps, in particular customized bits of code that are going to run inside SharePoint in some fashion. Basically Microsoft says that you have 2 models. The SharePoint-hosted model and the provider-hosted model. Now, quick aside, those of you who’ve kind of been on the SharePoint 13 train a little longer, may also remember something called AutoHosted.

Just in case you don’t know, AutoHosted is no longer available. It was put out as a preview and Microsoft decided, for whatever reason, to pull it back. If you’re not familiar with that, just understand that it was a variation on provider-hosted. I have no doubt that some of you in then environment, or excuse me, in the audience have a clear understanding of the differences and the pros and the cons of SharePoint and Provider-hosted.

If you don’t, don’t worry. I’m going to lay the ground work for that before we make a decision. However, what I think you’re going to see by the time we’re done today is that you really don’t have 2 choices, you really only have 1 choice, and that is you’re going to have a provider-hosted app and you just got to decide where you’re going to host it.

We’ll talk about that as well. A lot of times when I present I like to save the punch line for the end, I’m giving you the punch line at the beginning here. Really feel strongly that the provider-hosted model is the one that you’re going to be able to build real “apps” on. Then we’re going to talk about why and how over the next few moments.

This analogy that I’m going to lay on you, courtesy of Mr. Hester may seem a little out there, but I think it’s a perfect explanation so consider the strangeness of the animal we know as the platypus. A duck-billed, web-footed, egg-laying, venomous mammal. Almost an evolutionary freak, if you will, stuck in time somewhere back in the centuries and the eons.

How does that relate to us as SharePoint developers? You can see on the next slide, I’ve got a little timeline here that just kind of shows you the history of SharePoint and then the timeline of programming innovations along that line. I’m not going to bore you by reading every single point to you. What I would just offer is to look at a couple of things.

Number 1, if you look at the range to 2001 and 2003, that’s really the point at which it became viable to call yourself a “SharePoint developer.” You could actually build things like custom web parts and custom forms to customize the environment.

Then you can see over the time frame to 2007 and 2010, SharePoint obviously progressed and we would have to say that from the developer prospective, it got a lot friendlier, particularly upon the release of SharePoint 2010 where we could legitimately open visual studio and build a SharePoint project and not have to have a lot of magic in order to make it work.

Here, however, is the challenge that we have faced up to this moment as SharePoint developers. That is we’re based on a technology that is essentially nearly 15 years old. SharePoint’s fundamental web technologies up through 2010 were really based on the ASP.NET 1.x, and yes I know they changed framework versions as they went along, but this whole idea of building web forms and using server controls.

Serpa 2002, that was an awesome, innovative model, and it was something we were very happy to have. If you look at where we are today, there are a lot of things that have come along since then that for all practical purposes, as SharePoint traditional developers, we really couldn’t take advantage of that.

If you think of all of the parts that make up a modern web application, a responsive user interface, the use of the latest versions of the HTML, being able to take advantage of some of the more innovative JavaScript libraries that are out there, such as Angular or Backbone, none of those were really on the palate for us.

There are clever people who figured out how to kind of wedge these into the 2010 model, but the truth is, up until the moment that we get this app model in 2013, those things are really not on the table. What does that mean to all of us, both developer and non-developer? The world has just changed radically when it comes to doing SharePoint development.

Yes, we’re going to have some new challenges. We’re going to have to learn some new technologies, but on the positive side, we’re going to have a lost of opportunities to write applications in a way that just simply wasn’t practical in the old model.

If you’re a business leader, here’s another one. You have a larger pool of developers to choose from now. I can think about our own experiences, here at ThreeWill, where how many times we’ve said, “We need to hire a SharePoint developer.”

When you say you need to hire a SharePoint developer, what you’re really doing is saying, “I need to hire someone from a fairly small, fairly specialized pool” whereas with these new app models that we have, we can now more easily integrate developers that know a lot about JavaScript programming or a lot about DotNet programming, and help them come in and be productive in the SharePoint world.

Then just kind of in a more humorous way, what we’re really doing is moving up on the evolutionary scale. We now have a world where we can take advantage of all of the latest innovations when it comes to web-based programming.

If you think about one of the primary drivers in customizing SharePoint, and that is to give it a more pleasing user experience, then the fact that we can now take advantage of a lot of browser-based technologies that innovate on UI, that is really a big thing.

If you are a developer, if you’re already onboard with these changes, that’s great. If not, this is kind of a wake-up call. Your career is changing as a developer and you need to take advantage of the opportunity to expand yourself and to expand the opportunities of your company.

With that, I want to spend a few moment now doing 2 things. Number 1 I’m going to explain the 2 app models that you have available to you, SharePoint-hosted versus provider-hosted. I’m going to try to give a little primmer on what each one of them represents because, while I’m sure some of you know that, a few of you may not yet have that knowledge.

It will not only help you understand your choices, it will also help you understand why we’ve drawn some of the conclusions that we’ve drawn about which ones you might want to use. Let’s start with the SharePoint-hosted app model. Before I even get into any bullet points, one sees the name SharePoint-hosted and you think, “Okay, Well it must be hosted in SharePoint” and with the risk of being over-simplistic, that’s really what it is about.

At some level, the SharePoint-hosted model is desirable because it doesn’t bring any other server elements into play. Whatever it is you’re building, whatever it is you’re doing, ultimately it’s going to get deployed to SharePoint and then it’s going to run in some fashion.

What is it that you’re going to be writing when you write a SharePoint-hosted app? You’re really going to be writing client-side or browser-based technologies. You’re going to be writing Markup, you’re going to be writing JavaScript. You’re not really going to be doing anything with the server side code.

Now, giving JavaScript the credit that it is due, it has certainly evolved in some amazing ways over the past few years. There are a lot of innovative thing that you can do with it. I think what you’re going to find, as we go through this little journey, is that having the browser as your exclusive runtime engine and JavaScript as the language within that is going to pose some limitations that we may or may not be happy with. More to come on that as we go along.

Another thing to think about when you write a SharePoint-hosted app model, the presumption in almost all cases is that if you’re writing a SharePoint app, you’re writing it to manipulate list or libraries. It could be that you’ve built an app where you’re trying to track invoices or expenses or maybe even resumes. Generally it’s a combination of SharePoint building blocks such as lists and workflows and libraries. Then your code is acting as an integrating agent around that.

Given that, the way you’re going to do customizations now are a bit different. When we build an app we really have 2 websites that come into play. The first is called the host web. That is the site that is actually hosting the application. Then we have the app web, and for lack of a better way of explaining it, you can really think about the app web as being a special kind of sub-web or sub-site that lives under the host web.

Even if you say, “We’re using SharePoint- hosted, and we know what we’re getting into”, you still have to make a choice about where you’re going to store your data, either in the app web or in the host web. Let’s talk a little bit about what those choices are and why you might choose one over the other.

The first opportunity, or the first alternative that I would put out there is storing your lists in the host web. You can almost think about your app web is running and it’s calling up to the website that’s holding the data, and it’s going to interact with it there.

There are some distinct challenges in that approach. One of the first one is that you cannot declaratively create your lists. Excuse me. Those of you that are used to writing camel for provisioning a list, be it a task list, or an announcement list, or some kind of custom type, you literally can’t do that in this case.

Then how are those dependent lists going to get created? Essentially you have 1 of 2 choices. You can programmatically create them, although that’s going to be very difficult, and the reason it’s going to be difficult, when you think about it, a natural place to allocate a list would be when your app gets installed.

Unfortunately, SharePoint-hosted apps do not have an event handler that fires when your app gets installed, and the reason for that is you don’t have any server code. In effect, if you were going to programmatically create those lists in the host web, what you’d have to do is every time your app landed on its homepage, you’d have to do a quick check to see if they were there. If they weren’t there, creating them on the fly.

There’s a lot of entanglements with that, not the least of which the user that’s doing this action, probably doesn’t have that level of permission in the host web. Bottom line is you’re not going to be able to easily, programmatically create them.

What was the second option? The second option is you just go in and manually create them. I can tell you that on the app I’m going to demonstrate for you today, that’s precisely what we had to do. We have a little readme that says, “When you install this app, you’ve got to go up to the host web, you’ve got to create a list, and it’s got to look just like this.

That’s kind of a kludgy, sort of duct taped way to do it, but it really is your only other alternative. Another big challenge for storing the lists in the host web, and that is, by definition, if the users have permissions to interact with that list, then they’re going to be able to actually navigate to that list in the UI and manipulate it.

You think about your app assuming certain dependencies on how data gets manipulated and updated. It’s entirely possible for the user to circumvent that, navigate directly into the list and change it accordingly. Imagine, if you will, writing an app where you have a database and the database is surfaced to the user so that they can interact with it directly and bypass your app.

That’s essentially what we’re saying here. Yes, there are some UI tricks that you can do to kind of partially hide those, but in the end you’re just running this risk that the users would change the data in such a way that would be inconsistent or confusing to your application.

Your other alternative is to store the lists in the app web and, in fact, a lot of what comes out of Microsoft, in terms of sample code and so on, kind of presumes that this is what you’re going to do. On the strong side of this, it has a declarative creation model. You can write camel just like you did in the past, and you can allocate those lists as the app is being installed.

There’s not any kind of contingency code that you have to write to create the list. You don’t have to manually do anything. You just deploy the app and the lists get created and everybody’s happy. That is a huge upside. Not only that, it’s very difficult for a user to interactively navigate to such a list and manipulate it.

I don’t want to say impossible, because there are trap doors they can slip through, but by and large it’s much less likely that a user would directly manipulate a list that had been stored in the app web. That’s a big positive.

On the negative side, well there’s a couple of big negatives. Probably the biggest one that we’ve encountered in some of our experiments, there is no security model. This concept that you’re used to in SharePoint of being able to create groups and add users to those groups and then grant permissions in such a way so that certain groups may or may not get to a list, that’s not even possible in an app web.

By definition, if a user installs an app, then they’re going to have access to all the lists in that app. There’s really nothing that you can do about that. Here’s another big one. If you store the data in the app web, when you remove the apps and one decided to uninstall it, that’s it. The data is gone. You’ve lost that data, and if you “reinstall” the app, you’re kind of starting over fresh.

We can say that’s an implied positive of putting your list in the host web. At some level if you delete the app, the data is still available in the host. You would have the burden of perhaps going and cleaning that up at some point in the future, but at least of somebody kind of trivially deleted an app, they wouldn’t wind up nuking all your data.

That’s a lot of verbiage. Let’s see if we can do this in picture form. Some of you probably do a little better with pictures. You can see the outer gray block there that represents SharePoint. In this discussion, this could be an on-premises SharePoint farm that’s running in your company, or it could be SharePoint online by an Microsoft 365.

What you see here are a couple of moving parts. First of all, within the form itself, we have the host web where the app got installed, and then underneath that the app web where the code would actually be interacting with. Then you’ll notice from the dashed arrows that are moving right to left, that essentially my app can interact both with artifacts in the app web, and artifacts in the host web via the API into the app web.

The one thing that we have to be aware of on that application programming interface, is that getting the things in the app web is incredibly easy and straight forward. Getting things in the host web is a bit more complicated. If you’re familiar with the concept of cross-site scripting and being able to call from one domain to another, you probably already know what I’m hinting at. If not, just understand that it’s not as easy as just dialing up a URL and calling into that host web.

We have some plumbing that we have to go through and that plumbing is pretty particular and sometimes brittle. We actually have some real world experience where Microsoft made a change to that plumbing unannounced and it actually introduced a bug into one of our applications.

Now, notice over to the right, the little white block. All of your code is running in the browser. To put it another way, your browser is your runtime engine. Any logic, any [inaudible 00:21:03] manipulation is all going to happen there, and then as you need to retrieve and store data, you’re essentially going to be calling back into your app web’s API and then doing whatever manipulations you need to make.

What’s good and bad about this in kind of a diagram fashion, well one thing that’s good about this model is that unlike what we used to do in SharePoint 2010, this is, in fact, Cloud friendly. When you write an app using the SharePoint-hosted app model, you can deploy both to a local farm and to SharePoint online.

We also have this benefit that is it SharePoint only, so there’s no other dependencies, there’s no other servers that we have to worry about. You just take your artifacts, you deploy them to SharePoint and your job is done. Certainly, from an administrative, a production support point of view, it’s a very simple, very easy deployment model and a lot of people are going to like that.

Another thing that there is to like about this model, if you notice our little symbol there at the bottom, we’re not stuck in the Platypus programming model. We’re riding client-side technologies, so we can take advantage of all of the latest JavaScript libraries. Assuming that the browser supports it, we can HTML 5. We have lots of very, very interesting things that we can do there.

While it does have some problems that we’re going to have to deal with, on the user experience side, a SharePoint-hosted app model has a lot of opportunity to really bring us up to 2014 in terms of what our users expect in the user interface.

There has to be some negatives, and I think I’ve outlined many of these. Number 1, there’s no middle tier so whatever kind of logic you’re used to running at the server that you want to hide from prying eyes, you can’t really do that here.

Yes, I know there are tools out there that will midify and obfuscate your code, but in the end, your intellectual property’s being pushed out to the browser. There are stubborn people out there who can ultimately figure out how to get that code and maybe even co-opt it for their own purposes.

To me, particularly from a revenue point of view, if you’re in the role of an application developer that sells software commercially, that’s kind of a non-starter. This whole notion that your intellectual property’s just out there and available.

Some other things, just the integration that we have here is pretty brittle. I gave you an example of that where Microsoft made a trivial change on their side, and all of a sudden your code is broken. Because you’re really beholden completely to SharePoint for everything you do, you’re really sort of at the mercy of SharePoint when it comes to your integration.

Data limitations come in several forms. The obvious of which is the discussion we had about lists and where you’re going to store data. Not only do you have those issues, you have already well-known issues about SharePoint in terms of large lists and how many thousands of rows you can practically store before you begin to get problems.

Then one here at the bottom that is worth noting. As excited as we might be about these new client-side technologies, unless you’ve got a staff of developers that have already been doing this kind of work, in the short term there’s going to be some kind of reduced developer productivity. They’re going to have to learn JavaScript, they’re going to have to learn one or more fairly large libraries. They’re also going to have to get used to the daily cycle of code, debug, code, debug, using perhaps a new set of tools.

These are all kind of things you need to think about when it comes to using this model. I’ve kind of been hinting at some kind of show-stopper here that would make me say, “Wow, I never want to use that model” so that’s what I’d like to show you now. I want to take a quick look at an app that is using the SharePoint-hosted model and hopefully kind of demonstrate why that might be problematic for us.

What you’re looking at on the screen here is running in Microsoft 365. It is a teen site, and prior to our getting together I went in and installed a sample app that we’ve written here in our company called the Absence and Vacation Management app.

You can see I’m logged in as a fictitious user named Alex Darrow, and in this case, Alex is just a member of this site. He does not have an administrative role. I’ll go and click on the Absence and Vacation app. You’ll see as I go along here that there are really 2 views to this app. One view is for a normal user.

For that user they can go in and look at the calendar requests. They can go look at our policies for absence and vacation, and then they can check on the status of their pending or approved requests.

Let’s say in the case of Alex, he decides he wants to submit a new request. He’s going to take a vacation some time this fall with his family. He’ll go out and pick some dates here, and again the dates are insignificant, we just need to have some sample data. He wants to have a getaway, so that’s really nice.

We’re going to click ‘save’ and then at some level now, Alex has submitted a request and it’ll be up to a manager to come along and actually approve or reject that request. The way that we handle security here, remember we have no security inside of the app web, so what we’ve done is actually created a group in the host web and used that to monitor security, and then in our code, we just check the current user to see if they belong to the manager’s group or not.

Here’s what I’m going to do, and this is not all that far-fetched. I’m going to go up here and open my developer tools, and then I’m going to go into a file called ‘app.js’. For this example, this is where my application logic lives, and you can see I’ve got a break point in here that is set at the end of the logic where we check to see if this person is a manager.

Essentially what we’re doing is looking up on this ABR manager’s group to see if they are or are not in there. You’ll notice I’ve set a break point on it. What I’ll do now is refresh the page and then once my break point triggers, I’m going to float my mouse over it, I’m going to go down to the little pop-up window and double click on the word ‘faults’, and I’m going to change it to ‘true’.

This is all happening in the browser. It’s not like I’m some super administrator or anything. I just basically sniffed out where I needed to change the value of a variable, and now if I click ‘continue’, look at my user interface. Now Alex is a manager, and in fact, now Alex can go over to the manager’s page and look at all of the different things that are going on here.

He’s not even supposed to be able to see this. Not only that, he can now go to the request page and he can approve his own request. By simply changing the value in a [inaudible 00:28:08], we totally changed the security profile of how this app is behaving.

That kind of reinforces what we’ve already talked about. Your logic is out there, and it’s not like somebody has to steal it, and modify it, and post it back to the server, they can manipulate that logic in real time using the debugging tools that are built into pretty much every modern browser.

When you see a demo like that, at least when I see it, here’s the first thing I ask, “Why on earth would I ever want to use that model?” I don’t want to just say that you would never use the model, but I think that it is a very narrowly defined set of circumstances under which you would use it.

One reason that you would use it, whatever it is you are trying to accomplish, it’s all related to the user experience. You’re just trying to make it easier for a user to do something that they could do with a standard UI. Let me give you a perfect example. For the projects that we run here at ThreeWill, we actually keep all of our project-related data inside of a SharePoint site. Makes sense, we’re a SharePoint company, but there is a thing that a developer has to do to map out their tasks and their time that requires them to simultaneously update 3 or 4 lists.

Under our old model, that was a pretty laborious thing to do. In fact, it was funny, you could almost figure out when someone was doing it by walking by their desk, and you would see that they would have 3 tabs open on their browser to 3 different lists on the same site, and they’re switching back and forth and copying and pasting.

Instead what we did is wrote a SharePoint … Excuse me. … a SharePoint-hosted app that allows us to go to one page to see all those lists and to manipulate them simultaneously. We’re not trying to impose any app logic, we’re not trying to do any crazy calculation, we’re just making it easier for someone to accomplish a task.

Obviously, in that case, there isn’t any logic, it’s just UI manipulation so we don’t have to worry about someone “stealing’ it. Again, there’s not a security element here. We’re just trying to make the UI easier to use. Our data needs are pretty simple. Everything that we’re doing are stored in lists that are in the host web. If the developer wanted to, they could navigate directly to that list and manipulate it directly.

They just use the app as an easier way to accomplish that. All right, so now that we’ve taken our tour of SharePoint-hosted apps, lets begin looking at provider-hosted apps. What is the biggest or most profound difference between the 2 models? When you build a provider-hosted app, it is a mix of both server side and browser based logic.

What we really hope that we get there is the best of both worlds. Things that should belong in a server code that needs to perform well, that has higher security requirements, that has high availability requirements, great. We can write all of that as server logic and we can write it in a set of tools that are probably more familiar to us.

Then for the things that should be in the browser, markup and user interface manipulation, great. We can still take advantage of all of the crunchy goodness of the latest that JavaScript and other browser-based technologies have to offer. Here’s another thing about provider-hosted apps that doesn’t necessarily shine through initially, but the more you think about it, the more opportunity you see.

That is, when we talked about where you store your data, in a provider-hosted app, you can store it in the host web, you could store it in the app web, or you could store it in any data storage engine that you like. It almost changes your perspective of a SharePoint app where instead of being in this world where SharePoint is the center of the universe and you can’t really reach anything outside of it, now you’ve got an app that could be consuming resources from a database server in your company, from Azure in the Cloud, and at the same time consuming SharePoint as though it is a service.

That’s a pretty radical thing because some of our traditional SharePoint barriers around data capacity, number of items in a list, now if I know that I’m going to have some things that are trivial and some things that are going to be very large, I can put those very large things in another data storage engine but still consume the things that I like about SharePoint.

Another thing that is truly important about provider-hosted apps and that is better event model. In particular, there are a lot of legitimate things that you might programmatically need to do when your app is installed or uninstalled. The most obvious example is the little example I talked about a moment ago where I needed to have a list in my host web that hosted information about my managers.

If I’m writing a provider-hosted app, when the app gets installed, I can programmatically allocate that list and even populate it with data. Conversely, if I want to do a full cleanup, when my app is uninstalled, I can reach up into the host web and delete that data.

I could also do that with any other data storage engine. SQL Server, whatever it might be. There are other events that you are going to hear about, but the fact that you have an app installed and uninstalled event on a provider-hosted app, and you don’t have that on a SharePoint-hosted app, that’s a pretty important point.

Then looking a little more at storing data in a provider-hosted app. As before, we can store our lists in the host web, and as I kind of hinted at a moment ago, the one big difference here is just now that we can programmatically create those and clean those up based on app events. Otherwise, you’ve got essentially the same pros and cons that you had before.

Likewise, you can store your lists in an app web and the experience there is the same. You can declaratively create them. They do not have any security associated with them, and when you delete the app, they go away. Then, this third option, and I’m going to tell you for some of our customers, it’s kind of becoming the first option, and that is we really want to store our data somewhere else. Imagine as an example, you wrote an application that had to track an enormous amount of employee data and as [inaudible 00:34:39] it also needed to track some documents for those data.

It’s really easy to see a model where you would put your verbose employee data in a SQL server database, but then store the supporting documentation in Sheer Point and take advantage of libraries and workflows and all of the things that go around that.

If you’re used to working in this box of a Sheer Point developer, now that world’s kind of opened up, and you’re writing applications now and those applications launch from Sheer Point and use Sheer Point, but they’re not really limited to Sheer Point in their scope.

Once again, for those of you that kind of prefer the picture view as opposed to the written word, what you see here now is the provider-hosted model. If you look to the far left of the diagram, in the gray box, once again, we’re talking about SharePoint. Once again we’re talking about being on premises-friendly, as well as, Microsoft 365 friendly.

In this case, you still have the host web, you still have the app web. What’s probably different here is that you may have little or nothing in the app web. It may just be a toe-hold that lets you get in to SharePoint and launch the app. Then if you look to the right, the next diagram, the one that says, “Provider”, essentially this is the provider-hosted portion of your app.

To put it another way, this is the server logic that’s going to carry out your business plan. It’s going to read and write data from SQL databases or ques or any other storage mechanism. Then it’s going to deliver the client-side payload out to the browser that allows the user to interact with the app.

In effect, your user gets a set of markup, the begin to interact with it. The browser is then making calls to your provider-hosted app and it, on behalf of  the user and the app will consume resources either inside of SharePoint, or any other storage engine that we like.

There’s really not much that’s out of bounds here. Virtually everything that one would have available to them in SharePoint, can be programmatically manipulated in this way. One other thing that I want to point out, and this is a pretty important one. If you notice inside of the provider app block, there’s a little bullet point there that says, CSOM, Client Side Object Model is what that stands for.

What you need to understand is that when we write our apps this way, the programming model that we use is a little richer, and has more capabilities when it’s running in the serve as C-sharp as opposed to the version of this that runs in the browser as JavaScript.

To put that in simpler English, there are things that you can easily accomplish in C-sharp, in this context, that you just couldn’t as easily accomplish using JavaScript in our previous model. In terms of the volume of change, this diagram is accurate, but I’m not sure it conveys the message fully of just wow, all of these doors that used to be closed to us are now open.

Again, if we kind of look at our pros and cons here, there’s a lot to like here. We have a full middle tier, and all of the things that we might need out of that, data storage and retrieval, security, transactionality, all of that.

Because we can take advantage of all of the latest browser technologies, we can use the best that the web has to offer. We can also use the best that Microsoft has to offer. Again, DotNet has gone through several significant releases and added some great capabilities over the last 13 years. Now as SharePoint developers, we can take advantage of all of that.

Another thing that we have here, when it comes to our provider-hosted web and the corresponding services, we can have all of the performance controls that we want. Whatever metering and so on. We wouldn’t have those things in kind of SharePoint. We have design choices about what sort of patterns we want to use, such as MVC.

Other things about that, we have revenue options. Again, if I’m building an app and trying to sell it, I don’t want to push my intellectual property out to a browser so that anyone in the world can see it. In this model, it’s compiled and it’s behind a safe wall and I don’t have to worry about it.

Another thing at the bottom, and I think this is another huge one, because of the tools and techniques that we’re using in this model, we have a much better support for an application lifetime lifecycle management. Doing that in JavaScript is really hard, but having a full-fledged ALM for build management, for repeatable testing, for predictable deployment. It’s more like a “real software app” where you have known, repeatable procedures for carrying out those kinds of things.

I wouldn’t be honest if I didn’t put out some kind of con. I do have to acknowledge that, once again, there is going to be a learning curve for your developers. The best circumstance is that in addition to being Sheer Point developers, your developers have already worked a lot with DotNet, and browser-based technologies, and they’re kind of up on the current state of web programming. Again, the good news is that if they’re not, for those that already know how to program Sheer Point, a lot of what they’re going to know is translatable.

For those that don’t know how to program Sheer Point, they can bring other skills that they do have on the Microsoft and the WebStack and easily add the Sheer Point capabilities. It’s a little bit of short-term pain, but it’s some gain in the long term.

Let me quickly show you a provider-hosted app in action. I’ve navigated to a different site now. This is the demo app that was built to back up what we did for Sheer Point Saturday, the original presentation of this information. Some things that you’ll want to note. First up, you can see over here in my recent list, that there are actually some lists in this particular site. This is an example of storing data in this host web. In fact, those lists got created when the app got installed.

It actually had the logic inside to say, “Okay, this list don’t exist, let me go out and create them in a certain fashion.’ Then once it’s created those lists, if I click on the link that takes me to the actual demonstration application, it’s not any different that what we would have experienced with a Sheer Point-hosted app.

You still have full control of the UI. You still have the ability to take advantage of whatever JavaScript libraries you’d like. You still have the ability to have a completely responsive app that will scale from the size of a handheld device all the way up to a full browser window.

Not only that, whatever tricks I might do about switching myself from being a manager to being a non-manager back and forth, none of that is going to happen here. If I were to fire up the debugger, I might be able to inject some kind of weird data into the  stream, but ultimately I’m going to have hardened logic back at the server that’s going to kick out anything that doesn’t make total sense.

It really is the best of both worlds. Here’s the thing that you’ve got to notice. When we were on the Sheer Point site, you can see this URL that I’m at,, but when I go into the app, I’ve now navigated to a completely different place.

Really what’s happening here is we just had a toehold in SharePoint that allowed us to navigate here. Once we get here, we’re really running the web app in the context of a completely different server, and then our server logic is just making calls into SharePoint on our behalf. Again, it’s a new world, and it’s going to take some learning, but I think what you see is that this is the sweet spot where you get the best balance of risk and reward. Instead of saying, “Why would anyone use this?” I’ll just put it bluntly. Why you want to use this. Why you would use this.

Number 1. You’ve got logic beyond just doing user interface manipulation. You need to write a “real app” that can do real things. You need logic that’s safe, and private, and can’t be stolen, and can’t be manipulated. You need app-specific security. In the example that I just showed you, all of those libraries, all those lists that are in the host web, are secured using the exact same mechanism that we’ve already used.

I don’t have to roll my own and come up with this totally new way of doing things. From the app, it’s not going to let a user manipulate a list if that user doesn’t have permissions to the list. Not only that, in the rare case where I need an app to be able to do something on behalf of the user, where the user doesn’t already have permissions, we have these things called app-specific permissions. Again, it is the absolute best when it comes to not having to roll your own security mechanism.

You have complex data needs, you have app-specific data needs, you need to be able to integrate with other data sources. This is just going to give you a lot more options than what you would have in a SharePoint-hosted and certainly, more than we had in our traditional farm solution.

Availability requirements. Essentially, you’re going to be limited only in the reliability of the server you deploy to. If you’ve got to have strict uptime requirements, you can pay the extra money to deploy that into a high availability environment. Either one that you’ve set up yourself, or one that you’re purchasing from a third party.

Then being able to leverage server-side code, I will admit, I definitely have a bias toward server-side code. It’s just what I have the most experience with and what I feel more comfortable with. Regardless of ones biases, the truth is there are certain kinds of things that should be done at the server, particularly things that are processor-intensive, things that need to be shared across many different users.

Then you need a runtime engine that’s bigger than the browser. That is definitely a reason that you would use the provider-hosted model. We talked about data capacity not being limited by the arbitrary number of rows that one can put in SharePoint. If you’re really talking about needing to manipulate 30 million rows, there are other data storage engines that are going to do a lot better at that.

Just as kind of a fly-by here, I’ve put together this app model scorecard based on some data from Shawn. The numbers here are somewhat subjective, I will admit that, but there are some trends that you would want to spot. Number 1, don’t forget that farm solutions haven’t gone away. If you are an old time SharePoint developer, and you’re used to writing those, at least for the short-term, you can still write them, and you can still take advantage of everything that you ever did there.

The problem there is really kind of two-fold. Number 1, that means no Cloud support, it’s on premises only. Number 2, I think Microsoft has kind of shown their intention that while they’ve not announced a date that farm solutions will go away, it’s obvious that their lifetime is not infinite.

There’s going to come a point where there’ll be little or not support for those anymore, if you read the tea leaves. Some other trends to point out here, if you go to SharePoint or provider-hosted, there’s a learning curve.

Say that the provider-hosted model has a better learning curve only because some of the server logic you used to write as a farm solution programmer, is going to look very similar, in terms of server logic for provider-hosted.

If you’re not a JavaScript UI master, then you’re going to have some things to learn there. Then, really the biggest deal-breaker or show-stopper, the SharePoint-hosted environment is impossible to secure in a meaningful way. You really have to be talking about the kind of app where you’re not trying to enforce security on users, you’re just trying to give them a more convenient way to manipulate data via the web browser.

Let’s look at some conclusions here, and then I’ll send you on your way for the day. One thing you’ve got to do if you’re a developer, you’ve got to embrace change. Even the most open-minded among us can feel a little bit intimidated when we find that all of a sudden things are changing. I honestly believe this, and I’ve been coding now for almost 30 years. This is a positive change. There are so many things that we could now do with SharePoint and integrating it with other apps that just really wasn’t practical given the models that we used to use.

Another thing that you’ve got to do if you’re a developer, not only do you have to embrace the change, but you’ve got some specific things that you need to work on. If you’re not already comfortable with JavaScript, you need to learn JavaScript. You need to work on that right now.

You also, once you begin to learn JavaScript, need to pick some of the more common libraries out there, and begin to familiarize yourself with them. There’s way too many for me to mention, but pick one. Even if you don’t wind up using that one, just the experience working with it will teach you some patterns about how things are done in JavaScript.

I know for us here at ThreeWill, we’ve looked at Knockout, we’ve looked at Angular, we’ve looked at a lot of different things. That’s a journey that you want to begin. Another thing that I didn’t specifically show or talk about in the webinar, but you need to begin to learn about it as a developer, and that is [inaudible 00:48:15]. Think about how I jumped from server to server a moment ago and I did that seamlessly with one identity. Being able to authenticate, and authorize, and identify users, [inaudible 00:48:29] is the way that’s going to happen. While that is a non-trivial topic, it’s something that you’re going to want to have in your tool belt.

If we’re going to use SharePoint-hosted at all, we’re really only going to use it for UI convenience. Not only that, there’s going to be a user-education portion that goes along with that, where we have to train our users and say, “Look, I’ve built this thing for you, but if you circumvent it, and manipulate the data directly, then it’s going to cause problems.”

Then finally, if you’re building “real industrial strength” apps then provider-hosted is the model you want to go. You might build a provider-hosted model that exclusively stores and retrieves data in SharePoint and takes advantage of all SharePoint capabilities, or you may build a provider-hosted app that consumes some services from SharePoint and stores and retrieves or ques data in other mechanisms. Really, you’re only limited by the true need of your application, your imagination, and your skill set when it comes to writing those kinds of applications.

All right, so I want to thank you for giving me the better part of an hour to talk to you today. As always, when it comes to our webinars, I encourage you to ask questions now, and I can respond to those if they show in the question window. If not, again, you see my email address there. I’m more than happy to have you ask me a question after the fact. Also remember that, within a day or two, we’ll have the recording of this up on so, of course, you can send that link to friends and co-workers and let them know about this.

Share and Enjoy !

Related Content: