lighthouse-graphql 0.6.0 → 0.7.0

data/docs/filtering-and-ordering.md

@@ -37,12 +37,14 @@ Override it with `key:` — above, `minAge` filters the `age` column.
 
 ### `@where` operators
 
-`@where(operator: "...")` supports the same operator vocabulary as
-`@whereConditions`:
+`@where(operator: "...")` takes these operators:
 
 `EQ`, `NEQ`, `GT`, `GTE`, `LT`, `LTE`, `IN`, `NIN`, `CONTAINS`, `STARTS_WITH`,
 `ENDS_WITH`, `IS_NULL`, `IS_NOT_NULL`.
 
+They are not `@whereConditions`' `SQLOperator` values, which follow PHP
+Lighthouse (see below).
+
 ```graphql
 type Query {
   events(
@@ -52,38 +54,192 @@ type Query {
 }
 ```
 
-## Ordering — `@orderBy`
+## Ordering
+
+`@orderBy` works as in PHP Lighthouse. On an argument, the client picks the
+order. On a field, the order is fixed.
+
+### Client-controlled ordering
+
+Write the argument's type as `_`. Lighthouse then generates an input that
+takes the allowed columns as an enum, together with the `SortOrder` enum:
+
+```graphql
+type Query {
+  posts(orderBy: _ @orderBy(columns: ["posted_at", "title"])): [Post!]! @all
+}
+```
+
+Lighthouse generates this from it:
+
+```graphql
+"Order by clause for Query.posts.orderBy."
+input QueryPostsOrderByOrderByClause {
+  "The column that is used for ordering."
+  column: QueryPostsOrderByColumn!
+
+  "The direction that is used for ordering."
+  order: SortOrder!
+}
+
+"Allowed column names for Query.posts.orderBy."
+enum QueryPostsOrderByColumn {
+  POSTED_AT @enum(value: "posted_at")
+  TITLE @enum(value: "title")
+}
+
+"Directions for ordering a list of records."
+enum SortOrder {
+  ASC
+  DESC
+}
+```
+
+The argument becomes `orderBy: [QueryPostsOrderByOrderByClause!]`. The client
+passes a list of clauses, which apply in turn:
+
+```graphql
+{
+  posts(orderBy: [{ column: POSTED_AT, order: DESC }, { column: TITLE, order: ASC }]) {
+    title
+  }
+}
+```
+
+The names follow `<Type><Field><Argument>`: `QueryPostsOrderBy…` for
+`Query.posts(orderBy:)`. Each clause needs an `order`. Without `columns:`,
+`columnsEnum:` or `relations:`, the argument takes the shared `OrderByClause`,
+whose `column` is a `String!`. That allows any column, so restrict the columns
+whenever clients are not trusted.
 
-Sort the result by one or more columns. The client passes a list of clauses, each
-with a `column` and an `order` (`ASC`/`DESC`); clauses apply in order.
+To reuse one enum on several fields, name it with `columnsEnum:`. Its
+`@enum(value:)` gives each value's column:
 
 ```graphql
 type Query {
-  users(orderBy: [OrderByClause!] @orderBy): [User!]! @all
+  allPosts(orderBy: _ @orderBy(columnsEnum: "PostColumn")): [Post!]! @all
+  paginatedPosts(orderBy: _ @orderBy(columnsEnum: "PostColumn")): [Post!]! @paginate
+}
 
-  # query:
-  # users(orderBy: [{ column: NAME, order: ASC }, { column: CREATED_AT, order: DESC }])
+enum PostColumn {
+  POSTED_AT @enum(value: "posted_at")
+  TITLE @enum(value: "title")
 }
 ```
 
