I am working on an application of mid to high size and complexity, it is an umbrella application with at least 3 main applications (but you could think of them as Phoenix Contexts if you wish). There is an existing client-facing JSON API, a little pure HTML rendering, some websockets, and an internal API (for another server to interface with us). Currently data-loading and permissions checking happens in an ad-hoc manner. As we are just starting to add GraphQL support with Absinthe I’ve been thinking of using Dataloader throughout the various applications and contexts. Does anyone have familiarity with this type of approach?

I have been fairly deeply impacted by the philosophy espoused by Dan Schafer in this GraphQL talk: https://www.youtube.com/watch?v=etax3aEe2dA

So my goals are to have entities always loaded with respect to the current viewer (usually a user) and for that data loading to live in the context of the specific application.

The main approach that has come to mind so far is to create a %UserRequest{} struct with a %Viewer{} struct embedded. The %Viewer{} would have typically have a normal %User{} associated with it but sometimes the user would be a :super_admin (i.e. me) which would have extra permissions and it might even be :other_internal_system. The %UserRequest{} struct would additionally contain the %Dataloader{} that could be used to fetch entities that the user is allowed to see.

So my context/application data fetching functions would look something like this:

defmodule Blog do
  @spec fetch_post(binary, %UserRequest{}) :: {:ok, {%Post{}, %UserRequest{}}} | {:error, term}
  def fetch_post(id, %UserRequest{loader: loader, viewer: viewer}) do
    ...
  end

  @spec fetch_posts(list(binary), %UserRequest{}) :: {:ok, {list(%Post{}), %UserRequest{}}} | {:error, term}
  def fetch_posts(ids, %UserRequest{loader: loader, viewer: viewer}) do
    ...
  end
end

So the context/application data fetching functions would take in the data to query, along with the %UserRequest{} (which now that I think of it should perhaps be called a %UserRequestContext{} or maybe just %RequestContext{}). And along with fetching and returning the actual data, they would potentially load new data into the %UserRequest{} data structure which is the reason that the %UserRequest{} needs to be returned from the data fetching method as well.

This would allow all of the data fetching methods to have a common format for permission checking and avoid loading the same data multiple times (note that the permission checking will sometimes have to load data specific to the user).

Does this approach make sense? Are there better alternatives that wouldn’t require re-writing so much of the data-fetching logic? Should I instead move the dataloader to the Process dictionary (which is effectively the approach taken by the javascript dataloader)? @jfrolich I’m especially interested in your thoughts since I think your talk (which I’m about to watch) and PR are related to this topic.