undefined | Better HN

0 pointsreipahb10y ago0 comments

One thing to note is that while the continuation token is just a blob of data from the clients perspective, the server can actually use it to store the required state information.

A simple method would be to take the state information the server needs in order to continue the enumeration (e.g. sorting order, how far along it was in the enumeration, etc.), JSON-encode it, encrypt&sign it, and then base64 encode it.

Return that token to the client, and if the client wants more data it can pass that token back to the server, which can decode it into all the information it needs to resume the enumeration.

0 comments

mateo41110y ago

I like this approach, but this requires storing the rest of the enumeration. I think that you would want to the continuation token to expire after a reasonable period of time (10 minutes to 1 hour). When the token expired, you would remove the rest of the enumeration from your data store.

This isn't what the author recommends, but I think this is a good approach.

reipahbOP10y ago

I don't think this requires storing anything on the server. That was kind of the point of the whole "store the server state in the continuation token"-thing :)

You want to store enough information in the token that you can easily reconstruct and resume the enumeration.

For example, let us say that the user asked for all comments with a score >= 5 sorted by post time. In that case you could return 100 comments, and a token that encoded something like:

  {
    "min_score": 5,
    "sort": "post_time",
    "resume_from_post_time": "2015-05-07T05:34:02Z",
  }

To ensure that it is easy to resume the enumeration, the API can fudge the number of returned items so that the returned data always breaks at a nice "post_time" boundary. The goal here is to make it easy for the client to get all the data in the enumeration without implementing all this logic themselves.

True, it will only work efficiently for some types of queries, but a lot of the common queries can be reworked into something like that.

mateo41110y ago

Ok, I see the difference.

You suggest that the continuation token, is basically an encoding of the query parameters, to fetch results from the API. If you go with this approach, then you don't have to store any state on the server. This is a good approach, because it's simple, but it doesn't solve the issue, where the response from the API changes while you making the paging API calls. The example used in the article is where an order was deleted, while you were calling the API.

I was thinking of using a uuid to generate a continuation token, and storing a copy of the results from the API. Subsequent calls that use the continuation token, would take a subset of these results. This requires storing more state on the server, and managing that state. The benefit to this approach is that results you get back from paging are consistent. This solves the issue, where the results from the API change while you are calling the API multiple times. The downside to this approach is that you have to store more state in server. If you are storing the full results for all of these paging API calls, then this could be quite large.

1 more reply

j / k navigate · click thread line to collapse

0 comments

mateo41110y ago

This isn't what the author recommends, but I think this is a good approach.

reipahbOP10y ago

I don't think this requires storing anything on the server. That was kind of the point of the whole "store the server state in the continuation token"-thing :)

You want to store enough information in the token that you can easily reconstruct and resume the enumeration.

For example, let us say that the user asked for all comments with a score >= 5 sorted by post time. In that case you could return 100 comments, and a token that encoded something like:

  {
    "min_score": 5,
    "sort": "post_time",
    "resume_from_post_time": "2015-05-07T05:34:02Z",
  }

True, it will only work efficiently for some types of queries, but a lot of the common queries can be reworked into something like that.

mateo41110y ago

Ok, I see the difference.

1 more reply

j / k navigate · click thread line to collapse