By Status i mean this website barelyhuman/status
The reason I built it was simple, I needed a simple setup to see if the web services were all up and running, the list is quite small because those are the currrent one’s I would like to keep a track off.
Now this was built in a quick 60 min - 80 min time span and I’m going to explain the things I did and why I did them.
That’s basically it. No seriously, that’s about it.
The idea was to have a simple go binary that would render a html page with each website that needs to be checked and its particular status. This is basically why the website takes a bit longer to load after the browser cache has expired
The go binary is the microservice that vercel will use as an entry point, so on a very basic scale, since I won’t be using code to show how this is being done, we’ll go through the list of things that it does.
Vercel doesn’t allow a root endpoint without configuration so the endpoint for the micro service would be /api/pinger and the final url would be https://status.barelyhuman.dev/api/pinger , which while not a big deal, is a few more keystrokes than just https://status.barelyhuman.dev and thats one issue.
The html templates files are additional assets and those don’t always work in the vercel api functions and that iffy deployment and checks would be a deal breaker for a service which is trying to show the current status of other services.
Vercel has a time limit on each request of 10 seconds , post the initial execution request, so about 12-13 seconds whole. If I ping a website on the Indian Server from a US server, the services that are hosted in EU / IN would add up about 2 seconds, thus making the website be shown as Timed Out if it accidentally crosses the 12 second mark.
Avoid showing people what the urls of each of these api’s are, which while you can dig down a bit and find out, I’d prefer to have at least a layer of protection on top.
/ url to /api/pinger and done, checked if vercel supported that and boom , done.{
"rewrites": [{ "source": "/", "destination": "/api/pinger" }]
}The templates are just strings at the end of the day and go will build everything into a single binary so if I just write them as strings assigned to a variable, I can achieve the same result, so tried that and it worked as expected. I’ve explained about it in this discussion thread
Pinging each site in a linear fashion would be a bad idea but that was the initial prototype. I wanted to test if everything was already working. Checked if it was and then I went ahead and deployed the prototype. Right after I realised, that these would fail if the request is coming from the US server to the Indian hosted backend, thus making it slower, and that basically actually happened. It pinged barelyhuman’s blog properly but failed to get the status for the Taco backend and crashed, a reload showed both the results but I don’t want it to crash for something so trivial. I then just setup a go routine to parallelize the fetching of each service’s status and now the site handles 4 without any issue, not a big number but since it’s parallel it theoretically should create any problems for more either. I can optimize this better by limiting the time of each response to be under 4 seconds but then a busy server might not respond at once so I’m rethinking if I should/shouldn’t do it.
The html render and the website links are all fetched from the environment variables so that’s a secret on the vercel portal for now so as long as no one hacks into vercel, I’m a little safe, obviously you can look through each app but those are proxies and rate-limited proxies (not boasting, there’s ways around each) but for now that’s a simple barrier to keep the urls safe.