In a Federation 1 subgraph schema, what does the extend keyword on a type mean?

## The problem the keyword existed to solve A federated graph is composed from several subgraph schemas that are written independently, usually in different repositories by different teams. Composition merges them into one supergraph schema. That merge has to answer one question about every type name it meets twice: are these two declarations of the same type, and if so, who is in charge of it? Apollo Federation 1 answered that with syntax. Exactly one subgraph *defined* a type. Every other subgraph that wanted to add fields to it *extended* it: ```graphql # Lockers subgraph — the owner type Locker @key(fields: "id") { id: ID! address: String! bankSize: Int! } # Reservations subgraph — a contributor extend type Locker @key(fields: "id") { id: ID! @external activeHolds: Int! } ``` The Reservations subgraph is not claiming `Locker`. It is saying: a type called `Locker` exists somewhere else, here is the key I will use to talk about instances of it, the key field `id` is not mine to resolve (`@external`), and I am adding one field, `activeHolds`, that I *do* resolve. Without `extend`, Federation 1 composition would have seen two definitions of `Locker` and treated the pair as a conflict. ## What it does not do Three misreadings are common enough to be worth naming. It is not a runtime instruction. Nothing is copied, fetched or proxied because of `extend`. It is a statement to the composer, consumed once when the supergraph is built; at request time the router works from the composed schema, which records field ownership directly. It does not import the owner's fields into this subgraph. The Reservations subgraph above cannot resolve `address`; it does not even know the field exists unless it re-declares it as `@external`. A contributor sees only what it writes down. It does not require a shared base schema file. The two documents are never concatenated. Each subgraph's SDL stands alone and is valid on its own — which is precisely why `extend` was needed as an explicit marker in the first place. This is also where the keyword differs from plain GraphQL type extensions, where `extend type` normally extends a definition present in the same document. ## Why Federation 2 dropped it Federation 2 changed the model from "one owner, several extenders" to "several declarations, composed". Every subgraph writes a plain `type Locker @key(fields: "id") { ... }` listing the key plus whatever fields it contributes, and composition merges them. Field-level ownership is still exactly one subgraph per field by default; what disappeared is the requirement to say in syntax which declaration came first. Two simplifications followed. The key fields in a contributing subgraph no longer need `@external`, because a subgraph that merely lists the key so it can be addressed is not making a competing claim on it. And `extend` itself became optional — a Federation 2 subgraph may still write it, and it composes identically to a plain definition, so migrations do not have to touch every type at once. ## What a reviewer should take from it If you open a subgraph and see `extend type` on a type, you are almost certainly looking at Federation 1-era SDL or at a schema migrated from it. That tells you something useful before you read another line: this file is a contributor, not the owner, so the fields you find in it are the only ones this service resolves, and anything else about that type lives in another repository. When you migrate the subgraph to Federation 2, dropping the keyword and the `@external` markers on the key fields is a mechanical change; the meaningful decisions — which subgraph resolves which field, and whether any field is resolved in more than one place — are made by the other ownership directives, not by this one.