Convert two-sided relationship field in examples/blog to one-sided because of bad practice

[MurzNN]

Now in "examples/blog" project we have two-sided relationship between Author and Post lists items

Two-sided relationship suites well for many cases, but if it comes to blog, this way of relationship leads to very bad performance, when blog accumulates a lot of posts from some author!

For example, if an author "alice" would create 1000 posts, the "Alice" item will contain 1000 items in "posts" field.

This will be very bad for performance, because the "Author" item is loaded very often, even for authorization process. Also when we trying to get list of authors, ids of all posts for each author will be loaded!

So I think that this is a very bad practice to give this for users as "perfect" example, and recommend conversion of two-sided relationship field to one-sided, to eliminate this bad practice when users creates their projects, based on this example. What do you think about this?

[gautamsi]

You can always change the UI display mode for relationship field to be count

[MurzNN]

I'm worrying mostly about backend side, because item is loaded from database always with full content of all fields.

[gautamsi]

It should not be loaded unless you ask for it

[MurzNN]

No, Keystone always query all fields of List item from database, even if you are querying only one field! Because values of all fields may be used for access functions or hooks. You can easily check this via launching Prisma in debug mode (enableLogging: true) and try the query like this:

query {
  authors {
    email
  }
}

You'll see that all fields are queried by SQL query:

prisma:query SELECT `main`.`Author`.`id`, `main`.`Author`.`name`, `main`.`Author`.`email` FROM `main`.`Author` WHERE 1=1 LIMIT ? OFFSET ?

[MurzNN]

Hmm, seems relationship fields are exception from that rule, cuz I don't see them in that query.

[MurzNN]

And good alternative to Author.posts relationship field can be a virtual field, that loads all posts of that author on demand. This will be a very useful example to reuse in many cases.

[dcousens]

This will be very bad for performance, because the "Author" item is loaded very often, even for authorization process. Also when we trying to get list of authors, ids of all posts for each author will be loaded!

The Author.posts will only be fetched when requested, and you can set take (in GraphQL queries) or graphql.queryLimits.maxResults (in your list configuration) to prevent any potential DoS problems.

Please see our tests for an example

keystone/tests/api-tests/queries/limits.test.ts

Lines 22 to 26 in 58f525d

	graphql: {
	queryLimits: {
	maxResults: 2,
	},
	},

And the following for the implementation

keystone/packages/core/src/lib/core/queries/resolvers.ts

Lines 255 to 272 in 58f525d

	function applyEarlyMaxResults(_take: number | null | undefined, list: InitialisedList) {
	const take = Math.abs(_take ?? Infinity);
	// We want to help devs by failing fast and noisily if limits are violated.
	// Unfortunately, we can't always be sure of intent.
	// E.g., if the query has a "take: 10", is it bad if more results could come back?
	// Maybe yes, or maybe the dev is just paginating posts.
	// But we can be sure there's a problem in two cases:
	// * The query explicitly has a "take" that exceeds the limit
	// * The query has no "take", and has more results than the limit
	if (take < Infinity && take > list.maxResults) {
	throw limitsExceededError({ list: list.listKey, type: 'maxResults', limit: list.maxResults });
	}
	}
	function applyMaxResults(results: unknown[], list: InitialisedList, context: KeystoneContext) {
	if (results.length > list.maxResults) {
	throw limitsExceededError({ list: list.listKey, type: 'maxResults', limit: list.maxResults });
	}

This is an example of where our examples could be more instructive for these nuanced problems.