|
| 1 | +--- |
| 2 | +title: Schemas and Types |
| 3 | +layout: ../_core/DocsLayout |
| 4 | +category: Learn |
| 5 | +permalink: /learn/schema/ |
| 6 | +next: /docs/schema/ |
| 7 | +--- |
| 8 | + |
| 9 | +### ToC |
| 10 | + |
| 11 | +* Type system |
| 12 | +* Type language |
| 13 | +* Basics (Schema, Objects & Fields) |
| 14 | +* Scalars & Enums |
| 15 | +* Lists & NonNull (mention error handling) |
| 16 | +* Interfaces & Unions |
| 17 | + |
| 18 | +### Type system |
| 19 | + |
| 20 | +If you've seen a GraphQL query before, you know that the GraphQL query language is basically about selecting fields on objects. So, for example, in the following query: |
| 21 | + |
| 22 | +```graphql |
| 23 | +{ |
| 24 | + hero { |
| 25 | + name |
| 26 | + appearsIn |
| 27 | + } |
| 28 | +} |
| 29 | +``` |
| 30 | + |
| 31 | +1. We start with the a special "root" object |
| 32 | +2. We select the `hero` field on that |
| 33 | +3. For each object returned by `hero`, we select the `name` and `appearsIn` fields |
| 34 | + |
| 35 | +So you can predict what the query will return without knowing that much about the server. But the question remains - what fields can we select? What kinds of objects might they return? What fields are available on those sub-objects? That's where the schema comes in. |
| 36 | + |
| 37 | +Every GraphQL service defines a set of types which completely describe the set of possible data you can query on that service. Then, when queries come in, they are validated and executed against that schema. |
| 38 | + |
| 39 | +### Type language |
| 40 | + |
| 41 | +GraphQL services can be written in any language. Since we can't rely on a specific programming language syntax, like JavaScript, to talk about GraphQL schemas, we'll define our own simple language. We'll use the "GraphQL schema language" - it's similar to the query language, and allows us to talk about GraphQL schemas in a language-agnostic way. |
| 42 | + |
| 43 | +### Objects and fields |
| 44 | + |
| 45 | +The most basic components of a GraphQL schema are object types, which just represent a kind of object you can fetch from your service, and what fields it has. In the GraphQL schema language, we might represent it like this: |
| 46 | + |
| 47 | +```graphql |
| 48 | +type Character { |
| 49 | + name: String! |
| 50 | + appearsIn: [Episode] |
| 51 | +} |
| 52 | +``` |
| 53 | + |
| 54 | +The language is pretty readable, but let's go over it so that we can have a shared vocabulary: |
| 55 | + |
| 56 | +- `Character` is a _GraphQL Object Type_, meaning it's a type with some fields. Most of the types in your schema will be object types. |
| 57 | +- `name` and `appearsIn` are _fields_ on the `Character` type. That means that `name` and `appearsIn` are the only fields that can appear in any part of a GraphQL query that operates on the `Character` type. |
| 58 | +- `String` is one of the built-in _scalar_ types - these are types that resolve to a single scalar object, and can't have sub-selections in the query. We'll go over scalar types more later. |
| 59 | +- `String!` means that the field is _non-nullable_, meaning that the GraphQL service promises to always give you a value when you query this field. In the type language, we'll represent those with an exclamation mark. |
| 60 | +- `[Episode]` represents an _array_ of `Episode` objects. This means that you can always expect an array, with zero or more items, when you query the `appearsIn` field. |
| 61 | + |
| 62 | +Now you know what a GraphQL object type looks like, and how to read the basics of the GraphQL type language. |
0 commit comments