ROADMAP.md

bridge_ex - Roadmap

This document describes the current status and the upcoming milestones of the bridge_ex library.

Status	Goal	Breaking	Card	PR
✔	Add a CHANGELOG	-	-	#6
✔	Add a ROADMAP for future developments	-	-	#30
❌	Support all possible outcomes of a GraphQL query	💣	-
❌	Log queries safely	-	-	-
✔️	Use strings instead of atoms when deserializing GraphQL response	-	-	#69
✔	Flexible retry policy	💣	341	#39
✔	Exponential retry policy	-	367	#41

Support all possible outcomes of a GraphQL query

A GraphQL query may return

• only data on success
• only errors with null data on error
• both data and errors on partial success/failure

Right now bridge_ex returns

• {:ok, data} if errors is present
• {:error, errors} if errors is present, regardless of whether data is null or not

In the future, we may want to support the case of partial response, probably just by returning the whole response and letting the caller deal with its contents.

Log queries safely

If log_query_on_error option is enabled, both the query and its variables are logged, thus possibly leaking private data. In the future, we could remove the variables portion, allowing the caller to log the query even in staging or production without any risk.

---

Done

Use strings instead of atoms when deserializing GraphQL response

When deserializing the GraphQL response we convert all keys to atoms. While nothing bad has happened yet, this may lead to problems: atoms are not garbage collected and there is a limit to how many atoms one can have. In general, generating atoms dynamically is not a good practice, especially based on external input.

Make retry policy more flexible

Improve the library by adding the ability to customize the retry policy.

On error, a retry function is called (if max attempts > 1), but right now the retry happens regardless of the error. This is a bit limiting since not all errors are transient and enabling the retry could lead to many needless requests.

A better approach would be to provide the user with a default retry mechanism and then a way to define a custom function to match errors and decide which to recover from, something like

use BridgeEx.Graphql,
  endpoint: "http://my-endpoint"

...

call("{ some { query } }", %{},
  retry_policy: fn ->
    "SOME_ERROR" -> :retry
    "ANOTHER_ERROR" -> :retry
    _ -> :stop
  end
)

Add exponential retry policy

As of now the retry policy is linear. It could be useful to implement an exponential retry strategy instead.