SharePoint Framework is the latest buzzword making waves in the technology sector. It is mainly known for its client-side development features providing easy integration with SharePoint data and its support for open source tools. It can also be used with modern web development technologies to build applications that are mobile-ready. In addition, SharePoint Framework is designed to support SharePoint on-premises and SharePoint online.
These newly provided features of SharePoint do not affect the existing functionalities, instead they enhance features available in developer toolbox. When there are a lot of options available, it is extremely difficult to choose. Same is the case with SharePoint configuration. Before migrating to the new SharePoint Framework, it is necessary to think which features will be useful and feasible. Similarly, it is vital to understand when to use SharePoint Framework for your application development.
Modern team site communication with SharePoint – If your requirement is to build web parts in modern team site, which quickly allows you to add new items to the list or manage existing items, then this component can be built using SharePoint Framework. By solely using client-side technology and JavaScript framework, a small web application can be built to communicate with SharePoint.
Mobile-friendly solution – When SharePoint framework was build, first priority was given to mobile. The modern site feature within SharePoint are responsively build where its contents and customizations can be used for developing mobile app. With this feature, users can develop a consolidated solution that can be viewed on desktop or mobile.
Switch from classic SharePoint – The new SharePoint user experience is amazing in its own way but for some users it can be overwhelming. This is because they might require in-depth implementation knowledge of SharePoint framework. On the contrary, if the SharePoint Framework is familiar to you then instead of investing twice, you can simply develop a new solution using SharePoint Framework. However, the solution should be developed using only client-side technology. If you have other complex applications, you should be much more experienced in SharePoint.
Need elevated read from/write permissions – At times, it is good to have privileges irrespective of whether they are useful or not. Same is with SharePoint read from/write. SharePoint provides you with elevated permissions for a particular chunk of code within the farm solutions or app-only context for the site hosted with provider. SharePoint solutions being client-based, does provide provision for your code edit. Hence, to avoid these situation, user can build a hybrid solution. This can be done by developing UX using SharePoint Framework which can communicate with API registered with SharePoint add-ins, which uses app-only feature to context with SharePoint.
Need for long-running operations – Usually executing operations on client-side that tend to consume lot of time is not recommended as it is risky. Few processes might take a lot of time than actual. A hybrid approach can be beneficial here. You can use SharePoint Framework to build UX of the application and for backend you can use SharePoint sites to implement operations that consume lot of time. If you are opting for this solution then, if any browser issue persists, it would not hamper long-running operations which can be scaled independently.
Customizations that work securely – If you have some confidential information stored at customized intranet sites, make sure the customizations do not jeopardize the security of confidential information. When solutions are build using SharePoint Framework, user has all liberty of what an application can do. Hence to avoid this, code review is the best viable option. Another way to build customization is using SharePoint Add-in model. Here, it is possible to set permissions according to the user and limit it to the number of operations.
Data integrity – SharePoint Web Parts belonging to modern page and are in tandem with other Web Parts. Each Web Part is a fragment of a page and also a part of DOM, where a particular Web Part can hypothetically modify the contents of another Web Part belonging to other page. Thus to ensure data integrity, it is must to build a client-side application which covers an entire area or a Web Part using SharePoint Add-in model that would be executed in an isolated iframe.
IP protection – Solutions built using SharePoint Framework are browser based and client-side. Also, it is hard to avoid the situation where people can read your JavaScript code, irrespective of solutions. Thus if you require IP protection, it is better to develop solutions using server-side code like provider hosted add-ins.
Put out the developed solution on Office store – SharePoint Framework solutions processes everything according to the user, which can be done by the customizations also. There are no specific permissions because customizations are displayed on the page directly. However, if these customizations are done from an unknown resource, it can be risky. Thus, Microsoft Office supports only SharePoint Add-ins.
Communication with Microsoft Graph – OAuth authentication is used by Microsoft Graph for the purpose of controlling access because client-side solutions are not reliable in terms of security. Thus, using Microsoft Graph for server-side communication can be beneficial in securing access token. But on the contrary, it might be difficult to provide permissions to server-side component that can be excessively used by the Web Part. But, in case of a client-side, things can work because, the application is the single customization available at the specific URL and thus OAuth can make much more sense and help your application to communicate with Microsoft Graph.