-`@orderBy` also accepts `{ field:, direction: }` clause shapes, so it slots into
-existing client conventions.
+`columns:` and `columnsEnum:` cannot be used together.
+
+### Ordering by a relation
+
+`relations:` lets the client order by an aggregate of a relation. Without
+columns, that aggregate is `COUNT`. With a relation's own `columns:` (or
+`columnsEnum:`), it is `AVG`, `MIN`, `MAX`, `SUM` or `COUNT` of one of them:
+
+```graphql
+type Query {
+  users(
+    orderBy: _ @orderBy(columns: ["name"], relations: [{ relation: "posts" }, { relation: "tasks", columns: ["difficulty"] }])
+  ): [User!]! @all
+}
+```
+
+```graphql
+{
+  users(
+    orderBy: [
+      { posts: { aggregate: COUNT }, order: DESC }
+      { tasks: { aggregate: MAX, column: DIFFICULTY }, order: DESC }
+      { column: NAME, order: ASC }
+    ]
+  ) {
+    name
+  }
+}
+```
+
+The argument then takes `[QueryUsersOrderByRelationOrderByClause!]`. Each clause
+names exactly one of `column` and the relations. Each relation has an input of
+its own, `QueryUsersOrderByPosts` / `QueryUsersOrderByTasks`, with the
+`OrderByRelationAggregateFunction` or
+`OrderByRelationWithColumnAggregateFunction` enum.
+
+The aggregate is computed once per record, in a `LEFT JOIN` on a grouped
+subquery. A record with no related records is still listed, with a `COUNT` of 0.
+This also works on a relationship field (`posts(orderBy: _ @orderBy(...)): [Post!]! @hasMany`),
+including when its pages are batched.
+
+### Predefined ordering
+
+On a field, `@orderBy(column:, direction:)` always orders the result, whatever
+the client sends:
+
+```graphql
+type Query {
+  latestUsers: [User!]! @all @orderBy(column: "created_at", direction: DESC)
+}
+```
+
+A field's `@orderBy` applies after the client's `orderBy` argument, so on a
+field with both, it breaks ties:
+
+```graphql
+type Query {
+  posts(orderBy: _ @orderBy(columns: ["title"])): [Post!]! @paginate @orderBy(column: "created_at", direction: DESC)
+}
+```
+
+An argument written with a type of its own, such as `orderBy: [MyClause!] @orderBy`,
+keeps that type. Its input needs a `column` and an `order`.
 
 ## Complex where conditions
 
-For a flexible, client-controlled `WHERE` builder, use `@whereConditions`.
-Lighthouse generates the input and column-enum types automatically — you only
-declare the allowed columns.
+`@whereConditions` works as in PHP Lighthouse. The client builds the `WHERE`
+clause itself, from conditions joined by `AND` and `OR`, and from `HAS` checks on
+relations. Write the argument's type as `_`, and declare the allowed columns:
 
 ```graphql
 type Query {
   people(
-    where: _ @whereConditions(columns: ["age", "type", "height"])
+    where: _ @whereConditions(columns: ["age", "type", "haircolour", "height"])
   ): [Person!]! @all
 }
 ```
 
-Clients can then build dynamic conditions with `AND` / `OR` / operators:
+Lighthouse generates these types for `Query.people(where:)`:
+
+```graphql
+"Dynamic WHERE conditions for the `where` argument of Query.people."
+input QueryPeopleWhereWhereConditions {
+  column: QueryPeopleWhereColumn
+  operator: SQLOperator = EQ
+  value: Mixed
+  AND: [QueryPeopleWhereWhereConditions!]
+  OR: [QueryPeopleWhereWhereConditions!]
+  HAS: QueryPeopleWhereWhereConditionsRelation
+}
+
+"Allowed column names for Query.people.where."
+enum QueryPeopleWhereColumn {
+  AGE @enum(value: "age")
+  TYPE @enum(value: "type")
+  HAIRCOLOUR @enum(value: "haircolour")
+  HEIGHT @enum(value: "height")
+}
+
+input QueryPeopleWhereWhereConditionsRelation {
+  relation: String!
+  operator: SQLOperator = GTE
+  amount: Int = 1
+  condition: QueryPeopleWhereWhereConditionsHasCondition
+}
+```
+
+`QueryPeopleWhereWhereConditionsHasCondition` has the same fields as the
+conditions input, but its `column` is a `String`. It filters the related
+records, whose columns are not the model's.
+
+The conditions of one level all hold. An `AND` list is a group whose conditions
+all hold, and an `OR` list is a group where at least one does:
 
 ```graphql
 {
@@ -91,38 +247,182 @@ Clients can then build dynamic conditions with `AND` / `OR` / operators:
     where: {
       AND: [
         { column: AGE, operator: GT, value: 37 }
-        { OR: [
-            { column: TYPE, value: "Actor" }
+        { column: TYPE, value: "Actor" }
+        {
+          OR: [
+            { column: HAIRCOLOUR, value: "red" }
             { column: HEIGHT, operator: GTE, value: 150 }
-        ] }
+          ]
+        }
+      ]
+    }
+  ) {
+    name
+  }
+}
+```
+
+```graphql
+{
+  people(
+    where: {
+      AND: [
+        { column: HAIRCOLOUR, operator: IS_NULL }
+        { column: HEIGHT, operator: BETWEEN, value: [150, 200] }
       ]
     }
-  ) { name }
+  ) {
+    name
+  }
 }
 ```
 
