Seperating APIs for node ops from Libplanet.Explorer

[longfin]

When posting #2130, I've wanted to move GraphQL mutations from NineChronicles.Headless to Libplanet.Explorer. but then I felt awkwardness...

• Libplanet.Explorer had been intended as a set of query, not mutation.
• GraphQL is commonly used to describe APIs for data platforms. I don't think it's suitable for adding tx to the stage, or for signing unsigned transactions.

Therefore, I suggest as like below

• Separting (or duplicating) some node-related APIs from Libplanet.Explorer and NineChronicles.Headless to new project. (call it Libplnet.NodeAPI)
• Like as Libplanet.Explorer, Libplanet.NodeAPI is a library project and can be injected by .NET DI. (like MagicOnion)
• Instead of GraphQL, Libplanet.NodeAPI relies OpenAPI¹ to provide direct API instead of query.
  • GraphQL is still possible option for Libplanet.NodeAPI considering environment like graphql-playground, but Swagger seems comparable.

Maybe there are some misunderstandings because I'm still not familiar with GraphQL. Feel free to leave a comment. 🙏

Footnotes

1. Or, any other spec is welcome. ↩

[BasixKOR]

For me, the idea of staging a transaction via GraphQL doesn't feel very weird. While I agree with the point that signing or generating a transaction via queries is awkward as they are pure computations rather than queries for the data from the remote source, providing a single API endpoint for getting and editing (from a Web2 standpoint) would be ideal from GraphQL users' perspective. For example, EIP-1767 also includes the mutation.

I think the real problem lies in the signature: we haven't found a way to sign a transaction (or, so to speak, mutation) while keeping GraphQL's semantics. EIP-1767 circumvents this problem by having a single mutation that accepts the raw transaction, but you won't know what the mutation does unless you look into the raw bytes. This breaks GraphQL's semantics.

We could have a middle-man sign a transaction on the user's behalf and provide a semantic API to be translated into a signed raw transaction that Libplanet can understand. Then we can have OpenAPI or any RPC protocol to communicate with Libplanet-enabled nodes, and users can run the application with a middle-man to talk with the node.

[longfin]

For me, the idea of staging a transaction via GraphQL doesn't feel very weird. While I agree with the point that signing or generating a transaction via queries is awkward as they are pure computations rather than queries for the data from the remote source, providing a single API endpoint for getting and editing (from a Web2 standpoint) would be ideal from GraphQL users' perspective. For example, EIP-1767 also includes the mutation.

• EIP-1767 seems to be very interesting case about GQL usages for blockchain node ops. however, I'm also interested in the fact that there has been no activity for six months after the proposal was proposed. 😅
• My concern about mutations for stage API is, it doesn't seem to fit the GQL's assumptions. AFIK, GQL's main motivation is quries with specific types. mutations are also restricted to return formatted return values as an aid to these queries. it's useful nature if we want to fetch the data from query frequently. but in other words, If we use mutations on data that we rarely look up, I don't think this might be very useful.
• Of course, we can define types and queries for staged transactions in the nodes and it doesn't break GQL assumptions. but I wonder our demands for query and mutation against staged transactions are really same. 😕

We could have a middle-man sign a transaction on the user's behalf and provide a semantic API to be translated into a signed raw transaction that Libplanet can understand. Then we can have OpenAPI or any RPC protocol to communicate with Libplanet-enabled nodes, and users can run the application with a middle-man to talk with the node.

I think that we can omit middle-man signing by libraries like #2294 . (I'm afraid about that due to private key leakages 😢)