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!