Develop the Impossible with SharePoint (Part 1)
Many developers who are used to building legacy farm solutions for past versions of SharePoint on premises seem to be intimidated by the current Add-in Model (formerly referred to as App Model). I’ve heard plenty of excuses for sticking with the “tried and true” approach such as:
- I can write solutions faster the old way
- There are too many limitations of the new way
- We have no plans of going to the cloud
- We don’t want to builds apps
- etc.
When it really comes down to it these are simply excuses – nothing more. Now to be fair getting into the mindset of the Add-in Model after building farm solutions for so many years is not a trivial thing, you need to completely rethink how you approach designing and implementing your code, but in the end you’ll find that the rewards are well worth it.
What is the Add-in Model?
If you are new to this, it’s fair to start with defining what the Add-in Model is. It started out as the means to develop solutions that can be packaged up into Apps and deployed to the SharePoint App Catalog, which is why it was originally called the App Model. However, that unfairly caused people to think that it was only good for building “apps,” and it can do so much more than that.
A better definition may be: the Add-in Model is the group of technologies that can be used to extend the SharePoint platform. The primary technology within it is the Client Side Object Model or CSOM for short. CSOM comes in various forms such as a .NET library, JavaScript library (often referred to as JSOM), and also a series of RESTful web services. A well designed Add-in will leverage one or more of these CSOMs to extend the capabilities of the SharePoint platform in such a way that it does not compromise the backend server infrastructure.
The main driving force behind this modern design (outside of the ability to package features for distribution via the App Catalog) is the desire to get the code off of the SharePoint server itself. Many times when you have a SharePoint platform that is performing poorly or plagued by instability, the root cause of the problem can be traced back to code within a farm solution that is not written well, or is being used in a way that was not anticipated when it was first designed. This can lead to users getting frustrated with a platform, but that really isn’t the problem. The Add-in Model via these CSOMs solves this problem by having the custom extensions execute outside of the platform itself. Whether it be in the client’s browser (JSOM), a backend .NET server (.NET CSOM), or even some non-Microsoft backend (REST).
In the following posts in this series, I will go through some of the many solutions we have created that utilize the Add-in model to overcome business and technical challenges that in many cases weren’t even viable options with traditional farm solutions. The end results are some incredibly robust solutions leveraging modern design patterns that position our clients to take full advantage of the promise of the cloud (if they choose) and ultimately maintain a much more stable experience for their collective user base. At the end of the series you should see that there is almost nothing that is impossible with the Add-in model if you are willing to think outside the box.