module

package
v3.0.0 Latest Latest
Warning

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

Go to latest
Published: Nov 13, 2026 License: MIT Imports: 21 Imported by: 0

Documentation

Overview

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

This package defines opinionated, high-level module bundles that compose multiple lower-level feature modules into a single `signal.Option` suitable for inclusion in a go-signal 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 go-signal 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/v3/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 go-signal 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 go-signal 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