module

package
v2.679.0 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Jul 16, 2026 License: MIT Imports: 18 Imported by: 0

Documentation

Overview

Package module provides top-level Fx module composition for go-service.

This package defines opinionated, high-level module bundles that compose multiple lower-level feature modules into a single `di.Option` suitable for inclusion in an Fx/Dig application graph. These bundles are the primary supported entrypoints for applications and are the defaults used by `go-service-template` for long-running servers and `go-client-template` for short-lived commands.

Bundles

The exported bundles are intended as defaults:

  • Library: shared, transport-agnostic foundation wiring. It does not decode service configuration by itself.

  • Server: a typical long-running server composition, including configuration, telemetry, transports, debug, and health wiring.

  • Client: a typical short-lived or batch/client composition, including configuration, telemetry, SQL/cache helpers, shared webhook helpers, and limiter key wiring.

Enablement and configuration

In Server and Client, most runtime subsystems are enabled/disabled by configuration, typically using optional pointer sub-configs (nil meaning "disabled"). These bundles wire constructors and registrations; whether a subsystem is active depends on the configuration supplied to the graph.

Start with Library, Server, and Client. Drop down to lower-level package composition only when you intentionally need custom wiring beyond what the standard bundles provide.

Index

Constants

This section is empty.

Variables

Client provides the standard Fx module composition for a go-service client.

It builds on Library and adds client-oriented wiring commonly needed by client processes and batch jobs:

Unlike Server, Client does not wire debug endpoints, transports, HTTP/gRPC health endpoints, or HTTP hook transport adapters by default. Those can be added explicitly by composing additional modules, such as transport.Module or github.com/alexfalkowski/go-service/v2/transport/http/hooks.Module, on top of Client if needed.

This is the primary entrypoint for client-style applications built from `go-client-template`.

Library provides a baseline Fx module intended for reuse by both servers and clients.

It wires common, transport-agnostic dependencies that many subsystems build upon:

Library does not wire config decoding, transports, servers, or request handling; it is intended to be a common foundation that both the Server and Client bundles build upon.

Server provides the standard Fx module composition for a go-service server.

It builds on Library and adds server-oriented wiring commonly needed by services:

  • debug.Module (debug server + diagnostic endpoints)
  • config.Module (config decoding + validation + common sub-config projections)
  • telemetry.Module (logging/tracing/metrics wiring)
  • cache.Module (cache drivers, cache facade, and package-level cache registration)
  • feature.Module (OpenFeature client + optional provider registration)
  • sql.Module (SQL database wiring; currently PostgreSQL)
  • limiter.Module (rate limiter key map wiring; transport modules typically construct limiters)
  • transport.Module (HTTP/gRPC transports, transport health endpoint registration, CloudEvents HTTP receiver hooks, and server lifecycle wiring)
  • health.Module (shared go-health server/observer lifecycle used by transport health endpoints)

Many of these subsystems are optional and are enabled/disabled by configuration (often via nil pointer sub-configs). This bundle wires constructors/registrations; runtime behavior depends on the config supplied to the graph.

This is the primary entrypoint for server applications built from `go-service-template`.

Functions

This section is empty.

Types

This section is empty.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL