[Feature] Healthcheck Endpoint

[Skn0tt]

What do you want and why?

Applications commonly require status endpoints for monitoring purposes. It'd be great if Blitz supported that out of the box, preferably with included health checks of all necessary resources.

GET /api/health

200 OK
{ "isHealthy": true, "resources": { "redis": true, "db": true } }

Registering a new resource to be health-checked could work like this:

import { registerHealthCheck } from "blitz/health";

registerHealthCheck(
  "redis",
  async () => {
    const response = await redis.ping();
    return response === "pong";
  }
);

We could readily bundle healthchecks with officially supported resources, e.g. the Prisma Datasource, Job Queues or connected SMTP endpoints.

Possible implementation(s)

Add the /api/health API route, which will check against all registered resources when called. The specific endpoint could be altered in blitz.config.js.

[aem]

An interesting question here is if we expect much of the usage to be serverless, a healthcheck endpoint is a bit useless, right? You'd need to verify each endpoint individually. It's not like a traditional long-running server where one endpoint being live means the whole app is working correctly

[Skn0tt]

I'm not that familiar with serverless deployment scenarios, but isn't there something like health / heart beat monitoring on serverless platforms? Also, considering configuration and attached resources being shared across functions, health state should be consistent across function executions, right? So verification of all endpoints would only be necessary for stateful functions, which is a serverless anti-pattern anyway.

[aem]

@Skn0tt there probably is a concept still (I'm not familar with it), I just assume it's a little more involved since with serverless one 200 response from a serverless endpoint doesn't mean another serverless endpoint is up and running. Do you want to do some research into common patterns here?

[Skn0tt]

The Serverless Healtcheck Report

For Reference: Healthcheck Pattern

Goal of this: Find out if and how the concept of health checks exists in Serverless execution environments.

Environments that support health checks

Although not Serverless per se, Docker and Kubernetes implement health checks. When a pod / container becomes "unhealthy", it's swapped out immediately.

This behaviour is inherited to projects like OpenFaaS, who actually require a healthcheck to be present:

On Kubernetes is possible to run any container image as an OpenFaaS function as long as your application exposes port 8080 and has a HTTP health check endpoint.

Other notable environments supporting health checks:

• Knative
• AWS Fargate

You'll find that all of the above-mentioned services are part of the extended Docker ecosystem, most even part of K8s'.

Environments that don't

• AWS Lambda
• GCP Cloud Functions
• Azure Functions
• Vercel Now
• Netlify

In general, you'll find there to be two distinct versions of the "Serverless" concept: One where you simply deploy your raw source code and don't worry about how it's gonna be run in any way, and another one where you've got the option to build your own Docker images and the "Serverless" magic is just provisioning and deployment. Interestingly, you'll find the former (Lambda, Cloud Functions, Now, Netlify Functions) not to support health checks while the latter do support them.

And that makes total sense: Health checks are a deployment-specific thing that you don't think about when not thinking about deployments.

Conclusion

Well, Health checks are indeed a thing in Serverless execution environments, but apparently not in the environments that are close to Blitz' ecosystem. I find Netlify, Vercel Now and to some extent AWS Lambda to be the biggest contenders in this, and neither of them supports health checks.

[Skn0tt]

Considering health-checks are indeed a thing for server-ful applications, we could think about enabling them just for serverful builds.

[flybayer]

Let's park this for now. It's very easy to add a custom api route for a health check endpoint if someone needs.

If serverful was our default, then I would for sure add this, but it's not :)