Replies: 3 comments 1 reply
-
|
This is ideal however, I think we are restricted for HTTP in the near term. Since the SDK abstracts calls with methods we can swap out the internals when we can. |
Beta Was this translation helpful? Give feedback.
-
|
true. Graphql queries can happen over any transport, so the way I was thinking about it is we would have a http endpoint in the gateway that consumes a graphql query and outputs the response.. in the future this could be a p2p tcp connection with some other kind of server etc but the queries and results would be the same, so it would be less work to support more transport layers in the future. |
Beta Was this translation helpful? Give feedback.
-
|
To capture this here for discussion: |
Beta Was this translation helpful? Give feedback.
-
|
Locking this since it seems to be moved to: https://github.com/kubelt/kubelt/discussions/349 |
Beta Was this translation helpful? Give feedback.
-
What
Add an RPC interface to cores so that users and other cores can call operations on them.
Why
The main benefits are:
How
I like the GraphQL approach for various reasons. It is primarily designed to get fields from objects, but can have any arbitrary set of resolver functions to achieve this. I like how extensible it is, and that the query shape matches the result. These would improve the developer experience imo. It also conforms to the vision of pushing opinionation to the edge - applications can decide what data they need and how it should be formatted etc.
Example alias lookup
request:
{ subcore: core(id: "0xaeaeaeaeaeaeaeaeaeaeae") { alias(name: "images") } }response:
{ "data": { "subcore": { "alias": "0xdeadbeefdeadbeef" } } }Beta Was this translation helpful? Give feedback.
All reactions