Skip to content


The Architecture of QLoo can be understood as follows:


QLoo users interact via the Storage Layer API.

Declarative API Objects (Schemas and ResolverMaps) are written by the User (usually via qlooctl, the QLoo CLI) and polled by QLoo.

When QLoo detects an update to an API Object, it re-syncs its state to match the user specified configuration.

QLoo is composed of two components: a GraphQL service and an Envoy Proxy functioning as a sidecar. Rather than manually configuring its own sidecar, QLoo directs Envoy to connect to Gloo as its control plane, allowing QLoo to leverage Gloo's large set of HTTP routing features.

QLoo generates Gloo config objects in a self-service fashion, allowing Gloo to handle service discovery, Gloo plugin configuration, and configuration of Envoy HTTP Filters

Once Gloo has applied the desired configuration to Envoy, QLoo begins listening for incoming GraphQL requests, serving queries against the schema(s) provided by the user(s), and making requests via Envoy based on the configuration in the user-defined ResolverMaps