Can you elaborate on your use case a bit more? I am having difficulty thinking of a scenario where BEAM message communication and HTTP are both roughly on the table. Are these processes not on in the same node?
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
slouchpie
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.
4
Rich_Morin
I don’t know enough about GraphQL (let alone Absinthe) to know whether @slouchpie’s “naive solution” would work. Might someone else know?
0
Rich_Morin
Can you elaborate on your use case a bit more?
I could, but I’ve probably elaborated this use case far too much already (:-). So, just assume that a “server process” has a whole lot of information and assorted “client processes” should be able to ask for specified subsets.
I am having difficulty thinking of a scenario where BEAM message communication and HTTP are both roughly on the table.
As @slouchpie says: … the big win [in GraphQL] is the classic "the client defines what it needs”. From that perspective, the use of HTTP and JSON are “simply” implementation details.
Are these processes not on in the same node?
They might or might not be, depending on the use case involved. If data is being collected from a remote node, it might make sense for the relevant server to reside there. OTOH, it appears that a local Observer instance is able to monitor various nodes, so YMMV…
0
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
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.
2
Rich_Morin
Points taken, but what might a more “elixir native” solution look (and act) like? Hmmmmm.
Let’s assume that the server process publishes an “offerings” Struct, specifying the structure and naming of its available data.
To get started, a prospective client would send the server a “request” Struct (basically, a subset of the offerings Struct). The server would validate this once, then return a token.
After that, the client could request the subset by supplying the token. Upon receipt of a valid token, the server would copy the specified subset into a temporary data structure and send that back to the client.
If (as in @slouchpie’s use case) the server needs to call functions or even interrogate other processes, things could get a lot trickier. But we can start by assuming that all of the server’s data is nicely cached.
Does Elixir have some sort of pattern-matching magic (or whatever) that could efficiently support this sort of functionality? ELI5…
0
Tuxified
So If I understand it right, the goal is to be able to ‘query’ processes, similar to Observer ? Every process can have certain data, for example in the form of Structs but having it defined in SDL you’re able to get a subset of it?
I guess you could GraphQL to achieve that, but keep in mind that every application that needs to use this also needs to adhere to that standard (so dropping/using it in an everyday project is not possible without big changes).
Since you already mentioned Observer, have you looked where/how it got it’s information? Observer works for all processes that implement the gen_server behavior, but won’t work for bare bones process 
. For example when you click a process in Observer to inspect it’s state, it uses :sys.get_state, sending that process a message to inquire about it’s state. If that process doesn’t adhere to gen_server behavior there’s good chance Observer will be kept waiting indefinitely.
But let’s say you have a way of doing that structured querying, will it solve your (which?) problem? Even in the field of data science, having a structure in your data isn’t sufficient you still need understand what it represents to turn data into information.
If you only want to go for the structured extraction, you could extract the way observer gets it’s info into a new lib and put it into some repository, but even then you have to massage the data before using it as information.
0
LostKobrakai
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.
2
Tuxified
Ow… on the question about “some sort of pattern-matching magic”, you could look into ETS and match specs
2
derek-zhou
You could let the client ask for each and every piece of information it needs, in separate calls, since reducing the number of round trips is not a concern here.
1