-The generated `SQLOperator` enum covers `EQ`, `NEQ`, `GT`, `GTE`, `LT`, `LTE`,
-`IN`, `NIN`, `CONTAINS`, `STARTS_WITH`, `ENDS_WITH`, `IS_NULL`, `IS_NOT_NULL`.
+`where: null` filters nothing.
+
+### Operators
 
-### `@whereHasConditions`
+The generated `SQLOperator` enum has PHP Lighthouse's operators. `IS_NULL` and
+`IS_NOT_NULL` take no value. Any other operator needs one, or the query fails
+with "Did not receive a value to match the WhereConditions for column …".
 
-Filter by the existence of a related record, with conditions applied to the
-relation:
+| Operator | SQL | `value` |
+| --- | --- | --- |
+| `EQ` (default) | `=` | a scalar |
+| `NEQ` | `!=` | a scalar |
+| `GT`, `GTE`, `LT`, `LTE` | `>`, `>=`, `<`, `<=` | a scalar |
+| `LIKE`, `NOT_LIKE` | `LIKE`, `NOT LIKE` | a pattern: `"%Rails%"` |
+| `IN`, `NOT_IN` | `IN`, `NOT IN` | a list |
+| `BETWEEN`, `NOT_BETWEEN` | `BETWEEN`, `NOT BETWEEN` | `[from, to]` |
+| `IS_NULL`, `IS_NOT_NULL` | `IS NULL`, `IS NOT NULL` | none |
+
+### Related records — `HAS`
+
+`HAS` keeps the records that have related records. By default, at least one,
+which is `operator: GTE, amount: 1`. Its `condition` filters the related
+records, on their own table's columns:
+
+```graphql
+{
+  users(where: { HAS: { relation: "posts", amount: 3, condition: { column: "published", value: true } } }) {
+    name
+  }
+}
+```
+
+`relation` names an association of the model (`posts`, or `blogPosts` for
+`blog_posts`). `{ relation: "posts", operator: LT, amount: 1 }` keeps the users
+with no posts. A `condition` can hold its own `HAS`, which checks the related
+records' relations.
+
+### Without `columns:`
+
+Without `columns:` or `columnsEnum:`, the argument takes the shared
+`WhereConditions` input, whose `column` is a `String`. A column a client
+names there must be an identifier or `table.column`, optionally followed by a
+[JSON path](#json-columns) (`meta->tags`). Anything else fails with "Column names
+may contain only alphanumerics or underscores, optionally a table and a JSON path
+(posts.meta->tags), and may not begin with a digit, got: …". Any column of the
+table can still be filtered on, so declare the allowed columns when clients are
+not trusted.
+
+### JSON columns
+
+As in PHP Lighthouse (and Laravel), a column can point into a JSON document with
+`->`: `meta->series`, `meta->author->name`, and `meta->tags->0` for an array
+element. `@whereConditions`, `@whereHasConditions` and `@orderBy`, on an argument
+or on a field, take it in `columns:` like any column:
 
 ```graphql
 type Query {
-  users(
-    hasPosts: _ @whereHasConditions(columns: ["status"])
-  ): [User!]! @all
+  posts(
+    where: _ @whereConditions(columns: ["title", "meta->series", "meta->rank"])
+    orderBy: _ @orderBy(columns: ["meta->rank"])
+  ): [Post!]! @all
+  rankedPosts: [Post!]! @all @orderBy(column: "meta->rank", direction: DESC)
+}
+```
+
+The generated enum names the path with `__` (`META__SERIES`, `META__AUTHOR__NAME`):
+
+```graphql
+{
+  posts(
+    where: { AND: [{ column: META__SERIES, value: "graphql" }, { column: META__RANK, operator: GT, value: 9 }] }
+    orderBy: [{ column: META__RANK, order: DESC }]
+  ) {
+    title
+  }
+}
+```
+
+The value at the path is compiled for the database: `"meta"->>'series'` on
+PostgreSQL, `JSON_UNQUOTE(JSON_EXTRACT(meta, '$."series"'))` on MySQL, and
+`json_extract(meta, '$."series"')` on SQLite. Unlike Laravel, it behaves the same
+on all three:
+
+- A number compares as a number (`meta->rank GT 9` keeps 10), and a boolean as a
+  boolean. `LIKE` compares the text.
+- `IS_NULL` holds for a missing key and for a JSON `null`.
+- `@orderBy` orders by the JSON value, so numbers sort numerically.
+
+### A custom handler
+
+`handler:` names a class, looked up in `Config.namespaces[:builders]` (`Builders::`).
+It applies the conditions instead of Lighthouse:
+
+```graphql
+type Query {
+  people(where: _ @whereConditions(columns: ["age"], handler: "PeopleConditions")): [Person!]! @all
 }
 ```
 
-The relation is inferred from the `has<Relation>` argument name (`hasPosts` →
-`posts`), or specified with `relation:`.
+```ruby
+class Builders::PeopleConditions
+  # `conditions` as the client sent them: { column: "age", operator: "GT", value: 37, and: [...], ... }
+  def self.call(relation, conditions)
+    relation.where(...)
+  end
+end
+```
+
+Use `"Class@method"` to call another method.
+
+## `@whereHasConditions`
+
+`@whereHasConditions` keeps the records that have at least one related record
+matching the client's conditions. The input is the same as `@whereConditions`',
+applied to the relation:
+
+```graphql
+type Query {
+  people(hasRole: _ @whereHasConditions(columns: ["name", "access_level"])): [Person!]! @all
+}
+```
+
+```graphql
+{
+  people(hasRole: { column: ACCESS_LEVEL, operator: GTE, value: 5 }) {
+    name
+  }
+}
+```
+
+The relation is the argument's name without `has` (`hasRole` → `role`, and
+`roles` if the model has that instead). You can also name it with `relation:`:
+`work: _ @whereHasConditions(relation: "tasks")`. The generated input is
+`QueryPeopleHasRoleWhereHasConditions`.
+
+`hasRole: {}` keeps the people with any role. `hasRole: null` filters nothing.
+
+The client's conditions are an argument directive like any other, so they also
+work on `@paginate`, `@count`, `@first`, the relationship directives, and
+`resolve_info.enhance_builder`. The argument can have any name.
 
 ## How columns are resolved
 
 Column names from enums (e.g. `CREATED_AT`) and arguments (`minAge`) are mapped to
 real columns through one central rule (`Lighthouse::Support::Naming`): ALLCAPS
 enum keys are downcased, and camelCase is converted to snake_case. This keeps
