External dependencies

Following the "centralize, don't abstract" principle, neither the framework nor any of its 14 standalone modules hide the libraries underneath them: their types flow freely through the public API. This page is the full inventory: what each module uses, at what version, and where its official documentation lives, in the same order as the module map. For a pattern-level breakdown, see Design patterns.

The point of the grouping below: adopting one module never drags in another module's dependencies. go get github.com/gp-system/errs links nothing but the standard library; go get github.com/gp-system/dbx/pg links pgx and its own OTel tracer, nothing from auth, mail or the other ten modules. Only where one module's own go.mod requires another (auth→httperr, events→queue+dbx, notify→mail+dbx) does adopting it transitively pull in that dependency's footprint too, and that is always a gp-system/* module, documented on its own overview page, never a surprise 3rd-party library.

errs

github.com/gp-system/errs. Zero third-party dependencies: only the standard library (errors, fmt, runtime, log/slog). See errs: Overview.

envconf

github.com/gp-system/envconf. See envconf: Overview.

httperr (+httperr/validate)

github.com/gp-system/httperr. See httperr: Overview.

dbx (+dbx/pg, dbx/bunx, dbx/seed)

github.com/gp-system/dbx. See dbx: Overview.

logx (+logx/monolog)

github.com/gp-system/logx. logx itself imports nothing beyond the standard library; only its logx/monolog subpackage requires github.com/gp-system/errs, so adopting logx alone (without the monolog formatter) pulls in nothing at all. See logx: Overview.

paginate

github.com/gp-system/paginate. No dependency beyond github.com/gp-system/errs (ErrInvalidCursor and friends). See paginate: Overview.

queue

github.com/gp-system/queue. See Queue.

events (+events/outbox, events/scheduler)

github.com/gp-system/events. Its own go.mod requires github.com/gp-system/queue and github.com/gp-system/dbx (an already-extracted module depending on two others), so adopting events pulls in both of their footprints; see events: Overview.

auth (+auth/rbac, auth/policy)

github.com/gp-system/auth. A leaf module: its own go.mod requires nothing beyond golang-jwt/jwt/v5, not even github.com/gp-system/errs. It returns plain sentinel errors and never writes a response; the framework's server package (which does depend on httperr) provides the RFC 9457 Problem rendering on top. See Authentication and Using auth standalone.

mail (+mail/smtp, mail/mjml)

github.com/gp-system/mail. See Mail: Overview.

notify (+notify/broadcast, notify/database)

github.com/gp-system/notify. Its own go.mod requires github.com/gp-system/mail and github.com/gp-system/dbx, so adopting notify pulls in both of their footprints; see Notifications: Overview.

storage (+storage/memory, storage/local, storage/storagetest)

github.com/gp-system/storage. The Driver/Disk/Manager core and its in-memory/local-disk drivers add nothing beyond OTel: no object-storage SDK is linked unless you also import the S3 driver below. See Storage: Overview.

minio-storage-driver

github.com/gp-system/minio-storage-driver, storage's S3-compatible driver as a standalone module (the declared package name is s3): its own repo and its own go.mod, so only projects that actually need S3 pay for this dependency. See S3.

telemetry (+telemetry/otelx, telemetry/sentryx)

github.com/gp-system/telemetry. Its own go.mod requires github.com/gp-system/errs (used by telemetry/sentryx to read a captured error's stack trace, code and public message), nothing else: the console slog.Handler is supplied by the caller through WithLogHandler, so logx is one option among many, not a dependency, see logx: Overview and Telemetry: Overview.

The framework itself

github.com/gp-system/framework: the CLI plus the four chassis packages (app, server, worker, realtime). These are on top of, not instead of, the module dependencies above: worker requires queue+events, realtime requires notify+auth+queue, and so on, per the module map.

Dev tooling

Where to next

• The design patterns behind these dependencies (why storage's Driver model or telemetry/sentryx is a wrapper and the rest aren't) are covered in Design patterns.
• Every module's environment variables are listed on Configuration.