Page MenuHomePhabricator

Limit the use of nested serializes to a minimum
Open, HighPublic

Description

WARNING: This change will be breaking

The server sends a lot of data nested (like author objects) instead of just the id.

Only sending the id would make the total response size smaller as the client would then cache these objects.

Revisions and Commits

Event Timeline

Info-Screen created this task.

Here is the expected result on the API:

  • /users/ID/ is unchanged
  • /users/get is added, same as /users/ID/ but allows to specify multiple users IDs. The server returns an array of all of these users (still send the ID of each user in its data, this way the users do not have to be sent in the same order as they were requested. This might allow future threading optimization (because the order is pointless anyway and that the lib will check the correspondence of IDs anyway))
  • /areas/ID/own/ only returns an array of the IDs of the posts (posts should not be nested)
  • /areas/ID/ only returns an array of the IDs of the posts (posts should not be nested)
  • /areas/ID/ID/ returns the data of the post with comments included, but neither the post's author or comments' authors are (users should not be nested)
  • /areas/ID/get/ returns multiple posts, in the same way as /users/get (this is optional since posts don't need caching as badly as users do, since you don't often need to go back to old posts)

Until this is implemented, the Java lib will ignore everything that is not an ID in the above-mentioned requests. This way, the implementation of this task will be very fast.

Until then though, the lib will be getting a lot of unneeded data (I will not implement the reading of nested objects with cache verification since it's going to get deprecated in the near future anyway).

Info-Screen raised the priority of this task from Normal to High.

Currently there is no way to get a specific draft's data. Before this, the solution was to get the list of drafts with their data nested, but this is going to be removed.

An API endpoint at GET /areas/ID/drafts/ID/ would be necessary to update the local cache for a draft.

This could be replaced by T290, which gets the same results in a non-breaking way.

In T256#4663, @CLOVIS wrote:

This could be replaced by T290, which gets the same results in a non-breaking way.

So, do we replace it or not? @WyldBot @Info-Screen

I'd like to keep this one, because it removes unneeded nesting in serializers and therefore having data in multiple places

Okay. I thought about the other because it's not breaking (and more detailed)

This is why we need a versioned API