[feature] Configurable health check route #3577
Comments
|
This should be fairly easy to add. If the team is happy I'll submit a PR |
|
+1 this feature would be awesome to have. We have the same endpoint for health checks across all our services, and it would be awesome if we could avoid adding express just for one route :-) |
glasser
added a commit
to jutaz/apollo-server
that referenced
this issue
Oct 1, 2021
Our health check feature is kind of bizarre. It doesn't actually check that your GraphQL server can, well, serve GraphQL: it just checks if it can serve HTTP. And the way it matches path names doesn't work very well in contexts like Lambda where your whole server is often mounted at a sub-path. In many cases, it would be better to just run a trivial GraphQL operation as a health check. Additionally, it's strange that we let you configure the functionality of the health check in framework integrations, when it would be just as easy to define your own handler in your framework. I suppose it's nice that the health check exists in the batteries-included `apollo-server` package, since you do often want to have a health check (though again, running a GraphQL operation is often better) and that package doesn't let you tweak HTTP serving directly. And it's a bit of a shame that you can't set the health check path in that package. So, this PR: - Adds a `healthCheckPath` constructor option to the `apollo-server` package. You can also pass `null` to disable the health check, which wasn't previously possible with that package. This is based on work by @jutaz though the PR has been thoroughly reworked since then. - Reorganizes the `ApolloServer` reference docs so that the `apollo-server`-specific options are all together, and documents both the new option and the accidentally-undocumented `onHealthCheck`. - Rewrites the health check docs to encourage the use of GraphQL-level health checks, and to separate guidance around HTTP-level health checks in `apollo-server` (you can tweak it a bit if you want!) from HTTP-level health checks in framework integration packages (if you're doing something fancy just use the framework directly!) Fixes apollographql#3577. Fixes apollographql#5731.
glasser
added a commit
to jutaz/apollo-server
that referenced
this issue
Oct 8, 2021
Our health check feature is kind of bizarre. It doesn't actually check that your GraphQL server can, well, serve GraphQL: it just checks if it can serve HTTP. And the way it matches path names doesn't work very well in contexts like Lambda where your whole server is often mounted at a sub-path. In many cases, it would be better to just run a trivial GraphQL operation as a health check. Additionally, it's strange that we let you configure the functionality of the health check in framework integrations, when it would be just as easy to define your own handler in your framework. I suppose it's nice that the health check exists in the batteries-included `apollo-server` package, since you do often want to have a health check (though again, running a GraphQL operation is often better) and that package doesn't let you tweak HTTP serving directly. And it's a bit of a shame that you can't set the health check path in that package. So, this PR: - Adds a `healthCheckPath` constructor option to the `apollo-server` package. You can also pass `null` to disable the health check, which wasn't previously possible with that package. This is based on work by @jutaz though the PR has been thoroughly reworked since then. - Reorganizes the `ApolloServer` reference docs so that the `apollo-server`-specific options are all together, and documents both the new option and the accidentally-undocumented `onHealthCheck`. - Rewrites the health check docs to encourage the use of GraphQL-level health checks, and to separate guidance around HTTP-level health checks in `apollo-server` (you can tweak it a bit if you want!) from HTTP-level health checks in framework integration packages (if you're doing something fancy just use the framework directly!) Fixes apollographql#3577. Fixes apollographql#5731.
glasser
added a commit
to jutaz/apollo-server
that referenced
this issue
Oct 8, 2021
Our health check feature is kind of bizarre. It doesn't actually check that your GraphQL server can, well, serve GraphQL: it just checks if it can serve HTTP. And the way it matches path names doesn't work very well in contexts like Lambda where your whole server is often mounted at a sub-path. In many cases, it would be better to just run a trivial GraphQL operation as a health check. Additionally, it's strange that we let you configure the functionality of the health check in framework integrations, when it would be just as easy to define your own handler in your framework. I suppose it's nice that the health check exists in the batteries-included `apollo-server` package, since you do often want to have a health check (though again, running a GraphQL operation is often better) and that package doesn't let you tweak HTTP serving directly. And it's a bit of a shame that you can't set the health check path in that package. So, this PR: - Adds a `healthCheckPath` constructor option to the `apollo-server` package. You can also pass `null` to disable the health check, which wasn't previously possible with that package. This is based on work by @jutaz though the PR has been thoroughly reworked since then. - Reorganizes the `ApolloServer` reference docs so that the `apollo-server`-specific options are all together, and documents both the new option and the accidentally-undocumented `onHealthCheck`. - Rewrites the health check docs to encourage the use of GraphQL-level health checks, and to separate guidance around HTTP-level health checks in `apollo-server` (you can tweak it a bit if you want!) from HTTP-level health checks in framework integration packages (if you're doing something fancy just use the framework directly!) Fixes apollographql#3577. Fixes apollographql#5731.
glasser
added a commit
to jutaz/apollo-server
that referenced
this issue
Oct 8, 2021
Our health check feature is kind of bizarre. It doesn't actually check that your GraphQL server can, well, serve GraphQL: it just checks if it can serve HTTP. And the way it matches path names doesn't work very well in contexts like Lambda where your whole server is often mounted at a sub-path. In many cases, it would be better to just run a trivial GraphQL operation as a health check. Additionally, it's strange that we let you configure the functionality of the health check in framework integrations, when it would be just as easy to define your own handler in your framework. I suppose it's nice that the health check exists in the batteries-included `apollo-server` package, since you do often want to have a health check (though again, running a GraphQL operation is often better) and that package doesn't let you tweak HTTP serving directly. And it's a bit of a shame that you can't set the health check path in that package. So, this PR: - Adds a `healthCheckPath` constructor option to the `apollo-server` package. You can also pass `null` to disable the health check, which wasn't previously possible with that package. This is based on work by @jutaz though the PR has been thoroughly reworked since then. - Reorganizes the `ApolloServer` reference docs so that the `apollo-server`-specific options are all together, and documents both the new option and the accidentally-undocumented `onHealthCheck`. - Rewrites the health check docs to encourage the use of GraphQL-level health checks, and to separate guidance around HTTP-level health checks in `apollo-server` (you can tweak it a bit if you want!) from HTTP-level health checks in framework integration packages (if you're doing something fancy just use the framework directly!) Fixes apollographql#3577. Fixes apollographql#5731.
glasser
added a commit
that referenced
this issue
Oct 8, 2021
Our health check feature is kind of bizarre. It doesn't actually check that your GraphQL server can, well, serve GraphQL: it just checks if it can serve HTTP. And the way it matches path names doesn't work very well in contexts like Lambda where your whole server is often mounted at a sub-path. In many cases, it would be better to just run a trivial GraphQL operation as a health check. Additionally, it's strange that we let you configure the functionality of the health check in framework integrations, when it would be just as easy to define your own handler in your framework. I suppose it's nice that the health check exists in the batteries-included `apollo-server` package, since you do often want to have a health check (though again, running a GraphQL operation is often better) and that package doesn't let you tweak HTTP serving directly. And it's a bit of a shame that you can't set the health check path in that package. So, this PR: - Adds a `healthCheckPath` constructor option to the `apollo-server` package. You can also pass `null` to disable the health check, which wasn't previously possible with that package. This is based on work by @jutaz though the PR has been thoroughly reworked since then. - Reorganizes the `ApolloServer` reference docs so that the `apollo-server`-specific options are all together, and documents both the new option and the accidentally-undocumented `onHealthCheck`. - Rewrites the health check docs to encourage the use of GraphQL-level health checks, and to separate guidance around HTTP-level health checks in `apollo-server` (you can tweak it a bit if you want!) from HTTP-level health checks in framework integration packages (if you're doing something fancy just use the framework directly!) Fixes #3577. Fixes #5731. Co-authored-by: David Glasser <glasser@davidglasser.net>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hello awesome community!
I've just a tiny feature request.
Transform health check hard coded route to configurable route.
Currently the route is:
/.well-known/apollo/server-health.Please just add this in config 🙏
Thanks
Annexes
The text was updated successfully, but these errors were encountered: