slonik-dataloaders

slonik-dataloaders is a set of utilities for creating DataLoaders using Slonik. These DataLoaders abstract away some of the complexity of working with cursor-style pagination when working with a SQL database, while still maintaining the flexibility that comes with writing raw SQL statements.

createNodeByIdLoaderClass

Example usage:

1const UserByIdLoader = createNodeByIdLoaderClass({
2  query: sql.type(User)`
3    SELECT
4      *
5    FROM user
6  `,
7});
8
9const pool = createPool("postgresql://");
10const loader = new UserByIdLoader(pool);
11const user = await loader.load(99);

By default, the loader will look for an integer column named id to use as the key. You can specify a different column to use like this:

1const UserByIdLoader = createNodeByIdLoaderClass({
2  column: {
3    name: 'unique_id',
4    type: 'text',
5  }
6  query: sql.type(User)`
7    SELECT
8      *
9    FROM user
10  `,
11});

createConnectionLoaderClass

Example usage

1const UserConnectionLoader = createConnectionLoaderClass<User>({
2  query: sql.type(User)`
3    SELECT
4      *
5    FROM user
6  `,
7});
8
9const pool = createPool("postgresql://");
10const loader = new UserByIdLoader(pool);
11const connection = await loader.load({
12  where: ({ firstName }) => sql.fragment`${firstName} = 'Susan'`,
13  orderBy: ({ firstName }) => [[firstName, "ASC"]],
14});

When calling load, you can include where and orderBy expression factories that will be used to generate each respective clause. These factory functions allow for type-safe loader usage and abstract away the actual table alias used inside the generated SQL query. Note that the column names passed to each factory reflect the type provided when creating the loader class (i.e. User in the example above); however, each column name is transformed using columnNameTransformer as described below.

Usage example with forward pagination:

1const connection = await loader.load({
2  orderBy: ({ firstName }) => [[firstName, "ASC"]],
3  limit: first,
4  cursor: after,
5});

Usage example with backward pagination:

1const connection = await loader.load({
2  orderBy: ({ firstName }) => [[firstName, "ASC"]],
3  limit: last,
4  cursor: before,
5  reverse: true,
6});

Conditionally fetching edges and count based on requested fields

In addition to the standard edges and pageInfo fields, each connection returned by the loader also includes a count field. This field reflects the total number of results that would be returned if no limit was applied. In order to fetch both the edges and the count, the loader makes two separate database queries. However, the loader can determine whether it needs to request only one or both of the queries by looking at the GraphQL fields that were actually requested. To do this, we pass in the GraphQLResolveInfo parameter provided to every GraphQL resolver:

1const connection = await loader.load({
2  orderBy: ({ firstName }) => [[firstName, "ASC"]],
3  limit: first,
4  cursor: after,
5  info,
6});

Working with edge fields

It's possible to request columns that will be exposed as fields on the edge type in your schema, as opposed to on the node type. These fields should be included in your query and the TypeScript type provided to the loader. The loader returns each row of the results as both the edge and the node, so all requested columns are available inside the resolvers for either type. Note: each requested column should be unique, so if there's a name conflict, you should use an appropriate alias. For example:

1const UserConnectionLoader = createConnectionLoaderClass<
2  User & { edgeCreatedAt }
3>({
4  query: sql.unsafe`
5    SELECT
6      user.id,
7      user.name,
8      user.created_at,
9      friend.created_at edge_created_at
10    FROM user
11    INNER JOIN friend ON
12      user.id = friend.user_id
13  `,
14});

In the example above, if the field on the Edge type in the schema is named createdAt, we just need to write a resolver for it and resolve the value to that of the edgeCreatedAt property.

columnNameTransformer

Both types of loaders also accept an columnNameTransformer option. By default, the transformer used is snake-case. The default assumes:

• You're using conventional snake case column names; and
• You're using either slonik-interceptor-field-name-transformation or the slonik-interceptor-preset, which means the columns are returned as camelCased in the query results

By using the columnNameTransformer (snake case), fields can be referenced by their names as they appear in the results when calling the loader, while still referencing the correct columns inside the query itself. If your usage doesn't meet the above two criteria, consider providing an alternative transformer, like an identify function.