You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If your schema is producing unexpected results, try using `clear=1` to eliminate the possibility
81
+
If your schema is producing unexpected results, try using `--clear` to eliminate the possibility
82
82
of a caching issue. If the issue is resolved, record exactly what you changed and [create an issue](https://github.com/silverstripe/silverstripe-graphql/issues/new).
Copy file name to clipboardExpand all lines: docs/en/01_getting_started/06_deploying_the_schema.md
+8-8
Original file line number
Diff line number
Diff line change
@@ -14,13 +14,13 @@ One way or another, you must get the `.graphql-generated/` and `public/_graphql/
14
14
15
15
### Single-server hosting solutions with simple deployments {#simple-single-server}
16
16
17
-
If you host your site on a single server and you always run `dev/build` during the deployment, then assuming you have set up permissions to allow the webserver to write to the `.graphql-generated/` and `public/_graphql/` folders, your GraphQL schema will be built for you as a side-effect of running `dev/build`. You don't need to do anything further. Note that if your schema is exceptionally large you may still want to read through the rest of the options below.
17
+
If you host your site on a single server and you always run `sake db:build` during the deployment, then assuming you have set up permissions to allow the webserver to write to the `.graphql-generated/` and `public/_graphql/` folders, your GraphQL schema will be built for you as a side-effect of running `sake db:build`. You don't need to do anything further. Note that if your schema is exceptionally large you may still want to read through the rest of the options below.
18
18
19
19
### Options for any hosting solution
20
20
21
21
#### Commit the schema to version control {#commit-to-vcs}
22
22
23
-
A simplistic approach is to build the schema in your local development environment and add the `.graphql-generated/` and `public/_graphql/` folders to your version control system. With this approach you would most likely want to disable schema generation at `dev/build`.
23
+
A simplistic approach is to build the schema in your local development environment and add the `.graphql-generated/` and `public/_graphql/` folders to your version control system. With this approach you would most likely want to disable schema generation with `sake db:build`.
24
24
25
25
This approach has the advantage of being very simple, but it will pollute your commits with massive diffs for the generated code.
26
26
@@ -29,19 +29,19 @@ This approach has the advantage of being very simple, but it will pollute your c
29
29
30
30
#### Explicitly build the schema during each deployment {#build-during-deployment}
31
31
32
-
Many projects will automatically run a `dev/build` whenever they deploy a site to their production environment. If that’s your case, then you can just let this process run normally and generate the `.graphql-generated/` and `public/_graphql/` folders for you. This will allow you to add these folders to your `.gitignore` file and avoid tracking the folder in your version control system.
32
+
Many projects will automatically run `sake db:build` whenever they deploy a site to their production environment. If that’s your case, then you can just let this process run normally and generate the `.graphql-generated/` and `public/_graphql/` folders for you. This will allow you to add these folders to your `.gitignore` file and avoid tracking the folder in your version control system.
33
33
34
-
Be aware that for this approach to work, the process executing the `dev/build` must have write access to create the folders (or you must create those folders yourself, and give write access for those folders specifically), and for multi-server environments a `dev/build` or `dev/graphql/build` must be executed on each server hosting your site after each deployment.
34
+
Be aware that for this approach to work, the process executing `sake db:build` must have write access to create the folders (or you must create those folders yourself, and give write access for those folders specifically), and for multi-server environments `sake db:build` or `sake graphql:build` must be executed on each server hosting your site after each deployment.
35
35
36
36
#### Use a CI/CD pipeline to build your schema {#using-ci-cd}
37
37
38
38
Projects with more sophisticated requirements or bigger schemas exposing more than 100 `DataObject` classes may want to consider using a continuous-integration/continuous-deployment (CI/CD) pipeline to build their GraphQL schema.
39
39
40
-
In this kind of setup, you would need to update your deployment script to run the `dev/graphql/build` command which builds the `.graphql-generated/` and `public/_graphql/` folders. In multi-server environments this must be executed on each server hosting your site.
40
+
In this kind of setup, you would need to update your deployment script to run the `sake graphql:build` command which builds the `.graphql-generated/` and `public/_graphql/` folders. In multi-server environments this must be executed on each server hosting your site.
If your site is hosted in an environment with multiple servers or configured to auto-scale with demand, there are some additional considerations. For example if you only generate the schema on one single server (i.e. via `dev/build` or `dev/graphql/build`), then the other servers won’t have a `.graphql-generated/` or `public/_graphql/` folder (or those folders will be empty if you manually created them).
44
+
If your site is hosted in an environment with multiple servers or configured to auto-scale with demand, there are some additional considerations. For example if you only generate the schema on one single server (i.e. via `sake db:build` or `sake graphql:build`), then the other servers won’t have a `.graphql-generated/` or `public/_graphql/` folder (or those folders will be empty if you manually created them).
45
45
46
46
#### Rely on "on-demand" schema generation on the first GraphQL request {#on-demand}
47
47
@@ -58,7 +58,7 @@ Our expectation is that on-demand schema generation will be performant for most
58
58
59
59
#### Build the schema during/before deployment and share it across your servers {#multi-server-shared-dirs}
60
60
61
-
If you have a particularly large schema, you may want to ensure it is always built before the first GraphQL request. It might make sense for you to sync your `.graphql-generated/` and `public/_graphql/` folders across all your servers using an EFS or similar mechanism. In that case you only need to run `dev/build` or `dev/graphql/build` on the server with the original folder - but bear in mind that this may have a performance impact.
61
+
If you have a particularly large schema, you may want to ensure it is always built before the first GraphQL request. It might make sense for you to sync your `.graphql-generated/` and `public/_graphql/` folders across all your servers using an EFS or similar mechanism. In that case you only need to run `sake db:build` or `sake graphql:build` on the server with the original folder - but bear in mind that this may have a performance impact.
62
62
63
63
### Performance considerations when building the GraphQL schema {#performance-considerations}
64
64
@@ -81,7 +81,7 @@ DataObjects in schema | Build time (ms) | Memory use (MB)
81
81
82
82
The process that is generating these folders must have write permissions to create the folder and to update existing files. If different users are used to generate the folders, then you must make sure that each user retains write access on them.
83
83
84
-
For example, if you manually run a `dev/build` under a foobar user, the folders will be owned by foobar. If your web server is running under the www-data user and you try to call`dev/graphql/build` in your browser, you might get an error if www-data doesn’t have write access.
84
+
For example, if you manually run `sake db:build` under a foobar user, the folders will be owned by foobar. If your web server is running under the www-data user and you try to visit`dev/graphql/build` in your browser, you might get an error if www-data doesn’t have write access.
Copy file name to clipboardExpand all lines: docs/en/08_architecture_diagrams.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,7 @@ The schema is generated during a build step, which generates code generation art
16
16
17
17

18
18
19
-
-**`/dev/graphql/build`**: This is the command that builds the schema. It also runs as a side effect of `dev/build` as a fallback. It accepts a `schema` parameter if you only want to build one schema.
19
+
-**`sake graphql:build`**: This is the command that builds the schema. It also runs as a side effect of `sake db:build` as a fallback. It accepts a `schema` parameter if you only want to build one schema.
20
20
21
21
-**Schema Factory**: This class is responsible for rebuilding a schema or fetching an existing one (i.e. as cached generated code)
0 commit comments