API to go with a website

Sometimes there is a need to have some code running on the server. It is possible to do that to some extent for a Static Web App via the API mechanism, but that is not always free and there are limitations on the API implementation.

When to use an API

It offers a set of routes/URLs that are part of the website's URL range and can be called like any other, but execute code rather than a static web page. In my projects, the API mechanism may be relevant for two use cases: used by client-side code and used by server-side code. As I have a preference for client-side code of using a (free) web assembly over server based functionality, I'll always try to make the API functionality part of the web assembly. From a coding perspective there is hardly any difference, as the code is C#/cross-platform .NET in both cases.

The only reason I've had so far to consider the use of an API from client-side code is to provide data to an external service that is embedded in the website, in case the limitations prohibit providing the data as static files, e.g., because too many files are required or the files become too large. The API is used to filter a data set based on the selection criteria specified by the external service. This functionality can be provided via a separate Azure Functions or by the API; the API is required if CORS-issues are relevant.

The API can also be used for the server-side generation of web pages. It is possible to have a “normal” URL (like /error.html) and rewrite that to call an API (e.g., /api/alert). The original URL requested is available in the code via the x-ms-original-url header. I have used this feature in one of the projects to implement redirects: the code included a translation table of old URLs to the URL on a new (different) website. This was not possible to achieve with static files. There were too many redirects to fit in the limited size of the Static Web App configuration. And there was no way to set the redirect-header for a static file. As the old URL did not have an extension, it was also not possible to create an HTML file with the redirect information in the HTML, as that file would be served by Azure as an unknown file type (Content-Type: application/octet-stream), and that header cannot be overwritten in the configuration of the Static Web App.

Be aware of the limitations

As discussed in limitations, the main limitation is that there is no way to cap the costs of the API use. For a website that is only available to authorized users this is probably not a problem, as the use will most likely stay within the free tier. For public websites it may be an issue.

Code-only deployment

The API is hosted as Azure Functions, and that means it runs on Linux. The deployment is code-only: you have to provide the source code in the deployment to Azure, and the Azure publication tool and related services compile it.

This is something to take into account. My projects, and especially the ones with multi-platform deployments, are typically constructed in such a way that most functionality is in libraries that are (unit) tested in isolation on Windows. The final application may require many of the libraries. As I can build the applications for all platforms on a development desktop and can debug them as well, I'm able to catch and solve all platform-specific issues in the development phase. But I don't know the settings Azure uses to build the application, and debugging the deployed application is a whole different ball game.

For now I'll only use very simple API code, then I don't have these problems.