-client-facing GraphQL idiomatic while matching your Rails schema.
+client-facing GraphQL idiomatic while matching your Rails schema. An enum
+value's `@enum(value:)` names its column directly, as in the enums `@orderBy`
+and `@whereConditions` generate.

data/docs/generators.md

@@ -40,7 +40,7 @@ And it adds Lighthouse's own:
 | Option | Effect |
 | --- | --- |
 | `--schema=ApiSchema` | Which graphql-ruby schema class to adopt, and its name when `graphql:install` has to run |
-| `--sdl-folder=app/schema` | Where the `.graphql` files live (default `graphql`); sets `config.sdl_folder` |
+| `--schema-path=app/schema/schema.graphql` | The schema's entrypoint, which imports the other `.graphql` files (default `graphql/schema.graphql`); sets `config.schema_path` |
 | `--subscriptions` | Write `Subscriptions::BaseSubscription` and name it in `base_types` |
 | `--skip-controller` | Leave graphql-ruby's controller as it is, and add no route — for apps that serve GraphQL themselves |
 | `--skip-ide` | No `graphql.config.yml` or `.gitignore` entries |

data/docs/getting-started.md

@@ -37,10 +37,10 @@ graphql-ruby wrote, and adds Lighthouse's own:
 | `app/graphql/types/base_*.rb`, `resolvers/base_resolver.rb`, `mutations/base_mutation.rb` | graphql-ruby's base classes. `BaseObject`, `BaseInterface`, `BaseUnion` and `BaseScalar` include `Lighthouse::GraphQL::Type` |
 | `app/controllers/graphql_controller.rb` | graphql-ruby's controller, replaced by one including `Lighthouse::GraphQL::Controller` |
 | `config/initializers/lighthouse.rb` | Every [configuration](configuration.md) option, commented out at its default |
