When you write a new web part with the SharePoint Framework you might create a genius web part, where all the business logic is compiled into your web part. This approach makes sense when the web part is an isolated piece of work.
Sometimes you like to write pretty simple web parts that only access a backend or third-party API from somewhere on the Interweb. In this case, you can write all the data access inside your web part. Give the user the option to store APP Key, APP Secret and particular access token directly in the web part. Might pre-populate some of those properties of with your company-wide secrets and API keys too.
Over time the API might evolve, or you need to exchange the existing APP-ID with a new APP-ID or secret. You can write a new version of the web part and update all your existing instances to the changed conditions.
Wouldn’t it be smarter to store your settings somewhere else than directly in the web part? Even if you like to implement the data access don’t you want to create an interface which is apart from your web part code?
Create a new app for a smart, stupid web parts
Think about the following scenario. Currently, there is a web part that supports YouTube. This web part by Microsoft and does its job, but it only can be used with a single platform.
In case you like to use other platforms, such as Vimeo you might, need to write your custom web part. This web part can allow you to search all the Vimeo Videos, let the user pick the right video and embed it to a SharePoint page.
The first step to access Vimeo via their API is to register an App on their developer portal. Like most services on the web, they use OAUTH2 for authentication. So you get an APP-ID, and an APP Secret needed to authenticate against their API.
With the provided information you can already start to hardcode this into the web part or store them in the properties and access their rest endpoints directly from your web part. All good and a conventional approach but think about how to change these settings.
Update your web part code and redeploy? Write a script that updated all web part instances? Isn’t there a smarter approach to that?
There are still other questions unanswered before you can start to implement your web part. Vimeo, for example, has support for multiple programming languages but which one is the best to pick?.
Which SDK to use?
We need to store APP ID and App Secrets to authenticate against Vimeo web service anyway. So in case of a proxy web service, this could be part of the configuration. When changes to the configuration are needed, the web service can be the only place where those changes get applied.
Theoretically, in an on-premises world, and a C# background you tend to write a WCF Web HTTP service that implements the data access to the API of any application on the web. You can pass in the search queries and return the result.
Vimeo has an unofficial library listed to support .Net, Go, Java and Ruby. So this might be an option, but it is unofficial. The result could be that the person maintaining the project don’t like to support it in future and you have to rewrite your web service. Maybe write all the access methods manually.
Another option is to create a Docker container to provide this web service between the Vimeo API and your web part. It could be a web service written in NodeJS. NodeJS has official support and an SDK for this specific API. So it is a more substantial approach than using an un-official library.
Docker is helpful to use, but then you have to deal with other considerations too. Where and how do I host my docker container for example?
Server-less is the future and to be more precise a “single-purpose-server-to-small-to-call-it-a-real-server” would server this job pretty well. If you use Azure anyway, then this may be the right spot to host your docker container.
Azure Function – FTW
It even allows me to transform the data returned by Vimeo to any other defined JSON structure if needed. Another benefit is that you only have to configure all the settings once independent of the web part instances as I already mentioned before. So, you can store AppID and App Secret in the configuration of the Azure Functions. In case the SDK changes and I need to adapt the code of the Azure function without the need to redeploy the web part.
In the upcoming blog post I will show you what you need to know on Azure Functions for your local development and once the service is running, we will write a web part that consumes the information from the web service in SharePoint.
Stay tuned for part two and three in this series: