- Clone
- Run:
cargo run -- temp/config.yaml
to run it locally
When no arguments are specified, it defaults the config path to ./config.json
cargo run ./temp/config.yaml
# or
cargo run ./temp/config.json
This document will describe the architecture of the GraphQL gateway written in Rust.
The GraphQL Gateway's source code is divided into four main modules:
-
config
: Handles the loading and parsing of the Gateway configuration files. -
endpoint
: The endpoint module is responsible for managing endpoints, their runtime, and processing incoming GraphQL requests. -
gateway
: The gateway module contains the engine which manages the lifecycle of the gateway server. -
source
: This module includes the source service that processes the GraphQL requests to their respective sources.
The config
module parses the configuration for the gateway from a specified file. The configuration includes server settings, logger settings, source definitions, and endpoint definitions. It supports both JSON
and YAML
formats for the schema.
The endpoint module defines the EndpointRuntime
struct which handles incoming requests for a specific endpoint. The EndpointRuntime
contains the endpoint's configuration and a reference to the service that will process its requests (upstream_service
). The call
method is used to process incoming requests.
The gateway module contains the main Gateway
struct that manages the lifecycle of the gateway server. When the Gateway is initialized, it creates a map of GraphQLSourceService
structs for each source defined in the configuration and a map of EndpointRuntime
structs for each endpoint. These maps are then used to route incoming requests to the correct service.
The source module contains the SourceService
trait that defines the interface for services that process GraphQL requests, this is there so that later on other Sources than plain GraphQL like loading Supergraph from Hive/Apollo Studio.
The graphql_source
module includes the GraphQLSourceService
which is an implementation of the SourceService
trait for GraphQL sources.
The plugins_manager
module includes the PluginsManager
which includes all of the available traits to implement representing the different kind of hooks that can be implemented and plugged in.
The startup process of the server is handled in src/main.rs
. The steps are as follows:
- Load the configuration file.
config.json
orconfig.yaml
- Instantiate a
PluginsManager
and add all of the necessary hooks. - Create a new
Gateway
instance using the loaded configuration and thePluginsManager
. - Create a new
Router
and attach a route for each endpoint defined in the gateway's configuration. - Start the server and await incoming requests.
- The router routes the request to the correct
EndpointRuntime
. - The endpoint's
call
method is invoked with the requestbody
as a parameter. - The call function creates a new
SourceRequest
from the body, which includes the body fields for a valid graphql request (query
,variables
, andoperationName
). - The
PluginsManager
'sexec_before_req(&mut req)
is invoked, which is a method that hides the implementation of looping over the registered before request plugins and executes them. - The
SourceRequest
is sent to the endpoint'supstream_service
. - The
upstream_service
processes theSourceRequest
and returns aSourceResponse
. - The
PluginsManager
'sexec_post_res(&mut req)
is invoked, which is a method that hides the implementation of looping over the registered post response plugins and executes them. - The
SourceResponse
is returned as the response to the client's request.
Errors are primarily handled through the SourceError
enum, which includes variants for different types of errors that can occur when processing a request.
tokio
for async runtimehyper
for networkaxum
as HTTP servertower
to composing services and building flows