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?

The API provides pretty good support for REST queries to search for videos. So basically JavaScript is all you need. To make the web part stupid and avoid breaking changes in their API. It is eventually smarter not to code too many in a web part and use a proxy web service between the real API and the web part. This web service can even abstract all the required steps, such as authentication away from the web part and result in more straightforward functions call to search for videos.

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.

Wait, isn’t there a better option that allows me to do precisely the same thing without docker? Well, there is, and this thing is called Azure Functions, which support a lot of different languages including JavaScript.

Azure Function – FTW

The Azure Functions support JavaScript as one of their native languages to implement. The base technology for JavaScript-based Azure Functions is not only Javascript it is NodeJS. Everything you basically can put in a NodeJS based Docker container will work as an Azure Function too. From my perspective, this is the appropriate tool to choose to access the Vimeo API and work as a proxy.

Azure functions are pretty simple to implement. It also has the benefit that you can develop and test locally before moving it to Azure. Plus I only have to write JavaScript starting from the front end web part over to the Proxy Web Service to access data from a third party API only one single programming language is needed.

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:

• An Azure Function for a smart stupid web part – Part 2
• A smart stupid web part consumes a third party API through Azure Functions – Part 3