You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 9, 2021. It is now read-only.
Most of graphqls benefits and performance benefits are from having well structured data with type defs. But data in our stores are dynamic and not strictly defined, nor are they defined by a single entity, how can we reconcile these two things? In what ways to they come together best? Do they, or will another solution ultimately be better (like pushing graphql to client side, since nothing else is gained by service)
But right now, best effort relies on defining a schema over what we consider the well defined and shared subset of keys, and even this will change pretty regularly, so how do we approach frequent updates?
The text was updated successfully, but these errors were encountered:
Does projects make PRs to this repo? What about Spaces? Would each public space have their own schema?
Also random thought: For encrypted stores, the fact that keys are only hashed provides an interesting way of doing GraphQl queries on them. Basically the query could be converted in the client to a query that uses the hashed keys, this is sent to the GQL server which responds to the client with the requested data, the client can then decrypt the data.
Not sure if this would be possible with a model where keys also are encrypted.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Most of graphqls benefits and performance benefits are from having well structured data with type defs. But data in our stores are dynamic and not strictly defined, nor are they defined by a single entity, how can we reconcile these two things? In what ways to they come together best? Do they, or will another solution ultimately be better (like pushing graphql to client side, since nothing else is gained by service)
But right now, best effort relies on defining a schema over what we consider the well defined and shared subset of keys, and even this will change pretty regularly, so how do we approach frequent updates?
The text was updated successfully, but these errors were encountered: