Questions about graphql:sync/3

[bullno1]

Related: https://github.com/shopgun/graphql-erlang/issues/143

Recently, I saw that graphql:sync/3 is added but it doesn't have much documentation or example. I just want to check if I understand it correctly. If I want to build a dataloader, would the dataloader loop looks like this?

data_loader_loop(Ctx) ->
    graphql:sync(Ctx, self(), start_load),
    wait_loop(Ctx, []).

wait_loop(Ctx, Reqs) ->
    receive
        {load, _Token, _Type, _Id} = Req ->
            wait_loop(Ctx, [Req | Reqs]);
        start_load ->
            % Process each request, reply with graphql:reply_cast/2
            % Optionally, cache
            process_requests(Ctx, Reqs),
            data_loader_loop(Ctx)
    end.

Something like gen_statem could be used for cleaner code with regards to timeout and whatnot but I can't write that without heavy reference to the OTP doc.

At the beginning of a query, a new data loader process could be spawned and its pid get shoved into Ctx. One can use the data loader with:

load_data(#{data_loader := DataLoader} = Ctx, Type, Id) ->
    Token = graphql:token(Ctx),
    DataLoader ! {load, Token, Type, Id},
    Token.

The calling code would return that Token with defer and a timeout.

Is the above a correct way to implement data loader?
What happens in the case of timeout? Would graphql:execute returns with null + error?

IMO, sync is a very bad name. Essentially, the caller is asking to be notified on the next defer wait and sync sounds like the function makes the caller wait for something (e.g: fsync). As for name suggestion, I have some (potentially worse):

• on_next_defer: doesn't sound very "Erlangy" but it says what it is
• send_after_wait
• notify_wait
• subscribe(defer_wait, Pid, Msg): A generic name for a function that is used to subscribe to various events but only defer_wait is available currently.

[jlouis]

A couple of things:

• It is called sync because it synchronizes with the GraphQL engine. I like the name notify_wait the best of your alternative suggestions. Let's see what people say internally here.

You are definitely on the right track. We track two things whenever our data loader gets some work to do:

• A timeout, 8ms by default
• It calls graphql:sync/3

When the graphql engine enters the defer handling loop and it sees a sync message, it does its work. This uncorks the data loader early. OTOH, if more than 8ms passes, the Data Loader just starts the query at that point in time. This is useful if you are doing other work in the query which takes a long time. When that long work is done, there is already some data ready in the mailbox for the engine to work on.

I'll keep this open and make it into a "please document this", since the tutorial doesn't have documentation right now.