# Architecture

## Incoming Requests

<img src="../img/overview.png" style="display: inline-block;" alt="Overview" />

At a high level, all requests flow through [`ows-grass`](https://github.com/theorchard/ows-grass), which is a 
microservice used for authorizing/validating incoming requests at The Orchard.

Once a request from a client (such as [`orchardgo`](https://github.com/theorchard/orchardgo) or 
[`frontend-insights`](https://github.com/theorchard/frontend-insights)) is sent to 
[`ows-grass`](https://github.com/theorchard/ows-grass), it will verify whether the request is allowed to proceed, 
rewrite request headers, then forward the request to [`graphql-gateway`](https://github.com/theorchard/graphql-gateway).

If you have additional questions about Grass, please consult:
  * [The README for `ows-grass`](https://github.com/theorchard/ows-grass)
  * [#ows-grass](https://orcd.slack.com/archives/CHDEWNRC1) Slack channel
  * [#platform-team](https://orcd.slack.com/archives/CB507DH5E) Slack channel

## Federation

After a request is passed from [ows-grass](https://github.com/theorchard/ows-grass) to 
[graphql-gateway](https://github.com/theorchard/graphql-gateway), the gateway makes decisions about how to perform
resolution of the GraphQL request.

<img src="../img/federated.png" style="display: inline-block;" alt="Federated Services" />

You can think of [graphql-gateway](https://github.com/theorchard/graphql-gateway) as being a sort of dispatcher that 
understands the responsibilities of individual GraphQL services and how their capabilities support each other in order
to resolve a request. The [Apollo documentation on Federation](https://www.apollographql.com/docs/federation/) is a
great starting point to understand how the federation mechanism works, as well as why we're using it in the first place.