Difference between Farm solutions and Provider-hosted Apps

Question

I have been reading quite a lot about SharePoint 2013/2016 lately and I am not sure I am able to see the difference between Farm Solutions and Provider Hosted App. Please correct me if I am wrong:

• Farm Solutions are custom code deployed directly on the SharePoint Server (They are Full trust Applications), but then I can't see the difference between sandboxed and Farm Solutions.

• Provider Hosted App are applications that can be hosted on a complete different server and have to use S2S identification in order to be able to connect to the SharePoint Server (There are High Trust, user need to say he trusts this application) and are displayed in an IFrame to have a seemingly SharePoint experience using Chrome styling.

The more I read, the more I am confused!

Answer 1

Yes, your trouble is quite understandable!
First, you should read that "controversial" discussion we had here a few days ago: SharePoint development past and "future": how to keep calm?.

This will give you a history/backgroung about the different dev approaches for SharePoint.

And here's another (more technical) overlook:

1. Farm solutions (aka WSP) are packages physically deployed on the SharePoint server. They contain server-side code (C#) that has access to the entire SharePoint server API, meaning it can do a lot of things. A lot of components can be developed with this model: Web parts, event receivers, jobs, workflows, applicative pages, custom field types, custom forms, ... Almost no limit. This also means a "poorly-developed" application can highly impact the server (performance and security risks).
2. Sandbox solutions do use the same concepts but are limited, mainly in terms of the API you can use (+ they are resources-throttled by the system). So, it's a kind of subset of farm solutions. But same concepts, etc. They were introduced in SP2010 to allow developers to leverage their farm-solutions knowledge, while allowing some sorts of customizations in cloud-versions of SharePoint.

3. Then came the "Apps", now called add-ins. They appeared with SP2013, and sandbox were deprecated at the same time.
   Add-ins is a completely new approach for development. In a word, no custom code ever runs on the SharePoint machine with add-ins. Never. No code on the SharePoint server. The code is either client-side (JavaScript) or on a third-party server (ASP.NET or else). Also, there's a concept of app-web and IFrame to add a bit more confusion to the story, but I won't elaborate on that...
   Add-ins are categorized into different types:

   a. SharePoint-hosted add-ins: they only have JavaScript code.

   b. Provider-hosted (CSOM/REST) add-ins: they have JavaScript + server-side code (on the third-party server, never on the SharePoint server!) but the server-side code does not interact with SharePoint data.

   c. Provider-hosted (oAuth) add-ins: they have JavaScript + server-side code and the server-side code may interact with SharePoint data on behalf of the user. Only possible in Office 365 AFAIK.

   d. Provider-hosted (high-trust) add-ins: they have JavaScript code + server-side code, and the server-side code may interact with SharePoint data by authenticating itself as the add-in (with a client certificate). Only possible with SharePoint on-prem AFAIK.

   e. Auto-hosted add-ins: they do not exist anymore, Microsoft stopped them short after SP2013 release. Like a provider-hosted (oAuth) add-in, but with automatic deployment of the "third-party server" into Azure.

4. But we're now told add-ins are not that great, and a new (!) framework is released by Microsoft these days, called SPFx. For the moment it allows Web parts development only, but no more crappy concepts like app-web, IFrames, or else. But still "all client-side". And a lot of "new" tools, beside Visual Studio, to know about.