---
title: "FARP"
tagline: "Protocol"
language: "Go"
license: "Apache-2.0"
since: "2025"
canonical: "https://xraph.com/work/farp"
---

# FARP

The manifest format Octopus and Bastion consume. A service describes its own API surface across OpenAPI, AsyncAPI, gRPC, GraphQL, oRPC, Thrift and Avro, along with health and capability hints, and publishes it through Consul, etcd, Kubernetes, Redis or mDNS. FARP is the spec and the Go library. It deliberately does no routing itself.

## Install

```bash
go get github.com/xraph/farp
```

## What it is

FARP, the Forge API Gateway Registration Protocol, is how a service tells a gateway what it can do. It is a specification and a Go library: manifest data structures, schema generation, merging utilities, pluggable discovery, and lifecycle helpers.

It is deliberately not a gateway. No routing, no rate limiting, no traffic management. Drawing that line strictly is why two gateways as different as Octopus (Rust, standalone) and Bastion (Go, in-process) can both consume it.

## The manifest

A service publishes its API surface across seven formats, namely OpenAPI, AsyncAPI, gRPC, GraphQL, oRPC, Thrift and Avro, along with health information and capability hints such as whether an endpoint is safe to retry.

The generation providers build those from code, so the manifest comes from the same types that serve the requests. There is no second declaration to drift.

## Discovery

Pluggable: Consul, etcd, Kubernetes, Redis, mDNS, push-based, or your own. ServiceNode and GatewayNode handle the full lifecycle of registration, health reporting, schema publication and route updates, so a service mounts the FARP handlers on its own router and otherwise forgets about it.

## What it moved

> The service already knows its routes. Every line of gateway configuration is a second copy of that knowledge, racing the first.

The concrete wins: routes disappear correctly when an instance goes away; retry policy is declared by the service that knows whether an endpoint is idempotent; and a merged OpenAPI document exists without anyone maintaining it.

---

*Unpublished draft. Not peer reviewed and not submitted to a venue.*


## Anatomy

- **Manifest**: What a service serves, at which version, with which health semantics.
- **Derivation**: Routes as a pure function of the declared manifests.
- **Precedence**: Deterministic resolution when two services claim a path.

## Constraints and trade-offs

- (decision) Every route defined in two places will eventually disagree with itself. So it is defined once.
- (constraint) A manifest that fails validation removes the service from routing. It never partially applies.