Are you after the stricter typing validations that SDL could give you?

Are you after the stricter typing validations that SDL could give you?

Only in a fairly general sense. As I read it, a GraphQL server defines its API in terms of available information. The SDL schema looks a lot like JSON; the result is like an Elixir Struct on steroids. Like a Struct, it’s a named, scripting-friendly data structure. Unlike a Struct, however, a GraphQL schema:

• can be defined and published dynamically
• can inherit root object types such as Mutation and Subscription
• can include fine control of data types, using type modifiers
• can use built-in scalar and enumeration types

In short, GraphQL and SDL seem to have a lot of useful semantics, of which stricter typing validations are only a part. (Aren’t you glad you asked? :-})

In use, an SDL schema defines and names the server’s offerings. A client can request any desired subset(s) of a server’s schema. If the server can, it will supply the data, using the names and structure specified in the schema.

As a use case, assume that I’ve decided to update a server process, extending its offerings. The server can publish the extended version of the schema and clients can start using the added information immediately. Works for me…

-r

I don’t seem to be getting much traction on this topic; after several days, I’ve only received one inquiry. So, maybe I need to clarify my question a bit more. That way, maybe someone will be able to give me a clue…

Basically, I’d like to use GraphQL (and preferably Absinthe) for communication between Elixir processes. I know that I could do this using HTTP (etc), but that seems both awkward and inefficient.

Is there a way that I could transmit Absinthe queries and responses as BEAM messages? This would let my Actors request and supply particular sets of data, using a well-documented protocol. (It might be more convenient and efficient to use Erlang terms, rather than JSON, but that’s not a gating issue…)

I dont think that would give you much value over structs or maps or simply just using term to binary.

I am on my phone or I’d elaborate more

OK but what’s wrong with the normal Elixir process communication? Why is it deficient for your needs?

If you need a bit stronger typing then you can reach for something that implements i.e. ProtoBufs or Cap’n’Proto, or even MessagePack because it doesn’t require you to have a schema beforehand but you can still assert on what you receive.

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.

OK but what’s wrong with the normal Elixir process communication? Why is it deficient for your needs?

I like “normal Elixir process communication” just fine, but it doesn’t have some of the nifty semantics I discussed in my initial reply. To motivate the discussion, here’s a more specific use case than I described above ( apologies in advance for the SciFi aspects :-).

Background

Observer

Erlang’s Observer is an amazing piece of work which collects a lot of interesting information. However, it’s a bit of an information silo:

• The information is only available via a (rather restrictive) GUI:
  • The API is limited to start, start_and_wait, and stop.
  • I haven’t found any way to tweak the presentation format.
  • I’m pretty sure it wouldn’t play nicely with a screen reader.
  • …

Observer CLI

@zhongwencool’s Observer CLI library is also very nifty, and definitely much less of an information silo. So, for example, one could:

• request a particular report
• parse the text and terminal control sequences
• extract and reorganize the desired information

However, this seems more than a little roundabout. So, it would be nice if Observer CLI could output reports as serialized data.

Discussion

Let’s say that we wanted to take advantage of the data collected by these sorts of tools. For example, I could imagine:

• logging it for later analysis
• using it in an exploratory Livebook
• feeding it into an AI wizard of some sort
• making it accessible via a screen reader
• and a pony…

Problem is, we don’t really want to receive a firehose of data for most of these use cases. So, we need a way to obtain specified subsets of the available data, possibly in a dynamic fashion. And that is an area in which GraphQL appears to excel…

GraphQL’s Complexity

@derek-zhou said:

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.

Interesting; might you be able to point me to (or provide) a discussion of this? For example, does this added complexity impact either performance or usage difficulty? (I’d agree that reducing the number of round trips isn’t all that interesting in the BEAM environment.)

I don’t know man, all this simply sounds like one OpenTelemetry collector away from being a solved problem.

Maybe you can clarify further on what are these nifty semantics about? I am not seeing them in your OP.

“simply”? Yes, in the sense that creating and maintaining an OpenTelemetry collector which provides all the data found in Observer & Observer CLI is just a “simple matter of software” :-}.

However, let’s not get lost in that aspect of the use case. I think the basic question I’m trying to answer is: What is the best way to set up a data harvesting and serving process so that its clients can specify desired subsets of the available information?

Still OpenTelemetry, you can filter at the receiver side. I know that HoneyComb and OpenObserve can do it.

Also I don’t know about :observer in particular but you can have a background process periodically reporting resource usages. I agree it’s not very simple though!

In any case, either I’m systematically missing your idea and goals, or you’re over-fixated on a particular solution, so it’s probably best for me to bow out and give others a chance to chime in.