Skip to content
This repository has been archived by the owner on Aug 9, 2021. It is now read-only.

How to deal with continual schema updates? #9

Open
zachferland opened this issue Dec 17, 2018 · 1 comment
Open

How to deal with continual schema updates? #9

zachferland opened this issue Dec 17, 2018 · 1 comment

Comments

@zachferland
Copy link
Contributor

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?

@oed
Copy link
Member

oed commented Dec 17, 2018

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 free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants