bdq / federation-demo Goto Github PK

This repository is a demo of using Apollo Federation to build a single schema on top of AWS Lambda. The Lambdas are located under the ./services folder and the Gateway that composes the overall schema is in the gateway service.

This demo showcases four partial schemas running as federated microservices. Each of these schemas can be accessed on their own and form a partial shape of an overall schema. The gateway fetches the service capabilities from the running services to create an overall composed schema which can be queried.

The Gateway service accesses the upstreams GQL endpoints by invoking the Lambda directly (removing the HTTP overhead of the AWS API gateway), this is achieved using a custom Apollo Gateway Data Source called: LambdaGraphQLDataSource.

To learn more about Apollo Federation, check out the docs

This demo uses the AWS-CDK to configure the following components:

• Gateway Lambda - The public facing GraphQL endpoint, connected to its own AWS API Gateway (fedapi) to make it HTTP accessible.

• Products, Reviews, Accounts, Inventory Lambdas - Partial GraphQL endpoints (which are frontend by the Gateway Lambda above). These are also connected to an AWS API Gateway (gqlapi) for testing purposes only.

Setup locally

npm install

Deploy using CDK

npm run deploy

The command above should output two API Gateway URL:

• gql-demo.gqlapiEndpointXXXXXXX - this is the individual GraphQL endpoints, accessible at /prod/accounts, /prod/products, /prod/reviews & /prod/inventory

• gql-demo.fedapiEndpointXXXXXX - this is the combined (federated) endpoint accessible at: /prod

The following query will hit all 4 microservices, returning a single compiled response.

{
  topProducts {
    name
    inStock
    reviews {
      body
      author {
        username
        name
      }
    }
  }
}

The X-Ray trace for this query looks like:

• Federated (sub) schemas shouldn't be exposed to the public (federation leaks too much info). This is easy to achieve with the deployment pattern here, as the Apollo Gateway invokes lambdas programmatically (not using the AWS API Gateway). I've included the gqlapi API for testing purposes only. If we want to expose sub schemas directly, we'd need to have a dedicated lambda handler for that, that doesn't use the federated schema methods.

• Apollo Gateway, is pretty smart:

  • It knows what sub-queries it can run in parallel (see Inventory & Reviews lambda invokes in the trace timing above).
  • It can deal with an individual sub-queries failing (if the endpoint is down etc), it returns as much of the result as it can (allong with the exceptions encountered).

• Invoking a lambda seems to have 10ms to 20ms of overhead, in the x-ray trace above - the Gateway lambda takes 31ms to invoke the Products. However, if you look at the Products lambda breakdown, it only takes 17ms to process.

• Using the Lambda Power Tuning tool is a great way to balance performance vs cost of a lambda. See Product Lambda Tuning result for example.