Implement GraphQL query layer

regen-network / regen-ledger

:seedling: Blockchain for planetary regeneration

https://docs.regen.network

Other

214 stars 103 forks source link

Implement GraphQL query layer #930

Open ryanchristo opened 2 years ago

ryanchristo commented 2 years ago

Summary

We are currently storing addresses as bytes in state proto messages for storage efficiency. We are also using the same messages in query responses and therefore returning addresses that are not human-readable.

How do we make addresses readable in query responses?

Short-term solution:

[x] Separate messages for query responses #1022

Potential long-term solutions:

[ ] Expose a graphql query layer that has a straightforward way to get an address string from bytes

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

robert-zaremba commented 2 years ago

IMO, by default we should not think that stored object = presented object. So we should not be afraid to create a different structure for stored object and presentation object (the one we send out).

robert-zaremba commented 2 years ago

Hacky solution to this particular problem would be some proto annotations and having 2 codec modes which will understand that annotation and handle the coding. .... but to be honest, it looks too hacky ;)

aaronc commented 2 years ago

With the ORM, the stored object is effectively the presented object because the ORM will expose its own direct query layer to clients. So we will need to figure out a way to solve the presentation problem with the ORM.

My current thinking has been:

use cosmos_proto.scalar annotations to indicate a bytes field is an address
expose a graphql query layer that has a straightforward way to get an address string from bytes (similarly to how Postgraphile uses postgres helper functions to allow the same thing with I believe GeoJSON)

We could also do gRPC where we auto-generated presentation types based on scalar annotations, but that seems more heavy-handed... and graphql has other benefits...

Sorry this isn't well documented on the ORM side but we should write it up in one of the Framework WG calls

ryanchristo commented 2 years ago

We spoke about this briefly on our standup this morning. The graphql solution sounds interesting but may require more work. @technicallyty is planning to look into the scalar annotation later today if he has the time.

ryanchristo commented 2 years ago

Notes from product call:

For v4.0 release, we will need to create separate proto messages where addresses are represented as strings.

aaronc commented 2 years ago

Moving my comments from #1022 here

This makes me want to spend a bit of time on the query infrastructure in the SDK using Cosmos scalars so we don't have to manually write all this stuff. But generally looking good @ryanchristo

There are a few design questions though if I'm going to spend some time. Do we auto-generate gRPC endpoints that just convert bytes to strings for cosmos.AddressBytes scalars? Do we relate this to the value renderer work for sign mode textual? Or maybe we jump straight to graphql?

What do you think @ryanchristo ?

ryanchristo commented 2 years ago

What do you think @ryanchristo ?

I think we should consider jumping straight to graphql given we need more than just addresses converted from bytes to strings. Scalars will not eliminate our need for writing out queries as I have done in #1022.

aaronc commented 2 years ago

What do you think @ryanchristo ?

I think we should consider jumping straight to graphql given we need more than just addresses converted from bytes to strings. Scalars will not eliminate our need for writing out queries as I have done in #1022.

I've sort of been leaning towards graphql as well