Consider using GraphQL for serving data to the front-end
This would obviously be a big change and GraphQL may not yet be mature enough for PubSweet's needs, so this issue is mostly a placeholder to record pros/cons of using GraphQL.
An example use case would be displaying a list of collections that a user owns along with the team members of each collection.
In a server-side application where entities are passed directly from controllers to server-rendered views this isn't a problem as the controller/template can walk the entity graph to get the information it needs.
A client-side application doesn't have this ability, so in order to fetch the data needed for this view through the REST API, the client either needs to:
- call
/collections/?owner=:user_id
to get a list of the collections owned by a user (which each contains a list of the collection's teams), then call/teams/:team_id
for each team in each collection to get the team (which contains a list of the team's members), then call/users/:user_id
for each member of each team to get the user. - call
/collections/?owner=:user_id
and update the API to add all the nested information needed to the response (which will then be returned whenever any client requests data from that endpoint, even if they don't need it.
Using GraphQL, the client just has to define the shape of the data that it wishes to receive, and the server will resolve each level of that data (filtering using permissions at each step), returning a single object containing all the information needed.