-| `graphql/schema.graphql` | A starter schema (`user` via `@find`, `users` via `@paginate`) that assumes a `User` model — skipped when the folder already holds `.graphql` files |
+| `graphql/schema.graphql` | The schema's entrypoint: a starter schema (`user` via `@find`, `users` via `@paginate`) that assumes a `User` model. Skipped when the file exists |
 | `graphql.config.yml` | IDE configuration — see [IDE support](#ide-support) |
 
-`--schema=ApiSchema`, `--sdl-folder=app/schema`, `--subscriptions`,
+`--schema=ApiSchema`, `--schema-path=app/schema/schema.graphql`, `--subscriptions`,
 `--skip-controller` and `--skip-ide` change what it does. Rerunning it changes
 nothing, and a controller the app changed is kept.
 [generators.md](generators.md) has the details, every generator Lighthouse has, and
@@ -48,8 +48,8 @@ which of graphql-ruby's `graphql:*` generators fit a Lighthouse app.
 
 ## 1. Write your schema (SDL)
 
-By default Lighthouse loads every `*.graphql` file under `RAILS_ROOT/graphql`,
-sorted by path and concatenated. Split your schema however you like:
+Lighthouse reads the schema from one entrypoint, `RAILS_ROOT/graphql/schema.graphql`
+(`config.schema_path`), as PHP Lighthouse does:
 
 ```graphql
 # graphql/schema.graphql
@@ -70,6 +70,32 @@ argument (the `@eq` makes `id` a filter). Lighthouse infers the model from the
 field's return type name (`User`), or you can be explicit with
 `@all(model: "User")`.
 
+To split the schema, the entrypoint imports the other files. A type is defined
+once, and the other files add to it with `extend type`:
+
+```graphql
+# graphql/schema.graphql
+type Query
+
+#import user.graphql
+#import blog/*.graphql
+```
+
+```graphql
+# graphql/user.graphql
+type User {
+  id: ID!
+  name: String
+}
+
+extend type Query {
+  users: [User!]! @all
+}
+```
+
+A file nothing imports is not part of the schema, and a type defined twice is an
+error. See [schema-organisation.md](schema-organisation.md).
+
 ## 2. Provide your base classes
 
 Lighthouse builds on graphql-ruby, and follows its convention: each kind of class
@@ -158,8 +184,8 @@ class AppSchema < Lighthouse::GraphQL::RbLightHouse.get_schema(
 end
 ```
 
-The SDL is read from `config.sdl_folder` (`get_schema(sdl_folder: ...)` overrides
-it). The class body is graphql-ruby's, so plugins and settings go there as in any
+The SDL is read from `config.schema_path` and the files it imports
+(`get_schema(schema_path: ...)` overrides it). The class body is graphql-ruby's, so plugins and settings go there as in any
 graphql-ruby schema (`use ...`, `max_complexity(...)`), but for `query(...)` and
 `mutation(...)`, which the SDL's root types replace, and `resolve_type`, which
 Lighthouse answers (see [types.md](types.md)).
@@ -260,7 +286,9 @@ Your IDE validates and autocompletes `.graphql` files against the schema it can
 see. Lighthouse's directive definitions and the types its manipulation phase
 generates live in Ruby, so without help the IDE flags `@paginate` as unknown and
 can't resolve `UserPaginator`. PHP Lighthouse solves this with an IDE helper
-command; so does Lighthouse for Rails:
+command, and so does Lighthouse for Rails. In development, an app with a
+`graphql.config.yml` gets the files rewritten on boot and on every reload
+(`config.ide_helper`), so you never run it by hand there. Elsewhere:
 
 ```shell
 bin/rails lighthouse:ide_helper              # writes to Rails.root
@@ -274,8 +302,11 @@ It writes two files:
   declares (so the IDE never sees a duplicate).
 - **`programmatic-types.graphql`** — the types Lighthouse adds to the executable
   schema: `<Type>Paginator`, `<Type>SimplePaginator`, `<Type>Connection`/`Edge`,
-  `PaginatorInfo`, `SimplePaginatorInfo`, `PageInfo`, the `whereConditions`
-  inputs and enums, and the `_` placeholder scalar.
+  `PaginatorInfo`, `SimplePaginatorInfo`, `PageInfo`, the `@whereConditions` and
+  `@orderBy` inputs and enums, and the `_` placeholder scalar (without it, the
+  IDE reports `Unknown type "_"`). It leaves out every type the SDL or
+  `schema-directives.graphql` defines, because graphql-js, which the IDE plugins
+  use, rejects a type defined twice.
 
 Point your IDE's [graphql-config](https://the-guild.dev/graphql/config) at them
 next to your SDL — the install generator writes this `graphql.config.yml`:
@@ -289,7 +320,9 @@ schema:
 
 It works with the GraphQL plugin for JetBrains IDEs and the GraphQL extension for
 VS Code. The files are derived from your schema, so the generator adds them to
-`.gitignore`; rerun the task after changing the schema or registering a directive.
+`.gitignore`. Outside development, rerun the task after changing the schema or
+registering a directive. The IDE reads every `.graphql` file the glob matches, as
+one schema: it does not follow `#import`.
 
 > The IDE reads fields as you wrote them: `users: [User!]! @paginate` still looks
 > like a list to it, although clients query `users { data { … } }`. Field

data/docs/motivation.md

@@ -98,8 +98,9 @@ generated from Ruby classes:
 - **It is designed before it is implemented.** You can agree on the types and fields
   first, as a team, and the server follows the design rather than leaking its internals.
 - **Tools understand it directly.** IDE plugins, code generators and schema registries
-  read SDL. Lighthouse's `lighthouse:ide_helper` task adds its directives and generated
-  types so editors validate and autocomplete the schema.
+  read SDL. Lighthouse writes out its directives and generated types (in development
+  on every reload, or with `lighthouse:ide_helper`), so editors validate and
+  autocomplete the schema.
 - **It says what each field does.** `posts: [Post!]! @paginate @guard @cacheControl(maxAge: 60)`
   tells a reader, without opening any Ruby, that the field is paginated, requires a
   signed-in user and can be cached for a minute.

data/docs/performance.md

@@ -59,9 +59,10 @@ Lighthouse.configure { |config| config.watch_sdl = Rails.env.development? }
 ```
 
 Rails' reloader watches Ruby files, not `.graphql` ones, so without this an SDL
-edit only shows up after restarting the server. With it, the SDL folder joins
-`config.watchable_dirs`, and an edit reloads the app, and with it the schema, on
-the next request, like a Ruby change. This relies on the schema class living
+edit only shows up after restarting the server. With it, the folder of
+`config.schema_path` joins `config.watchable_dirs`, and an edit to any `.graphql`
+file below it reloads the app, and with it the schema, on the next request, like
+a Ruby change. The reload also rewrites the IDE helper files (`config.ide_helper`). This relies on the schema class living
 in an autoloaded file, as `app/graphql/app_schema.rb` does.
 
 ## Persisted queries

data/docs/relationships.md

@@ -174,7 +174,8 @@ queries:
 type User {
   publishedPosts(
     title: String @like
-    orderBy: [OrderByClause!] @orderBy
+    orderBy: _ @orderBy(columns: ["title", "created_at"])
+    where: _ @whereConditions(columns: ["title"])
   ): [Post!]! @hasMany(relation: "posts", scopes: ["published"])
 }
 ```

data/docs/resolvers.md

@@ -282,11 +282,11 @@ What PHP Lighthouse hands a resolver as `$resolveInfo`. A `Resolvers::` or
 `enhance_builder` lets a class build the query no directive could, and still honour
 what the field declares: its `@builder` classes, and the argument directives the
 client used (`@eq`, `@where`, `@in`, `@like`, `@orderBy`, `@whereConditions`, ...),
-as `@all` and `@paginate` apply them. `scopes:` adds model scopes.
+then the field's own `@orderBy(column:)`, as `@all` and `@paginate` apply them. `scopes:` adds model scopes.
 
 ```graphql
 type Query {
-  myPosts(title: String @like, orderBy: [PostOrderByClause!] @orderBy): [Post!]! @guard
+  myPosts(title: String @like, orderBy: _ @orderBy(columns: ["title", "created_at"])): [Post!]! @guard
 }
 ```