Tracking: Subgraph Radio Frontend

[neriumrevolta]

Tracking: Subgraph Radio Frontend

[hopeyen]

some quick feedbacks

Messages flowing through the Graphcast network on the subgraph-radio pubsub topic

subgraph-radio is not a pubsub topic, it is part of a content topic

The GraphQL API provides a lot of useful query options, it has its limitations, after all it can only serve data that's readily available to the Radio (in other words - data that is saved locally).

This limitation isn't true; there are existing resolvers that query network subgraph (basic indexer info) and we used to do computations upon query requests, which was improved through persisting states.

user is still unable to identify those senders by their display name or Indexer URL, for instance. To do that, the user would have to send more request to the Network subgraph GraphQL endpoint.

This point can be easily resolved through adding the desired fields in our existing queries to the network subgraph, or a new variant of the existing query that includes display name and url.

Sending graphql requests to the Radio's internal GraphQL endpoint, for more custom and/or complex queries if needed
Sending graphql requests to the Core Network and Registry Subgraphs to get more detailed sender data

There's existing graphql playground interfaces for radio and the subgraphs. I'm failing to see understand why this should be part of the subgraph radio FE.
If there should be an aggregated place for making graphql requests, it might be out of scope here.

Interfacing with other parts of the Indexer stack like Graph Node endpoint(s), Indexer Agent, etc

Could you provide an example of how to use this

Sending messages

What kind of messages? How is this different from graphcast-web?

Changing the Radio's configurations on the fly

This can be implemented independently; indexer can use the API to update a config and doesn't require a frontend.

---

Overall I think the problem statement can be solved without an FE. My main concerns being

• when do we expect an indexer to use the FE?
• If we know the type of info they might be interested in, why not have the radio operator automatically generate it and send it through notification?
• Does it really make sense for a radio to have a grafana dashboard, a http server with restful and graphql APIs, notifications, and a separate frontend?
• A listener radio frontend makes more sense to me as a page of graphops explorer
• It would be good to have a mermaid diagram demonstrating how the frontend is expected to interact with existing components of the radio/sdk, as well as initial sketches of what you think the initial page should look like.

[neriumrevolta]

Good points @hopeyen

when do we expect an indexer to use the FE?

I'd expect Indexers to use the FE the same way they'd use the frontend view of poifier, when they want a more interactive and feature rich environment compared to the Grafana dashboard. It makes interacting with all of the other Radio components a lot easier, can be a "one stop shop", and can reduce a lot of manual workflow on the user's side, as well as make the flow a whole lot easier. Generally it could aid user experience a lot.

Does it really make sense for a radio to have a grafana dashboard, a http server with restful and graphql APIs, notifications, and a separate frontend?

Nothing wrong with multiple options of interacting with/monitoring the Radio I think, different users will have different preferences.

A listener radio frontend makes more sense to me as a page of graphops explorer

Yes, for aggregated data meant for the explorer, having a listener Radio running somewhere and querying its GraphQL endpoint, then visualising that on the explorer, seems like the best option. The Subgraph Radio frontend would help us on that front as well because we would undergo a similar effort here (fetching data from a Radio's GraphqQL endpoint and visualising it, with options for users to customise the views)

If we know the type of info they might be interested in, why not have the radio operator automatically generate it and send it through notification?

This can be harder to customise on the user's end compared to a frontend, it can also be a one-time thing and might not require a scheduled notification

What kind of messages? How is this different from graphcast-web?

It is very different because our "flagship" implementations of Graphcast and Subgraph Radio will always be in Rust, we would much rather use the Radio (that's already running) to send messages via a web interface using this frontend, compared to graphcast-js. Graphcast-js is for cases where an underlying Rust-based Radio isn't there.

Could you provide an example of how to use this

This can be as simple as just fetching and visualising data from them that might be relevant to Subgraph Radio

This can be implemented independently; indexer can use the API to update a config and doesn't require a frontend.

Agreed, but as with other things - a frontend makes it easier for the user.

There's existing graphql playground interfaces for radio and the subgraphs. I'm failing to see understand why this should be part of the subgraph radio FE.
If there should be an aggregated place for making graphql requests, it might be out of scope here.

We don't want to have "an aggregated place for making graphql requests", but we can alleviate the need of users having to construct their queries in the graphql playground(s) every time if we identify useful repeating queries, we can fetch and provide that data upfront (this can also be customised through the frontend).

This point can be easily resolved through adding the desired fields in our existing queries to the network subgraph, or a new variant of the existing query that includes display name and url.

This is fair. That way we can avoid needing multiple queries both on the GraphQL playground and in the frontend.

subgraph-radio is not a pubsub topic, it is part of a content topic

Ah my bad, that's more proper wording indeed.

This limitation isn't true; there are existing resolvers that query network subgraph (basic indexer info) and we used to do computations upon query requests, which was improved through persisting states.

I agree it's not true as far as the Radio's internal operations are concerned, but I think it still is when we consider what users can query for on the existing GraphQL endpoint.