The Architecture of Sqoop can be understood as follows:


Sqoop users interact via the Storage Layer API.

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

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

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

Sqoop 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, Sqoop 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