module

package
v2.555.0 Latest Latest
Warning

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

Go to latest
Published: Jun 3, 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 service applications and are the defaults used by `go-service-template`.

Bundles

The exported bundles are intended as defaults:

  • Library: shared, transport-agnostic wiring.

  • Server: a typical server composition.

  • Client: a typical client composition.

Enablement and configuration

Most subsystems in go-service 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:

  • config.Module (config decoding + validation + common sub-config projections)
  • [Module] (logging/tracing/metrics wiring)
  • cache.Module (cache drivers/facade; optional by config)
  • feature.Module (OpenFeature client + optional provider registration)
  • hooks.Module (Standard Webhooks helpers; used by HTTP hook integrations)
  • sql.Module (SQL database wiring; currently PostgreSQL)
  • limiter.Module (rate limiter key map wiring)

Unlike Server, Client does not wire debug endpoints, transports, or a health server by default. Those can be added explicitly by composing additional modules on top of Client if needed.

This is the primary entrypoint for client-style applications built from `go-service-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 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)
  • [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 and related client/server integrations)
  • health.Module (health server wiring)

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