## GraphQL federation on the edge

## GraphQL Federation: WHY?  - This is where all applications start - Perfect for simple application - Great to have a unified view of the data

## THE MONOLITH  - As the application grows, it starts to tangle more and more - Multiple teams working on it, with risk of type duplications, and moving slower

## BFF  - Good developer experience, domain separation - Duplicate effort, missing an unified view of the data

## Apollo Federation: Concepts  - The gateway is the entry point of each request and coordinates all the subgraphs - What is a subgraph? It's an instance of @apollo/subgraph. For example, In SE we got disco, se and assessment subgraphs

## Apollo Federation: Concepts  - In a federated architecture multiple subgraphs are federated into a single "supergraph" on the gateway - Easy to merge different types, but what about extending?

## Apollo Federation: Entities  - An entity is an object type that you define in one subgraph and you extend and reference in other subgraphs - In apollo, you can define an entity by using the `@key` directive

## Apollo Federation: Entities  - SE subgraph extends the type from Disco - SE needs also resolvers for the fields it provides

## Apollo Federation: Entities - Merged type in federation 

## Apollo Federation: Concepts 

## INNER WORKINGS  - Transforming the server to a subgraph, it will provide a _service and a _entities query 

## How data is queried  - We query for any type specifying the required keys and the typename - Use the `...on` sytax to query the fields of the specific type

## So are we using apollo federation? - Only on the subgraphs, the gateway is using @graphql-tools stitching - Reasons: smaller bundle size & less bloated, more powerful, runs smooths on workers - Compatible with apollo federation (not to be confused with the "old" stitching)

## How does graphql-tools stitching works? - Remote schemas that threats remote endpoints as if they were local executable schemas 

## How does graphql-tools stitching works? - Stitching schemas together will create a single schema like on apollo federation - Some minor conversion needed for the directives 

## Full stitching example 

## Pitfalls  - Think about the federation when designing queries and entities, you could easily trigger multiple subgraph requests

## Pitfalls - Avoid breaking changes, with federation you could break the graph for everyone - Be careful about enums, interfaces, inputs with the same names (we have some things in place to prevent this)

## Cloudflare

## Cloudflare workers: Pros - All the serverless goodies (autoscaling, easy deployments, global network) - 0ms cold start - Edge storage KV builtin - 1/10th the cost of other serverless platforms

## Cloudflare workers: Differences - Does not support lots of node builtin modules (so we had to reimplement things like apps insights) - Testing environments required some work (ie: kv mocks, call interception, cron tiggers...) - Still cutting edge, so more functionalities added, tooling changes, best practices not obvious etc.