This documentation presents the Admin API and explains how to run a Dgraph database with GraphQL.
We’re overhauling Dgraph’s docs to make them clearer and more approachable. If you notice any issues during this transition or have suggestions, please let us know.
This article presents the Admin API and explains how to run a Dgraph database with GraphQL.
The simplest way to start with Dgraph GraphQL is to run the all-in-one Docker image.
That brings up GraphQL at localhost:8080/graphql
and localhost:8080/admin
,
but is intended for quickstart and doesn’t persist data.
Once you’ve tried out Dgraph GraphQL, you’ll need to move past the
dgraph/standalone
and run and deploy Dgraph instances.
Dgraph is a distributed graph database. It can scale to huge data and shard that data across a cluster of Dgraph instances. GraphQL is built into Dgraph in its Alpha nodes. To learn how to manage and deploy a Dgraph cluster, check our deployment guide.
GraphQL schema introspection is enabled by default, but you can disable it by
setting the --graphql
superflag’s introspection
option to false
(--graphql introspection=false
) when starting the Dgraph Alpha nodes in your
cluster.
Dgraph’s GraphQL runs in Dgraph and presents a GraphQL schema where the queries and mutations are executed in the Dgraph cluster. So the GraphQL schema is backed by Dgraph’s schema.
This means that if you have a Dgraph instance and change its GraphQL schema, the schema of the underlying Dgraph will also be changed!
When you start Dgraph with GraphQL, two GraphQL endpoints are served.
At /graphql
you’ll find the GraphQL API for the types you’ve added. That’s
what your app would access and is the GraphQL entry point to Dgraph. If you need
to know more about this, see the quick start and
schema docs.
At /admin
you’ll find an admin API for administering your GraphQL instance.
The admin API is a GraphQL API that serves POST and GET as well as compressed
data, much like the /graphql
endpoint.
Here are the important types, queries, and mutations from the admin
schema.
You’ll notice that the /admin
schema is very much the same as the schemas
generated by Dgraph GraphQL.
health
query lets you know if everything is connected and if there’s a
schema currently being served at /graphql
.state
query returns the current state of the cluster and group
membership information. For more information about state
see
here.config
query returns the configuration options of the cluster set at the
time of starting it.getGQLSchema
query gets the current GraphQL schema served at /graphql
,
or returns null if there’s no such schema.updateGQLSchema
mutation allows you to change the schema currently
served at /graphql
.Enterprise Features like ACL, binary backups are also available using the
GraphQL API at /admin
endpoint.
On first starting with a blank database:
/graphql
./admin
endpoint for getGQLSchema
returns
"getGQLSchema": null
./admin
endpoint for health
lets you know that no schema has
been added.You can validate a GraphQL schema before adding it to your database by sending
your schema definition in an HTTP POST request to the to the
/admin/schema/validate
endpoint, as shown in the following example:
Request header:
Request body:
This endpoint returns a JSON response that indicates if the schema is valid or
not, and provides an error if isn’t valid. In this case, the schema is valid, so
the JSON response includes the following message: Schema is valid
.
There are two ways you can modify a GraphQL schema:
/admin/schema
updateGQLSchema
mutation on /admin
While modifying the GraphQL schema, if you get errors like
errIndexingInProgress
, another operation is already running
or server is not ready
, please wait a moment and then retry the schema update.
/admin/schema
The /admin/schema
endpoint provides a simplified method to add and update
schemas.
To create a schema you only need to call the /admin/schema
endpoint with the
required schema definition. For example:
If you have the schema definition stored in a schema.graphql
file, you can use
curl
like this:
On successful execution, the /admin/schema
endpoint will give you a JSON
response with a success code.
updateGQLSchema
to add or modify a schemaAnother option to add or modify a GraphQL schema is the updateGQLSchema
mutation.
For example, to create a schema using updateGQLSchema
, run this mutation on
the /admin
endpoint:
Regardless of the method used to upload the GraphQL schema, on a black database, adding this schema
would cause the following:
/graphql
endpoint would refresh and serve the GraphQL schema generated
from type type Person { name: String }
.Person
type and name
predicate./admin
endpoint for health
would return that a schema is being served."schema": "type Person { name: String }"
and the
generated GraphQL schema for generatedSchema
(this is the schema served at
/graphql
)./admin
endpoint for getGQLSchema
would return the new schema.Given an instance serving the GraphQL schema from the previous section, updating the schema to the following
would change the GraphQL definition of Person
and result in the following:
/graphql
endpoint would refresh and serve the GraphQL schema generated
from the new type.dob
(predicate Person.dob: datetime .
is added, and Person.name
becomes
Person.name: string @index(regexp).
) and indexes are rebuilt to allow the
regexp search.health
is unchanged./admin
endpoint for getGQLSchema
would return the updated
schema.Adding a schema through GraphQL doesn’t remove existing data (it only removes indexes).
For example, starting from the schema in the previous section and modifying it with the initial schema
would have the following effects:
/graphql
endpoint would refresh to serve the schema built from this
type.dob
would no longer be accessible, and there would be no search
available on name
.name
in Dgraph would be removed.dob
in Dgraph would be left untouched (the predicate remains
and no data is deleted).This documentation presents the Admin API and explains how to run a Dgraph database with GraphQL.
We’re overhauling Dgraph’s docs to make them clearer and more approachable. If you notice any issues during this transition or have suggestions, please let us know.
This article presents the Admin API and explains how to run a Dgraph database with GraphQL.
The simplest way to start with Dgraph GraphQL is to run the all-in-one Docker image.
That brings up GraphQL at localhost:8080/graphql
and localhost:8080/admin
,
but is intended for quickstart and doesn’t persist data.
Once you’ve tried out Dgraph GraphQL, you’ll need to move past the
dgraph/standalone
and run and deploy Dgraph instances.
Dgraph is a distributed graph database. It can scale to huge data and shard that data across a cluster of Dgraph instances. GraphQL is built into Dgraph in its Alpha nodes. To learn how to manage and deploy a Dgraph cluster, check our deployment guide.
GraphQL schema introspection is enabled by default, but you can disable it by
setting the --graphql
superflag’s introspection
option to false
(--graphql introspection=false
) when starting the Dgraph Alpha nodes in your
cluster.
Dgraph’s GraphQL runs in Dgraph and presents a GraphQL schema where the queries and mutations are executed in the Dgraph cluster. So the GraphQL schema is backed by Dgraph’s schema.
This means that if you have a Dgraph instance and change its GraphQL schema, the schema of the underlying Dgraph will also be changed!
When you start Dgraph with GraphQL, two GraphQL endpoints are served.
At /graphql
you’ll find the GraphQL API for the types you’ve added. That’s
what your app would access and is the GraphQL entry point to Dgraph. If you need
to know more about this, see the quick start and
schema docs.
At /admin
you’ll find an admin API for administering your GraphQL instance.
The admin API is a GraphQL API that serves POST and GET as well as compressed
data, much like the /graphql
endpoint.
Here are the important types, queries, and mutations from the admin
schema.
You’ll notice that the /admin
schema is very much the same as the schemas
generated by Dgraph GraphQL.
health
query lets you know if everything is connected and if there’s a
schema currently being served at /graphql
.state
query returns the current state of the cluster and group
membership information. For more information about state
see
here.config
query returns the configuration options of the cluster set at the
time of starting it.getGQLSchema
query gets the current GraphQL schema served at /graphql
,
or returns null if there’s no such schema.updateGQLSchema
mutation allows you to change the schema currently
served at /graphql
.Enterprise Features like ACL, binary backups are also available using the
GraphQL API at /admin
endpoint.
On first starting with a blank database:
/graphql
./admin
endpoint for getGQLSchema
returns
"getGQLSchema": null
./admin
endpoint for health
lets you know that no schema has
been added.You can validate a GraphQL schema before adding it to your database by sending
your schema definition in an HTTP POST request to the to the
/admin/schema/validate
endpoint, as shown in the following example:
Request header:
Request body:
This endpoint returns a JSON response that indicates if the schema is valid or
not, and provides an error if isn’t valid. In this case, the schema is valid, so
the JSON response includes the following message: Schema is valid
.
There are two ways you can modify a GraphQL schema:
/admin/schema
updateGQLSchema
mutation on /admin
While modifying the GraphQL schema, if you get errors like
errIndexingInProgress
, another operation is already running
or server is not ready
, please wait a moment and then retry the schema update.
/admin/schema
The /admin/schema
endpoint provides a simplified method to add and update
schemas.
To create a schema you only need to call the /admin/schema
endpoint with the
required schema definition. For example:
If you have the schema definition stored in a schema.graphql
file, you can use
curl
like this:
On successful execution, the /admin/schema
endpoint will give you a JSON
response with a success code.
updateGQLSchema
to add or modify a schemaAnother option to add or modify a GraphQL schema is the updateGQLSchema
mutation.
For example, to create a schema using updateGQLSchema
, run this mutation on
the /admin
endpoint:
Regardless of the method used to upload the GraphQL schema, on a black database, adding this schema
would cause the following:
/graphql
endpoint would refresh and serve the GraphQL schema generated
from type type Person { name: String }
.Person
type and name
predicate./admin
endpoint for health
would return that a schema is being served."schema": "type Person { name: String }"
and the
generated GraphQL schema for generatedSchema
(this is the schema served at
/graphql
)./admin
endpoint for getGQLSchema
would return the new schema.Given an instance serving the GraphQL schema from the previous section, updating the schema to the following
would change the GraphQL definition of Person
and result in the following:
/graphql
endpoint would refresh and serve the GraphQL schema generated
from the new type.dob
(predicate Person.dob: datetime .
is added, and Person.name
becomes
Person.name: string @index(regexp).
) and indexes are rebuilt to allow the
regexp search.health
is unchanged./admin
endpoint for getGQLSchema
would return the updated
schema.Adding a schema through GraphQL doesn’t remove existing data (it only removes indexes).
For example, starting from the schema in the previous section and modifying it with the initial schema
would have the following effects:
/graphql
endpoint would refresh to serve the schema built from this
type.dob
would no longer be accessible, and there would be no search
available on name
.name
in Dgraph would be removed.dob
in Dgraph would be left untouched (the predicate remains
and no data is deleted).