rreading-glasses: metadata for a book server whose own service was retired

It is a metadata service, not a library

The framing in the README is that this is a drop-in replacement for a now defunct metadata service, working with an existing installation of the book server, backwards compatible with the library, and taking seconds to enable or disable. That last property is the design brief. The original service was proprietary, so the README lays out what the replacement claims over it: faster, handles large authors, full coverage of the scraped book database or Hardcover, and it does not take months to load new books. The server itself is not part of this repository. What is here is the service the server calls to turn a title into metadata, plus the two forks configured to point at it.

Two binaries, two sources, and the Makefile builds both

The repository has a gr/ and a hardcover/ directory plus a cmd/ tree, and the Makefile makes the split explicit. build-gr produces bin/rggr from ./cmd/rggr, and build-hc produces bin/rghc from ./cmd/rghc, with build depending on both. The two serve targets show the shape of each one. The Goodreads flavoured server names its upstream explicitly:

go run ./cmd/rggr/main.go serve --verbose --upstream=www.goodreads.com --port 8080

The Hardcover flavoured server takes an API key as a bearer token:

go run ./cmd/rghc/main.go serve --verbose --port 8080 --hardcover-auth "Bearer $(HARDCOVER_API_KEY)"

One small thing to know if you script this: the second target is labelled serve-gc rather than serve-hc, so invoking make serve-hc will not find that target. The Makefile also wires lint through golangci-lint run with a ten minute timeout, tests through go test with the race detector, and coverage written to coverage.txt.

The Goodreads path is compatible, the Hardcover path is not

The README's comparison table is the decision document, so here is what it says. On summary quality, the Goodreads path is lower quality but backward compatible with existing installations, while Hardcover gives higher quality metadata and is not backward compatible, requiring a fresh installation. New releases and large authors are supported by both. On curation, the Goodreads metadata is described as not really editable by users, while Hardcover has an active community of librarians curating metadata as it appears on the website, unaffiliated with this project. On stability, the Goodreads path is stable and nearly identical in behaviour to the retired service, whereas Hardcover is beta and still loading data. Source code is public for both, against private for the original. In practice that means the Hardcover path can give you better data and a worse first week.

Two compose files, a Prometheus endpoint and a Grafana dashboard

Deployment support is checked in rather than described. The root holds docker-compose-gr.yml and docker-compose-hardcover.yml, so a full stack per backend is one file each. Metrics are not an afterthought: the dependency list includes github.com/IBM/pgxpoolprometheus and prometheus/client_golang, and grafana.json at the root is a provisioned dashboard. The Dockerfile shows the shape of the service itself, a two stage build on golang:1.26.0-alpine producing a single binary with CGO disabled, copied into gcr.io/distroless/static:nonroot:

FROM gcr.io/distroless/static:nonroot AS app
COPY --from=build /app/main /main
COPY --from=build /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

EXPOSE 8788
CMD ["/main"]

Note the exposed port is 8788, while the local development serve targets above use 8080. The release targets build multi architecture images for linux/amd64 and linux/arm64 and push them to docker.io/blampe/rreading-glasses with a latest tag for the Goodreads build and a hardcover tag for the other.

Hosted or self hosted, and the hosted one has 12k daily users

Two hosted instances are given: api.bookinfo.pro for the Goodreads flavoured data and hardcover.bookinfo.pro for the other, and the README says the service can also be self hosted. As of January 2026 the shared instance had around 12k daily users. That number is the reason the shared instance exists and also the reason to think carefully about it: this is a third party service returning the metadata your library is built on, and a fork's users are all pointed at it by default. Self hosting costs you one container and, from the go.mod dependency list, a Postgres connection pool, since pgx and pgxpoolprometheus are both required.

The original project is retired, so you are adopting a fork

The IMPORTANT notice at the top of the README is the governance statement and it comes before the introduction. The original project has been retired, and two community forks continue to work by using this metadata: pennydreadful/bookshelf, covering both the Goodreads and Hardcover sources, and Faustvii/Readarr, covering Goodreads. The maintainer says they do not endorse the vibe-coded Chaptarr project and points to FORKS.md for a comparison of forks, and asks developers who want to help to contribute to those forks or start their own. Practical consequence: your upgrade path runs through a fork, not the application you installed years ago, and the fork comparison is a file you should read before choosing.

Against leaving the fork pointed at nothing

The alternative is to run the fork without any replacement service, which is the state the table describes as unmaintained and half a year out of date, missing some of the most popular authors entirely. The intermediate option is to use a fork that ships its own metadata behaviour and skip this service altogether, accepting that large authors and new releases stay incomplete. The difference in approach is where the data comes from and who maintains the scraping. This project maintains a scraper against a third party site, which is faster and more complete and is also a dependency on that site continuing to serve it; a self maintained dataset has the reverse profile, slower to fill but stable to consume. Pick according to whether your library is a fixed collection or something you keep adding to.

Editorial conclusion

rreading-glasses is the right pick if you run that book server and want large author bibliographies and new releases that the retired service never had, and the Goodreads flavoured path is the one that keeps your existing library, because it is backward compatible with existing databases and Docker images while the Hardcover path needs a fresh database and a custom image. Before you commit, read FORKS.md and the comparison table at the top of the README, since the original project is retired and the community forks are the supported way in, and decide whether you want to depend on api.bookinfo.pro or run your own. Check the port before exposing it, because the image exposes 8788 with no authentication described. The last push was on 2026-10-16 and there are no GitHub releases, so the container tags rather than release notes are the versioning.

Frequently asked questions

Official sources

1. blampe/rreading-glasses on GitHub
2. Issues
3. License: GPL-3.0
4. README