Module client 

Available on crate feature client only.

Reading configuration from a config server.

The other half of this crate, behind the client feature: a RemoteSource that fetches GET /{application}/{profile} and hands the document to the engine, exactly as an etcd or a Vault source does. The two halves live in one crate so that they are tested against each other — every test in tests/client.rs drives this against the real router rather than against a fixture of what the router is believed to return.

use std::time::Duration;
use dynamic_config_server::client::ConfigServer;

let source = ConfigServer::new("https://config.internal", "billing", "prod")
    .with_token(std::env::var("CONFIG_TOKEN").unwrap_or_default())
    .with_timeout(Duration::from_secs(5));

What it does not do

It does not subscribe. GET /{application}/{profile}/stream carries a generation, and a client that follows it calls refresh_remote() when the number moves — a loop of a dozen lines that belongs to whoever owns the reload cadence. Building it in would mean this crate owning a task, a backoff and a reconnect policy that the application is better placed to choose; what this crate owes is the half that is fiddly to get right, which is the bounded, deadline-covered, credential-carrying fetch below.

It does not verify provenance. The document arrives as JSON with no signature, so a client trusts the server exactly as far as TLS and the bearer token take it. A deployment that needs more should read from the store the server reads from.

Structs

ConfigServer

A RemoteSource reading one application-and-profile from a config server.