A neat project, though. I think that this is best solved in the application itself (e.g. your server starts but returns HTTP errors while the database is unavailable), but being able to retrofit this behaviour into any existing application seems useful. Feels like something very similar should be built into tools like docker-compose.
In docker compose you can use `depends_on` [0] to define dependencies between containers and by default it will wait until a dependent container is "ready".
But you can also use a more verbose syntax to wait until a container is "healthy", as defined by its own healthcheck.
services:
web:
depends_on:
db:
condition: service_healthy
db:
image: postgres
For example, in the case of PostgreSQL, there is already a tool called pg_isready [0] to do this inside a healthcheck as you described.
services: postgres-db: image: postgres healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"]
application:
image: image
depends_on:
postgres-db:
condition: service_healthy
[0] https://www.postgresql.org/docs/current/app-pg-isready.html
See: https://f1bonacc1.github.io/process-compose/health/?h=port#r...
https://devenv.sh/ is one example that uses it to do just that.
Came here to make the same comment. 0 dependencies would mean/infer (at least, to me) a lack of any dependencies but that doesn't seem to be the case[1]. There are 30 matches for the word `dependencies`.
[1] - https://github.com/Stavrospanakakis/is_ready/blob/main/Cargo...
The title claims "0 dependencies", not "0 runtime dependencies" nor "0 compile-time dependencies". In other words, the word dependencies - by itself - is encompassing both runtime and compile-time dependencies.
Think of reading the title at face-value - but as if someone else had written it, with no exposure to your project, its use-case, behaviour, etc. - before it was read.
The "dependencies" point still stands, though, in that the term - generally - encompasses both.