The web used to be such a simple place: write some HTML+CSS, perhaps add in a little bit of javascript, all of it readable via View Source, upload it to a webserver somewhere, and job done.
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.
The arrival of web APIs meant that you could call on other people’s webservices and add them into your own. Want to add a Google map to your web page for example? That could all be done, via Javascript, in the browser client:
What this meant was that you could build quite rich applications with just HTML, CSS and Javascript; you didn’t necessarily need to run server scripts and you could het away with very simple web hosting: nothing more than a place to upload you files. Any execution of (Javascript) code would happen on the client side, in the browser.
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…
This is a real pain and represents another way in which powerful features (the ability to easily call third party APIs) is denied to novices, making the on ramp harder. You can’t just hack together some HTML’n’JS and post it somewhere, letting the browser run the Javascript code and calling the third party APIs. You need to solve another problem first — finding somewhere to run chunks of your code in private to call the API services using your private key, building the page based on the response from the API and then serving that in public.
Just by the by, web pages have also got harder to read when you View Source. Many of them dynamically create HTML elements from Javascript, which means if you View Source, all you see is the JS code.
(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.)
Another shift that is happening is the shift to so called “serverless” models for publishing web applications. In this case, the idea is not that you upload your website code (HTML, Javascript, CSS, server scripts) to a web server somewhere, but you upload it to a potential webserver. When a request to view the website comes in, a server is launched dynamically to serve the application.
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.
OUseful.Info, the blog... 