Proposed serverless model for a decentralised speedtracker

[philhawksworth]

Overview

In order to remove the need for Speedtraker to maintain a server instance to handle the comms between WebPageTest API requests and a suitable data stores (currently on GitHub), a serverless model could be adopted. This issue is intended to help facilitate a move to this architecture. And to discuss some of the ways it can work.

Summary of logical architecture

At a high level the flow will be like this:

• After a successful deploy, a request will be automatically made to submit some defined URLs to WebPageTest's APIs for performance measurements. This request can be created by a serverless function associated with the site build.
• The request to the WebPageTest API will include a callback endpoint of another serverless function which can receive the results data, and stash it a suitable database. (This might be Mongo or Fauna or similar)
• Following the saving of results data to the DB, the serverless function will also trigger the build of a reports view site, which will generate visualisations of that data for review.

All of the above can be automated through Netlify Functions, events, and build hooks.

Advantages

In this way, each site owner will be bale to execute the requests to WebPageTest directly under their own quota and without the need for an intermediary service.

Each user will also be able to manages and customise their own means of persisting and reporting the data (building upon some easily provisioned and working defaults)

GitHub will no longer be relied upon to be some where for the raw results data to reside.

Since performance metrics will be created for every deploy, we will be able to visualise the impact of performance from every deployment and every commit which triggered that deployment

High level tasks (probably to be tracked separately)

• Create a project initialiser which will provision and associate a Fauna DB, and store the WebPageTest API key.
• Create function to dispatch calls to the WebPageTest API and specify an handler function
• Create a function to handler the results returned from WebPageTest and stash them in a Fauna DB
• Create report views of the results data as sourced from the Fauna DB
• Add triggers and automation to trigger the flows
• Documentation, documentation, documentation

[eduardoboucas]

Function as an API

This is great, thank you @philhawksworth! I've done some work on the dashboard (see https://github.com/speedtracker/speedtracker/tree/feature/v2), which is mostly aligned with the vision you outlined. Perhaps the only exception is this:

Following the saving of results data to the DB, the serverless function will also trigger the build of a reports view site, which will generate visualisations of that data for review.

In the proof-of-concept I put together, I created a Netlify Function that retrieves test results from the database based on the parameters it receives, effectively acting as an API. For example, this call returns the test results for a profile called test between two timestamps: https://serene-dubinsky-e91d99.netlify.com/.netlify/functions/get?page=test&from=1536167284&to=1536177019

As a result, there's no need to ever rebuild the dashboard site (unless the dashboard itself is being updated), as the front-end application makes XHR calls to the Netlify Function.

Profiles

It's also worth touching on this:

After a successful deploy, a request will be automatically made to submit some defined URLs to WebPageTest's APIs for performance measurements. This request can be created by a serverless function associated with the site build.

In the current implementation of SpeedTracker, users define the URLs to be tested using the concept of profiles. A profile is a collection of test parameters, which include the URL to be tested, but also other WebPageTest parameters such as the device type, the location of the instance, the number of runs, etc. This is also where budgets for each performance metric can be defined, as well as related alerts. The most common reason for having multiple profiles is to test multiple URLs, but you could use them to test the same URL under different conditions.

In the proof-of-concept, the profiles are loaded from a YAML file, which at build time is read and converted into a JavaScript file that the React application can read.

Going forward, I think it'd be interesting to provide two options for configuring this:

1. Read a URL to test from an environment variable (e.g. TEST_URL). If the Netlify UI allows people to quickly insert a value here, it would be a great way for someone to start playing with SpeedTracker and have it test a single URL, without having to manually edit a YAML file.

2. If a profiles.yml is present in the repository, that takes precedence over any environment variable. This could be used by more advanced users that want to have multiple profiles and/or performance budgets.

Next steps

I'll start looking into the functions for triggering tests and processing results, incorporating them with the proof-of-concept. Perhaps at that point we can regroup and re-evaluate how the various pieces work together?