A history of extensibility in SharePoint and how Fresh chose a model
In the old days of SharePoint there was a single obvious choice to consider when building applications on the SharePoint platform. Microsoft Office SharePoint Server (aka MOSS, aka SharePoint 2007) introduced the Farm Solution with its Feature Framework and later SharePoint Server 2010 provided a safer incarnation of this with the Sandboxed Solution (aka User Solution).
During this time, a SharePoint application or extension would be built as a Sandboxed Solution if possible within the restrictions of this model, and otherwise would resort to being built using the Farm Solution model.
SharePoint Server 2013 introduced the App Model (now referred to as the SharePoint Add-in Model) which was intended an alternative to the Feature Framework based models. Importantly, the Add-in model supports applications running on servers outside of the SharePoint farm and using remote APIs to authenticate and utilise the services provided by the platform. This is a critical step towards ensuring the performance and availability of SharePoint irrespective of the Add-ins deployed to the environment.
For completeness, Office 365 Apps provide yet another way to authenticate and execute code against SharePoint Online APIs and the Microsoft Graph among other endpoints. However, this article will limit itself to extensibility models that are suitable for both SharePoint Server and SharePoint Online.
It is in this context that Content and Code approached the development of Fresh, our Internet solution. The solution needs to work both with SharePoint Server/On-Premises and SharePoint Online. It must also not have a dependency on non-SharePoint Infrastructure as for many organisations it’s not currently possible to host code in Azure. This is often due to it being an unrealised platform within the company rather than any technical or compliance reason. Even for clients who are already in Azure and totally satisfied, providing a solution with no external dependencies and no variable hosting costs improves our proposition.
Unfortunately, the framework shipped with limitations around the provisioning of SPFx web parts that prevented its being provisioned along with site templates. The modern page framework in which the web parts shine best was also limited in the way layout and common elements such as navigation could be applied.
Recent advancements such as SPFx Extensions in preview, communication sites providing modern pages with page layout mechanisms, and tenant scoped deployment of SPFx web parts go a long way to providing a platform suitable for an Intranet product. As this landscape matures to general availability in all areas we expect to be able to take full advantage of the new framework. We are committed to using the best engineering approaches for Fresh, and our investment in this area will continue.
Choose your model
About our author
Paul works as a Technical Architect at Content and Code. Having worked with SharePoint since 2007, and with Office 365 and Azure since 2013 he has developed deep technical knowledge in these areas and special interest in Microsoft Cloud technologies. He has played a key role in the successful conception, design, and development of enterprise solutions across a range industries including telecommunications, defence, legal, imaging, construction, and health.