It soon got a bit more complicated. If you run a company that’s actually doing something with information retrieved from the web page, you need scripts on the backend:
But the web page code was often still quite straightforward to look through.
In recent years, however, there has been a tendency for web APIs to require an API token to access the API. The token allows the API publisher to track, and limit, use of the API from a particular user; tokens should also be kept secret.
So for example, you can’t just call the Youtube API to search for videos on a particular topic. Instead, you have to make a request using your key as part of the search query. You can still list the results and add video players to your page which will play without the need for a token, but the initial API request needs a key.
What this does is place a burden on someone wanting to call the API. No longer can they publish a single web page app, where everything is contained in a single web page. Instead, they have do do some code execution on the server side so they can keep their token secret:
A single page, self-contained web app is still possible, but you give your token away so that anyone else can use it, and run up (mis)usage on your account…
(You can still get to see the HTML, but it means you have to go into the browser’s developer tools area so you can inspect what the browser is actually rendering.)
If your application is on a server that was created for a previous visitor, and that server is still running, will be used to serve the application rather than a new one being launched. Unless your application is receiving lots of visitors at the same time, in which case the serverless host may autoscale it for you, and launch additional servers running your web application to cope with the load. (Autoscaling can also be applied to “traditional” web servers.)
What’s important to realise about serverless web application architectures is that they aren’t serverless: a web server is still required to serve the application. The serverless property means that there is no webserver unless someone makes a request to view the site.
For some examples of serverless approaches via lambda functions, see Implementing Slack Slash Commands Using Amazon Lambda Functions – Getting Started and Searching the UK Parliament API from Slack Slash Commands Using a Python Microservice via Hook.io Webhooks.
One of the early, easy to use serverless providers was Zeit.Now (see for example: Publish Static Websites, Docker Containers or Node.js Apps Just by Typing: now). An attractive feature of the Zeit offering was that it could launch web applications packaged in Docker containers in a serverless way, but this seems to have been deprecated recently (for example, see this post from Simon Willison).
However, it seems that Google have just announced a new service that launches Docker containers in a serverless way: Google Cloud Run. For a third party review, see here.