Just checking if I understand correctly what OP is talking about. Would a naive solution simply be to send graphql document strings and handle them by calling Absinthe.run/3?

It is a really cool idea because the big win is the classic “the client defines what it needs”. So you can keep (response) messages as small as possible on a case-by-case basis. This would definitely be useful if you’re working with LiveView.

I have been working on a GraphQL API where much of the data is retrieved from long-running processes rather than the database. It was easy enough to write generic dataloader “resolve” functions that call named processes. That is not what you want but it is similarly…deviant.

At a high level, the overhead introduced by GraphQL isn’t a huge trade off when compared to an HTTP request, and in particular an HTTP request over the wire is already going to have to serialize and deserialize data.

However between Elixir processes the overhead of building a query, validating that query, executing it, deserializing it, etc is substantially more heavy weight than a message passing. For Elixir processes on the same node I would strongly suggest a more “elixir native” solution.

If you have processes that are between nodes and you’re using the distributed protocol in lieu of a more traditional solution then sure you could send a graphql query to the other process and then just call Absinthe.run on it if you want, then send the result back.

Regarding your Observer example I think there’s a misconception about how things work.

Observer is not the tool providing all the available information. It’s just an aggregator of information. Just like Phoenix LiveDashboard or Observer CLI.

At least the first two, if not all three, use the same underlying functions OTP provides to get access to information. If you want to use the information for something else you could use those very same functions. So if you want to tackle the tasks you mentioned it’s not really a problem of “how do I extract those things from observer” as all the information (or at least the underlying data) is available to you directly as well. Skip dealing with observer and go to the source.

Ow… on the question about “some sort of pattern-matching magic”, you could look into ETS and match specs

A lot of the complexity of GraphQL is to reduce the number of network round-trips. If you use GraphQL for inter-process communication within the BEAM, you are paying for the complexity without the benefit.