SDL
SDL (Schema definition Language)
- instead of functions to create schema, use string based syntax for schemas
- easier to read
- can be composable
- supported by all tools
Scalar and Object Types
- describe resources used in queries/mutations
- Scalar types are built in primitives
- string
- int
- float
- boolean
- ID
- Object types are custom shapes with fields that are either scalar or other object types
- object type fields also describe any arguments and or validations
- types are target of all requests
Query and Mutation types
- Query type describes different queries your API is capable of
- Query operation is just name with possible arguments that eventually returns a type
- Mutation is exact same thing but with intent of mutating the DB vs just reading
- Query and mutations are basically like routes
Mutations
- graphql’s method of using put, post, delete methods
Fields in GraphQL
You can think of each field in a GraphQL query as a function or method of the previous type which returns the next type. In fact, this is exactly how GraphQL works. Each field on each type is backed by a function called theresolverwhich is provided by the GraphQL server developer. When a field is executed, the correspondingresolveris called to produce the next value.
If a field produces a scalar value like a string or number, then the execution completes. However if a field produces an object value then the query will contain another selection of fields which apply to that object. This continues until scalar values are reached. GraphQL queries always end at scalar values.
Architectural Use Cases
- GraphQL server with a connected database
- GraphQL server to integrate existing system
- Hybrid approach with connected DB and integration of existing system
Imperative data fetching
- Construct and send HTTP request (e.g with fetch in javascript)
- Receive and parse server response
- Store Data locally
- Display information in UI
Declarative Data fetching
- Describe data requirements
- displays information in UI
- everything else will be handled by graphql client (networking and storing data is abstracted away)
GraphQL Client Side
- used to solve UI related problems
- alternative to REST endpoints
- One single endpoint
- Send queries instead of reaching a particular endpoint
- REST API forces us to retrieve unnecessary data that we don’t need and make multiple calls
- GraphQL makes a specific query to get specific information you need
- Allows you to specific information and nested info without having to call server more than once
- Makes it easier/lightweight for frontend
- sits in front of any existing API
REST vs GraphQL
- GraphQL only has one endpoint and doesn’t need resource url + verb combo
- in REST, shape and size of data resource is determined by server, Graphql is determined by the query(request)
- in REST, multiple API calls need to be made to retrieve relational data, but GraphQL can start with entry resource and traverse all connections in one request
- in REST, shape of response determined by whom created server, in GraphQL the shape is determined by query
- in REST, single request will execute on controller on server but in GraphQL a request might execute many resolvers on server
Query
A type on a schema that defines operations clients can perform to access data that resembles the shape of other Types in the schema
Creating Query
- create Query type in schema using SDL
- Add fields to Query Type
- Create resolvers for that field
Creating Resolvers
- resolver names must match exact field name on schema types
- resolvers must return value type declared for matching field
- resolvers can be async
- can retrieve data from any source
Resolvers
- functions that are responsible for returning values for fields that exist on type in schema
- resolvers execution is dependent on incoming client query
Mutations
- type on schema that defines operations clients can perform to mutate data (create, update, delete)
- define mutation type on schema using SDL
- add fields for mutation type
- add arguments for mutation fields
- create resolvers for mutation fields
Enums
set of discrete values that can be used in place of scalars. An enum field must resolve to one of the values in the enum. Great for limitng a field to only a few different options
Interfaces
Abstract types that can’t be used as field values but used as foundations for explicit types
Unions
like interfaces but without an defined common fields among types. useful when need to access more than one disjoint type from one query
