That makes a lot of sense for application servers when one controls the stack and can implement something like exponential backoff, and services are expected to already be running.
However it is not realistic to make sure all library dependencies used behave properly for more lambda-like jobs where a library/app like "wait for" is very useful since it reduces the backoff parameters that ops needs to know about, and reduces unnecessary errors in logs.
Take GCP Cloud SQL Auth Proxy [1] for example which simplifies the details of securely connecting to a database without exposing long-term credentials to app code. Typically for the audience that uses the proxy, it is run as a sidecar container in Kubernetes Pod and has a non-deterministic startup time in the range of a few seconds. There is no "depends_on" facility like in Docker (at least when I had to use it). Your batch job could potentially always fail if the proxy cannot establish a connection to the database before your minimal database migration container starts up. Building the backoff inside the migration app makes it more opaque for ops teams. Having this "wait for" run in a startup script before the main app allow ops to tune its parameters, such as through environment variables, so that the job behaves appropriately under health probes [2] for higher level backoffs. All of which can be configured without recompiling the main app code, or embedding the functionality in the first place.
Can you suggest to me one way for an API service to wait for a database to accept connections to run the database migrations without the API depending on the liveness of the database to start up?
I think the pragmatic answer is you should wait for your database to be live before starting up. One just wants to lean on the side of depending on a few critical services rather than all potentially-utlizied application services.
