There are a lot of different options when it comes to communicating with SharePoint. Here’s some advice when to use them when building Apps:

Apps that offer Create/Read/Update/Delete (CRUD) actions against SharePoint or BCS external data, and are hosted on an application server separated by a firewall benefit most from using the JavaScript client object model.

Server-side code in Apps that offer Create/Read/Update/Delete (CRUD) actions against SharePoint or BCS external data, and are hosted on an application server but not separated by a firewall mainly benefit from using the .managed client object model, but the Silverlight client object model, JavaScript client object model or REST are also options.

Apps hosted on non-Microsoft technology (such as members of the LAMP stack) will need to use REST.

Windows phone apps need to use the mobile client object model.

If an App contains a Silverlight application, it should use the Silverlight client object model.

Office Apps that also work with SharePoint need to use the JavaScript client object model.

The mantra of SharePoint 2013 seems to be: “Must get all the evil custom code out of SharePoint” (whether that will be workflows, InfoPath, or farm solutions). Is it just us or is the new best practice of creating Apps for SharePoint 2013 leading to a big mess of so-called “client-side pattern” cum “spaghetti” code? At this point, it feels as if MS is catapulting SharePoint devs back into a time where JavaScript was the main tool of the trade (or, as is suggested here, you should build business logic using client-side JavaScript: http://msdn.microsoft.com/en-us/library/office/apps/fp179889(v=office.15)). It seems that in one or two new versions of SharePoint from now we all will be saying: “of course this old development style lead to all kinds of problems and messy code, luckily now we have a development environment that fully supports OO client-side development”… Anyway, this Wiki page contains a link to some of the emerging design patterns for Apps for SharePoint 2013: http://social.technet.microsoft.com/wiki/contents/articles/12438.sharepoint-2013-best-practices.aspx

Without getting into much detail, there are several host models for Apps in SharePoint 2013, namely:

No-hosted

SharePoint-hosted

Provider-hosted

Again, without getting into details, provider-hosted Apps can be hosted on dedicated application servers or in the cloud (Azure). We want to take a moment to reflect on the provider-hosted Apps on dedicated application servers… Those Apps are stand-alone applications that run completely outside of your SharePoint farm, and SharePoint is completely technology-agnostic as far as these Apps go. This means, Apps can be hosted on application servers running, for instance, using any technology on the LAMP stack (Linux, Apache, MySQL, and PHP).

This particular feature was hailed enthusiastically by lots of SharePoint bloggers. We don’t share the sentiment. Although in itself it’s great to have the flexibility to use any flavor of application server you like, in reality we’ve found that this type of platform independence is almost never an issue (Roger Sessions once did some, unscientific, research about it, wrote about it, and found that this is a factor in less than 1% of the IT projects). If you’re an avid Java or PHP developer planning to build Apps, you’ll find that you still have to have intimate knowledge of SharePoint technology and development models. What’s more, developing these types of solutions will be a lot easier using the Microsoft dev tools. We’re convinced that the share of skilled Java and SharePoint developers is pretty limited and we’re betting it’ll stay that way for times to come. In addition, some SharePoint bloggers have even predicted the end of the era of SharePoint developers, since now every ASP.NET developer will be able to create Apps as well. We think this is nothing more than a wrong conclusion, for exactly the same reasons. If you want to develop SharePoint solutions in the form of Apps, you need the knowledge about the platform. You simply can’t do that while you’re avoiding becoming a “SharePoint” developer.

We’ve never seen a version of SharePoint where so much information was already available during beta release. We did notice though that a lot of articles contrasting farm solutions, sandboxed solutions, and Apps use the terms farm solutions and full trust solutions interchangeably (even so in MSDN documentation).We don’t think this is fair, because it implies that farm solutions can’t run without full trust. The opposite is true, farm solutions can run under very fine grained security policies. We do know where the confusion is coming from, a new change in SharePoint 2013 is that now, the default CAS policy that is used us Full Trust, instead of wss_minimal:

<trust level=”Full” originUrl=”” legacyCasModel=”true” />

In effect, this will mean that by default, a SharePoint 2013 farm solution will run under full trust, which makes it a full trust solution. Things didn’t use to be like that, and we feel this is definitely a step backwards for the latest version of SharePoint. At this point, all we know that this change is caused by the fact that the full trust is needed by .NET 4?! We don’t have more specifics, and we don’t know if SharePoint 2013 is able to run under a different trust model without breaking.