The client-side development framework SPFx has already been discussed in some of the previous columns. Various client-side frameworks are used for development, which can quickly lead to version conflicts. To avoid that, Docker can assist here.
SharePoint solutions can be roughly divided into purely client-side, purely server-side, and mixed solution types. In the case of purely server-side and mixed solutions, developers usually need a SharePoint server as a development platform. This is the only way to efficiently implement solutions. Unfortunately, this also means that you need a complete SharePoint farm including Active Directory and a Microsoft SQL Server.Β
The latter can also be used together – but since access is made from a development environment, this is not the optimal way. In addition, a server operating system must be used as a basis. With SharePoint Server 2010, Microsoft made attempts to simplify the implementation of server-side solutions, in that the SharePoint server could also be installed on a client-side system. However, this approach did not prove successful.Β
Therefore, virtualization platforms such as Virtual Box, Hyper-V, or VMWare are used for the development of server-side solutions. An alternative is to use a shared remote server that can be used by multiple developers. But this variant is also problematic since the installation of solution packages can always lead to interruptions in (debugging) processes.Β
An alternative is to use a shared remote server that can be used by multiple developers. But this variant is also problematic since the installation of solution packages can always lead to interruptions in (debugging) processes. An alternative is to use a shared remote server that can be used by multiple developers. But this variant is also problematic since the installation of solution packages can always lead to interruptions in (debugging) processes.
SPFx-based solutions
If, on the other hand, purely client-side solutions are implemented, a SharePoint server is ultimately also required. It does not matter whether it is an on-premises server farm or a SharePoint online farm. The development environment based on the SPFx, therefore, differs in many respects from a server-side development environment. In client-side development, the management of different frameworks and library versions is more of a challenge. For example, SPFx is constantly evolving and newer versions are released over time. The same applies to the libraries used. In order to avoid any version conflicts on the local development computer, isolation for each development project would also be desirable here. Of course, a virtualization platform could again be used. But while this is theoretically possible, it poses a problem for client-side l…
SharePoint and the Graph API
Data from SharePoint can be accessed in various programmatic ways. A modern access path via a web protocol is available with the Microsoft Graph. The current column is initially about clarifying how the graph interface is structured and what this API enables. In the next issue, the Graph API will be put to practical use within a SharePoint solution.
When implementing solutions based on a SharePoint platform, data must be retrieved from SharePoint in most cases. This can be, for example, list entries, documents, search results, or data from other SharePoint sources. This data can be accessed in a variety of ways:
- Direct access via the server-side API
- Access via a client-side library (CSOM, JSOM)
- Data retrieval via PowerShell
- Use of a REST endpoint (e.g. https://{tenant-name}.sharepoint.com/_api/v2.0/sites )
Direct data retrieval via the server-side API should be avoided whenever possible, as this requires solutions to be installed directly on the SharePoint server. As an alternative, the available client-side libraries that are available for different platforms can be used. They allow remote access to SharePoint data, eliminating the need to install a solution directly on the SharePoint server. The PowerShell commands and extensions also allow access to SharePoint data. However, PowerShell is not particularly suitable for being integrated into your own applications. Various REST API endpoints are also available, which enable simple web-based data retrieval. The REST API interface has long been at the address /_api/accessible on every SharePoint page. There is now also a newer endpoint for this under /_api/v2.0/ . This new endpoint can also be integrated directly for your own solutions. However, this endpoint is important for the Microsoft Graph because it uses it for integration. Table 1 shows the relations between REST and graph addresses. The table shows which endpoints the Graph API uses to access SharePoint.
Microsoft Graph overview
The Microsoft Graph enables centralized access to Office 365 data and functions. By bundling information from different systems, the graph represents a uniform and standardized access point. Not only data from Office 365 and its environment can be accessed via the Microsoft Graph, your own data can also be made available to the graph via connectors. Figure 1 shows the classification of the Microsoft Graph in the Microsoft 365 platform. The Microsoft Graph currently provides data from the following cloud services:
Contact the best team of Al Rafay for all real estate IT Solutions. Al Rafay Consulting (ARC) Is one the best Microsoft consulting firm in the USA.Β
