But the key here is that their own library still goes through their API, not directly to their database. So that if you don't want to use their library you don't have to.
The failing pattern we've seen at my company is a client library, a server library, and a shared "model" library.
The issue that has happened time and time again is the model library ends up including classes and dependencies that either the server or client needs. This in turn leads to a frustrating experience of dependency wrangling when someone decides to throw in lombok, or kafka, or JavaFx into the model library for that 1 sweat `Pair` class the server is using internally. Or worse, they depend on a different model library because they need that one sweat enum. (Which in turn depends on other model classes, or server classes, or whatever).
If you do a client library, it should depend on practically nothing. The transport library (http client), authentication, and the data marshalling library. Nothing more. It should also be viewed as an example of how to work with your API and not the only way to work with the API. (Don't reinvent graphql... please!)
in fact the galactus team should actively _not_ publish a library for their API
doing so introduces a source-level coupling between consumers and producer, which the API was (presumably) created specifically to avoid
it takes an enormous amount of discipline to ensure that this kind of software is treated as "a reference implementation" rather than the canonical path
if an internal service API is too difficult to use without an API library, then this is a pretty good signal that something is wrong and needs to be fixed, imo