-
Notifications
You must be signed in to change notification settings - Fork 140
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
WIP - Add cursor-based stable ID pagination
This code is more for reference than review. The intent of this PR is to increase transparency and collaboration so we can get input from the community on the best direction to head - as with everything, there are tradeoffs. [This JSON:API "Cursor Pagination" Profile](https://jsonapi.org/profiles/ethanresnick/cursor-pagination/) explains one use case. The other is that we're in the process of adding GraphQL support to Graphiti, and cursors are more common in the GraphQL world. There are really two ways to do cursor-based pagination, and the JSON:API proposal only considers one. We can do this will offset-based cursors, or "stable IDS". This is best explained by [this post on Stable Relation Connections](https://graphql-ruby.org/pagination/stable_relation_connections) in GraphQL-Pro. Vanilla `graphql-ruby` does offset-based, Pro adds support for stable IDs. The third thing to consider is omitting cursors and supporting the `page[offset]` parameter. This is the simplest thing that supports the most use cases, though downsides are noted above. This PR implements stable IDs. That means we need to tell Graphiti which attributes are unique, incrementing keys. I've defaulted this to `id`, though it's notable that will need to be overridden if using non-incrementing UUIDs. So, the code: ```ruby class EmployeeResource < ApplicationResource # Tell Graphiti we are opting-in to cursor pagination self.cursor_paginatable = true # Tell Graphiti this is a stable ID that can be used as cursor sort :created_at, :datetime, cursor: true # Override the default cursor from 'id' to 'created_at' self.default_cursor = :created_at end ``` (*NB: One reason to have `cursor_paginatable` a separate flag from `default_cursor` is so `ApplicationResource` can say "all resources should support cursor pagination" but then throw helpful errors if `id` is a UUID or we elsewise don't have a default stable cursor defined*) This will cause us to render base64 encoded cursors: ```ruby { data: [ { id: "10", type: "employees", attributes: { ... }, meta: { cursor: "abc123" } } ] } ``` Which can be used as offsets with `?page[after]=abc123`. This would by default cause the SQL query `SELECT * FROM employees WHERE id > 10`. So far so good. The client might also pass a sort. So `sort=-id` (ID descending) would cause the reverse query `...where id < 10`. A little trickier: the client might pass a sort on an attribute that is not the cursor. This is one reason we want to flag the sorts with `cursor: true` - so the user can ```ruby sort :created_at, cursor: true ``` Then call ``` ?sort=created_at ``` Which will then use `created_at` as the cursor which means ``` ?sort=created_at&page[after]=abc123 ``` Will fire ``` SELECT * from employees where created_at > ? order by created_at asc ``` OK but now let's say the user tries to sort on something that ISN'T a stable ID: ``` ?sort=age ``` Under-the-hood we will turn this into a multi-sort like `age,id`. Then when paging `after` the SQL would be something like: ``` SELECT * FROM employees WHERE age > 40 OR (age = 40 AND id > 10) ORDER BY age ASC, id ASC ``` Finally, we need to consider `datetime`. By default we render to the second (e.g. `created_at.iso8601`) but to be a stable ID we need to render to nanosecond precision (`created_at.iso8601(6)`). So the serializer block will be honored, even if the attribute is unreadable: ```ruby attribute :timestamp, :datetime, readable: false do @object.created_at end ``` But we override the typecasting logic that would normally call `.iso8601` and instead call `.iso8601(6)`. For everything else *we omit typecasting entirely* since cursors should be referencing "raw" values and there is no need to case to and fro. There are three downsides to stable ID cursor pagination: * The developer needs to know all this, and has a little more work to do (like specifying `cursor: true`). * The `OR` logic above would be specific to the `ActiveRecord` adapter. Adapters in general do not have an `OR` concept, and I'm not sure there is a good general-purpose one. This means stable IDs only work when limiting sort capabilities and/or only using `ActiveRecord`. * The `before` cursor is complicated. We need to reverse the direction of the clauses, then re-reverse the records in memory. See [SQL Option 2: Double Reverse](https://blog.reactioncommerce.com/how-to-implement-graphql-pagination-and-sorting/). This feels like it might be buggy down the line. For these reasons I propose: * Default to offset-based cursors * Opt-in to stable IDs by specifying `.default_cursor` * This all goes through a `cursor_paginate` adapter method (alternative is we can call the relevant adapter methods like `filter_integer_gt` and introduce an "OR" concept, but this feels shaky). Implementing this will be non-trivial for non-AR datastores. * This means adapters need an "offset" concept This seems to give us the best balance of ease-of-use (offset-based) and opt-in power (stable-id-based). It also allows us to more easily say "all endpoints implement cursor-based pagination" (so we avoid having to remember to specify cursors in all resources). But, there are enough moving pieces here this is usually where I stop and get advice from people smarter than me. This is often @wadetandy but also includes basically anyone reading this PR. So, what are your thoughts?
- Loading branch information
Lee Richmond
committed
May 3, 2021
1 parent
9ab7fa8
commit e935a2c
Showing
18 changed files
with
911 additions
and
19 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
module Graphiti | ||
module Util | ||
module Cursor | ||
def self.encode(parts) | ||
parts.each do |part| | ||
part[:value] = part[:value].iso8601(6) if part[:value].is_a?(Time) | ||
end | ||
Base64.encode64(parts.to_json) | ||
end | ||
|
||
def self.decode(resource, cursor) | ||
parts = JSON.parse(Base64.decode64(cursor)).map(&:symbolize_keys) | ||
parts.each do |part| | ||
part[:attribute] = part[:attribute].to_sym | ||
config = resource.get_attr!(part[:attribute], :sortable, request: true) | ||
value = part[:value] | ||
part[:value] = if config[:type] == :datetime | ||
Dry::Types["json.date_time"][value].iso8601(6) | ||
else | ||
resource.typecast(part[:attribute], value, :sortable) | ||
end | ||
end | ||
parts | ||
end | ||
end | ||
end | ||
end |
Oops, something went wrong.