junction-api

API configuration types for Junction. Check out the Junction documentation for more information on what Junction is and how to get started.

lib.rs:

The core implementation for Junction - an xDS dynamically-configurable API load-balancer library.

• Getting Started

This crate allows you to build configuration for a dynamic HTTP client and export it to a control plane or pass it directly to an in-process client. Junction configuration is expressible as plain Rust structs, and can be serialized/deserialized with a [serde] compatible library.

Core Concepts

Service

The Junction API is built around the idea that you're always routing requests to a [Service], which is an abstract representation of a place you might want traffic to go. A [Service] can be anything, but to use one in Junction you need a way to uniquely specify it. That could be anything from a DNS name someone else has already set up to a Kubernetes Service in a cluster you've connected to Junction.

Routes

An HTTP Route is the client facing half of Junction, and contains most of the things you'd traditionally find in a hand-rolled HTTP client - timeouts, retries, URL rewriting and more. Routes match outgoing requests based on their method, URL, and headers. The [http] module's documentation goes into detail on how and why to configure a Route.

Backends

A Backend is a single port on a Service. Backends configuration gives you control over the things you'd normally configure in a reverse proxy or a traditional load balancer. See the [backend] module's documentation for more detail.

Crate Feature Flags

The following feature flags are available:

• The kube feature includes conversions from Junction configuration to and from Kubernetes objects. This feature depends on the kube and k8s-openapi crates. See the [kube] module docs for more detail.

• The xds feature includes conversions from Junction configuration to and from xDS types. This feature depends on the [xds-api][xds_api] crate.