Absinthe GraphQL: best practice for object graph

Chat / Discussions
,
1

I work on a calendar app, and to query appointments, my query document looks like below:

me {
  calendar {
    appointments { ... }
    availabilities { ... }
  }
}

To access the appointments, I have to resolve the current user, then the calendar, then finally the appointments.

This follows the Ecto schemas associations.

And in the JS client, I have account.calendar.appointments.

It made me thinking, shouldn’t I also offer the possibility to fetch the appointments directly from the account?

me {
  appointments { ... }
  availabilities { ... }
}

But then I need to handle two function clauses for the resolver:

appointments(%Calendar{} = calendar, %{date_range: date_range}, _)
appointments(%Account{} = account, %{date_range: date_range}, _)

Question:
If I further reason like that for other parts, I’ll have resolvers that resolve an entity for multiple parent types with multiple clauses, is that a normal thing to have? Do you resolve entities for multiple parents to avoid having to access deeply nested objects?
Or do you design the graph closely following the Ecto schema associations (such as seen in first query document)? I’m confused…

Secondly, when the JS client requests for example the appointments, I end up with an account (as I’m using the viewer ‘me’ pattern as seen above), and not directly appointments (or as in my first example, an account, then a calendar, then appointments). So code/variables/function names tends to be a little incoherent on the JS client side, e.g. a fetchAppointments function requesting the appointments will result into an account… there are many ways to solve this issue, but how do you deal with that?

Any guidance is welcome!

2

I’m interested in how people approach this also. We got a fairly large Absinthe project and faced some of these same decisions.

For the most part no. It doesn’t feel very dry to me (too many ways to skin a cat). Or it feels like it’s just making convenience functions just for the reason of making your query smaller.

The biggest issue for us (and this might relate to some of your issues) is that we use Dataloader exclusively, which makes it where resolvers can’t “call” other resolvers, so when we want to share functionality, we make “resolver helpers” that different resolvers can call. Which looks like this for your example:

def appointments(%Calendar{} = calendar, args, res) do
  res.context.loader
  |> load_appointments(calendar, args, fn _loader, appointments ->
    {:ok, appointments}
  end)
end

def appointments(%Account{} = account, args, res) do
  res.context.loader
  |> load(:db, :calendar, account)
  |> on_load(fn loader, calendar ->
    loader
    |> load_appointments(calendar, args, fn _loader, appointments ->
      {:ok, appointments}
    end)
  end)
end

(we have our own Dataloader helpers that make this API possible; I know it’s not standard)

I don’t know if that’s the best way to share functionality between Dataloader based resolvers, but it works.