In my company we have a team of 5 SharePoint developers. It just so happened that every one was very excited about new app model at first. But as time went by we started to realize that we can't find a good use of this model. We are not developing for Office 365 and we just keep creating farm solutions as usual. I'm searching where we can possibly use this app model, but we simply don't need it yet. Are we not alone who's worried about it? Or is it absolutely OK? Are there any good cases where apps can give us any leg up versus farm solutions?
3 Answers
We're working on a corporate Intranet and I've just in the last few weeks attempted my first application. After you've decided to roll out with Office 365 or on-prem I think the first question to ask yourself is "Am I manipulating SharePoint itself?" Simply put, with Office 365 the flowchart ends with "make an app". You see a lot of app examples of things like provisioning master pages, IMO, because Microsoft is trying to move companies into O365 and therefore the MVPs and consultants need to learn how to support what Microsoft is driving.
Let me give you two concrete examples of what I think warrants the use of Farm solution and one that warrants the use of App Model.
1) You want to build out a company Intranet and not spend time manually creating custom content types, libraries, sites and branding, package it up as farm solutions. Use your own best practices on how many solutions to create, but for example I have a feature that will take a team site and transform it into a "department site". I just create subsites and then run one feature and boom a new department site has been created.
2) You need to work on custom logic that requires little to no use of SharePoint. For instance, you want to build a section to your Intranet that shows a breakdown each of your employees' time spent on clients using a several different charts and filters. The chart and filtering logic will be custom but the client information will come from a CRM product and time billed to a client is stored in a SharePoint list. It's best to build that as a SharePoint app since there is such a big separation of concerns away from SharePoint.
This is just my take on the two different methodologies. The app I'm working on has several custom code files that would just not make sense to deploy to SharePoint logically. Plus, the added benefit is that my custom logic is not in danger of incompatibility in a future release. I just need to make sure there is a list where I host my app with the same columns I reference in my application.
Hope this helped.
I do agree that APP model is the new buzzword in the SharePoint world, and it is shifting the way we used to think everything as a feature till date.
App model does offers some great flexibility to manage the solutions for admins (distribution and deployments) but yet to have a better example for app development.
So far what i could see is developing single page application with some scripting and REST call is the only valid use that i can see..or giving a new UI to SharePoint components.
Combining my experience with that of my colleagues, my advice would be to spend some time learning the App Model but to avoid really investing in it until version 2. There's currently a serious lack of documentation and real world guidance and, unfortunately, a lot of issues being reported.