router

router copied to clipboard

Describe the solution you'd like

During the course of re-working the Rhai plugin, I've noticed that there is a significant amount of naming and structure "variability" which makes it hard to perform "generic" handling for components. The types of variations are (mainly) I expect justifiable, but certainly some aren't and so we should seek to reduce arbitrary variations to simplify programming.

Here are some examples which we need to consider:

• naming: plugin_steps tend to follow the name of the structure they represent. In itself, that is probably a decision worth re-considering, but given that is the case, then "query_planner" to "query_planning" seems like a mistake. We should rename the "query_planning_service" to be "query_planner_service".
• Some data is contained within an Arc (e.g. variables on the Request). Is this for performance reasons or to prevent users from interacting with this data? In general, we should consider these kind of things carefully.
• Some data doesn't really make sense to interact with at certain stages in the pipeline. For example: If you try altering a Request.query after the QueryPlanner step what would you expect to happen? Should we (somehow) enforce logical constraints like this?
• How do we propagate subgraph header responses back to the client? (I think there's already an issue for this)
• Variations in Response.response data type. Usually Response but RouterResponse has ResponseBody.
• No way to propagate errors at the QueryPlan stage.

This list isn't exhaustive, but it's reasonably indicative of the types of things we should consider.

Describe alternatives you've considered

Leave things as they are.

Additional context

N/A