API
In our API, each SQL table is reflected as a set of GraphQL types. At a high level, tables become types and columns/foreign keys become fields on those types.
By default, PostgreSQL table and column names are not inflected when reflecting GraphQL names. For example, an account_holder
table has GraphQL type name account_holder
. In cases where SQL entities are named using snake_case
, enable inflection to match GraphQL/Javascript conventions e.g. account_holder
-> AccountHolder
.
Individual table, column, and relationship names may also be manually overridden.
Primary Keys (Required)
Every table must have a primary key for it to be exposed in the GraphQL schema. For example, the following Blog
table will be available in the GraphQL schema as blogCollection
since it has a primary key named id
:
1 2 3 4 |
|
But the following table will not be exposed because it doesn't have a primary key:
1 2 3 4 |
|
QueryType
The Query
type is the entrypoint for all read access into the graph.
Node
The node
interface allows for retrieving records that are uniquely identifiable by a globally unique nodeId: ID!
field. For more information about nodeId, see nodeId.
SQL Setup
1 2 3 4 5 6 7 |
|
GraphQL Types
1 2 3 4 5 6 7 |
|
To query the node
interface effectively, use inline fragments to specify which fields to return for each type.
Example
1 2 3 4 5 6 7 8 9 10 11 12 |
|
1 2 3 4 5 6 7 8 9 |
|
Collections
Each table has top level entry in the Query
type for selecting records from that table. Collections return a connection type and can be paginated, filtered, and sorted using the available arguments.
SQL Setup
1 2 3 4 5 6 7 |
|
GraphQL Types
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
|
Connection types are the primary interface to returning records from a collection.
Connections wrap a result set with some additional metadata.
1 2 3 4 5 6 7 8 9 10 11 12 |
|
1 2 3 4 5 6 7 8 9 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 7 8 9 10 11 |
|
Note
The totalCount
field is disabled by default because it can be expensive on large tables. To enable it use a comment directive
Pagination
Keyset Pagination
Paginating forwards and backwards through collections is handled using the first
, last
, before
, and after
parameters, following the relay spec.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
Metadata relating to the current page of a result set is available on the pageInfo
field of the connection type returned from a collection.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
1 2 3 4 5 6 7 8 9 |
|
To paginate forward in the collection, use the first
and after
arguments. To retrieve the first page, the after
argument should be null or absent.
Example
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
To retrieve the next page, provide the cursor value from data.blogCollection.pageInfo.endCursor
to the after
argument of another query.
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
once the collection has been fully enumerated, data.blogConnection.pageInfo.hasNextPage
returns false.
To paginate backwards through a collection, repeat the process substituting first
-> last
, after
-> before
, hasNextPage
-> hasPreviousPage
Offset Pagination
In addition to keyset pagination, collections may also be paged using first
and offset
, which operates like SQL's limit
and offset
to skip offset
number of records in the results.
Note
offset
based pagination becomes inefficient the offset
value increases. For this reason, prefer cursor based pagination where possible.
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
Filtering
To filter the result set, use the filter
argument.
1 2 3 4 5 6 7 8 9 10 11 |
|
Where the <Table>Filter
type enumerates filterable fields and their associated <Type>Filter
.
1 2 3 4 5 6 7 8 9 10 11 12 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
1 2 3 4 5 6 7 8 9 10 |
|
1 2 3 4 |
|
The following list shows the operators that may be available on <Type>Filter
types.
Operator | Description |
---|---|
eq | Equal To |
neq | Not Equal To |
gt | Greater Than |
gte | Greater Than Or Equal To |
in | Contained by Value List |
lt | Less Than |
lte | Less Than Or Equal To |
is | Null or Not Null |
startsWith | Starts with prefix |
like | Pattern Match. '%' as wildcard |
ilike | Pattern Match. '%' as wildcard. Case Insensitive |
regex | POSIX Regular Expression Match |
iregex | POSIX Regular Expression Match. Case Insensitive |
contains | Contains. Applies to array columns only. |
containedBy | Contained in. Applies to array columns only. |
overlaps | Overlap (have points in common). Applies to array columns only. |
Not all operators are available on every <Type>Filter
type. For example, UUIDFilter
only supports eq
and neq
because UUID
s are not ordered.
Example: simple
1 2 3 4 5 6 7 8 9 10 11 12 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
Example: array column
The contains
filter is used to return results where all the elements in the input array appear in the array column.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
The contains
filter can also accept a single scalar.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
The containedBy
filter is used to return results where every element of the array column appears in the input array.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
The containedBy
filter can also accept a single scalar. In this case, only results where the only element in the array column is the input scalar are returned.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
The overlaps
filter is used to return results where the array column and the input array have at least one element in common.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
|
Example: and/or
Multiple filters can be combined with and
, or
and not
operators. The and
and or
operators accept a list of <Type>Filter
.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
Example: not
not
accepts a single <Type>Filter
.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
|
Example: nested composition
The and
, or
and not
operators can be arbitrarily nested inside each other.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
|
Example: empty
Empty filters are ignored, i.e. they behave as if the operator was not specified at all.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
|
Example: implicit and
Multiple column filters at the same level will be implicitly combined with boolean and
. In the following example the id: {eq: 1}
and name: {eq: "A: Blog 1"}
will be and
ed.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
|
This means that an and
filter can be often be simplified. In the following example all queries are equivalent and produce the same result.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
|
Be aware that the above simplification only works for the and
operator. If you try it with an or
operator it will behave like an and
.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
1 2 3 4 5 6 7 |
|
This is because according to the rules of GraphQL list input coercion, if a value passed to an input of list type is not a list, then it is coerced to a list of a single item. So in the above example or: {id: {eq: 1}, name: {eq: "A: Blog 2}}
will be coerced into or: [{id: {eq: 1}, name: {eq: "A: Blog 2}}]
which is equivalent to or: [and: [{id: {eq: 1}}, {name: {eq: "A: Blog 2}}}]
due to implicit and
ing.
Note
Avoid naming your columns and
, or
or not
. If you do, the corresponding filter operator will not be available for use.
The and
, or
and not
operators also work with update and delete mutations.
Ordering
The default order of results is defined by the underlying table's primary key column in ascending order. That default can be overridden by passing an array of <Table>OrderBy
to the collection's orderBy
argument.
1 2 3 4 5 6 7 8 9 10 11 |
|
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Example
1 2 3 4 5 6 7 8 9 10 11 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
Note, only one key value pair may be provided to each element of the input array. For example, [{name: AscNullsLast}, {id: AscNullFirst}]
is valid. Passing multiple key value pairs in a single element of the input array e.g. [{name: AscNullsLast, id: AscNullFirst}]
, is invalid.
MutationType
The Mutation
type is the entrypoint for mutations/edits.
Each table has top level entry in the Mutation
type for inserting insertInto<Table>Collection
, updating update<Table>Collection
and deleting deleteFrom<Table>Collection
.
SQL Setup
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
|
Insert
To add records to a collection, use the insertInto<Table>Collection
field on the Mutation
type.
SQL Setup
1 2 3 4 5 6 7 |
|
GraphQL Types
1 2 3 4 5 6 7 8 9 10 11 12 |
|
1 2 3 4 5 6 |
|
1 2 3 4 5 6 7 |
|
Where elements in the objects
array are inserted into the underlying table.
Example
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
Update
To update records in a collection, use the update<Table>Collection
field on the Mutation
type.
SQL Setup
1 2 3 4 5 6 7 |
|
GraphQL Types
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
1 2 3 4 5 6 |
|
1 2 3 4 5 6 7 8 9 |
|
Where the set
argument is a key value pair describing the values to update, filter
controls which records should be updated, and atMost
restricts the maximum number of records that may be impacted. If the number of records impacted by the mutation exceeds the atMost
parameter the operation will return an error.
Example
1 2 3 4 5 6 7 8 9 10 11 12 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
Delete
To remove records from a collection, use the deleteFrom<Table>Collection
field on the Mutation
type.
SQL Setup
1 2 3 4 5 6 7 |
|
GraphQL Types
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
1 2 3 4 5 6 7 8 9 10 |
|
1 2 3 4 5 6 7 |
|
Where filter
controls which records should be deleted and atMost
restricts the maximum number of records that may be deleted. If the number of records impacted by the mutation exceeds the atMost
parameter the operation will return an error.
Example
1 2 3 4 5 6 7 8 9 10 11 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
Concepts
nodeId
The base GraphQL type for every table with a primary key is automatically assigned a nodeId: ID!
field. That value, can be passed to the node entrypoint of the Query
type to retrieve its other fields. nodeId
may also be used as a caching key.
relay support
By default relay expects the ID
field for types to have the name id
. pg_graphql uses nodeId
by default to avoid conflicting with user defined id
columns. You can configure relay to work with pg_graphql's nodeId
field with relay's nodeInterfaceIdField
option. More info available here.
SQL Setup
1 2 3 4 |
|
GraphQL Types
1 2 3 4 5 |
|
Relationships
Relationships between collections in the Graph are derived from foreign keys.
One-to-Many
A foreign key on table A referencing table B defines a one-to-many relationship from table A to table B.
SQL Setup
1 2 3 4 5 6 7 8 9 10 11 |
|
GraphQL Types
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
|
Where blogPostCollection
exposes the full Query
interface to BlogPost
s.
Example
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
|
Many-to-One
A foreign key on table A referencing table B defines a many-to-one relationship from table B to table A.
SQL Setup
1 2 3 4 5 6 7 8 9 10 11 |
|
GraphQL Types
1 2 3 4 5 6 7 8 9 |
|
Where blog
exposes the Blog
record associated with the BlogPost
.
1 2 3 4 5 6 7 8 9 10 11 12 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
One-to-One
A one-to-one relationship is defined by a foreign key on table A referencing table B where the columns making up the foreign key on table A are unique.
SQL Setup
1 2 3 4 5 6 7 8 9 10 |
|
GraphQL Types
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 |
|
Example
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
Custom Scalars
Due to differences among the types supported by PostgreSQL, JSON, and GraphQL, pg_graphql
adds several new Scalar types to handle PostgreSQL builtins that require special handling.
JSON
pg_graphql
serializes json
and jsonb
data types as String
under the custom scalar name JSON
.
1 |
|
Example
Given the setup
1 2 3 4 5 6 7 |
|
1 2 3 4 5 |
|
The query
1 2 3 4 5 6 7 8 9 |
|
The returns the following data. Note that config
is serialized as a string
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
Use serialized JSON strings when updating or inserting JSON
fields via the GraphQL API.
JSON does not currently support filtering.
BigInt
PostgreSQL bigint
and bigserial
types are 64 bit integers. In contrast, JSON supports 32 bit integers.
Since PostgreSQL bigint
values may be outside the min/max range allowed by JSON, they are represented in the GraphQL schema as BigInt
s and values are serialized as strings.
1 2 3 4 5 6 7 8 9 10 11 12 |
|
Example
Given the setup
1 2 3 4 5 6 7 |
|
1 2 3 4 5 |
|
The query
1 2 3 4 5 6 7 8 9 10 |
|
The returns the following data. Note that id
is serialized as a string
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
BigFloat
PostgreSQL's numeric
type supports arbitrary precision floating point values. JSON's float
is limited to 64-bit precision.
Since a PostgreSQL numeric
may require more precision than can be handled by JSON, numeric
types are represented in the GraphQL schema as BigFloat
and values are serialized as strings.
1 2 3 4 5 6 7 8 9 10 11 12 |
|
Example
Given the SQL setup
1 2 3 4 5 6 7 |
|
The query
1 2 3 4 5 6 7 8 9 10 |
|
The returns the following data. Note that amount
is serialized as a string
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Opaque
PostgreSQL's type system is extensible and not all types handle all operations e.g. filtering with like
. To account for these, pg_graphql
introduces a scalar Opaque
type. The Opaque
type uses PostgreSQL's to_json
method to serialize values. That allows complex or unknown types to be included in the schema by delegating handling to the client.
1 2 3 4 5 6 |
|