Closed n1ru4l closed 3 days ago
It could also show a complexity score next to each document.
Could also reject documents with complexity higher than X
S3 could be used as a schema registry
Yes and Hive should control it all
a few analytic stuff we can do here as well.
e.g. display how many bytes saved from client <-> server requests by using persisted operations over time
Plus some part of data processing (related to the usage reporting pipeline) might be done ahead of time and the structure of the usage report could be much different much much lower in size (and more performant on the user side - no processing of documents involved)
Having GraphQL Hive act as a persistent operation store would be great.
Critical user flow
publish app deployement (app name + app version + set of persisted documents) via Hive CLI
use Hive CLI to mark an app deployment as active (as soon as it is active, the persisted documents should be available via CDN)
The Hive SDK should with a single option opt-into using the persisted document store from Hive CDN, no additional configuration needed
@graphql-hive/envelope
@graphql-hive/yoga
@graphql-hive/apollo
user configures urql, apollo and relay use persisted documents with Hive, through our guidance documentation (we also reference to frameworks/libraries for further information)
once an app deployment is no longer used → retire app via CLI or Hive App UI (persisted documents are no longer available via persisted documents CDN)
Technical Challenges
How do we “store”/insert all the operations?
~API: We need an async task runner for writing operations from “storage” to “CDN” and also cleaning them up if app deployment got retired (we cannot send 1000 requests to S3 from within a single HTTP call, can't we? :))~ - We decided that it makes most sense to immediately write to S3 in the incoming request; we can check whether deployment is active via another S3 key lookup
How do we extract operations with Hive? Do we rely on people providing a JSON file?
Nice to have (stretch goals; follow up tasks)
-->
Allow users to decide whether to do breaking change detection based on app deployments or usage data.
Delete persisted operation deployment flow
We must figure out how to incorporate the persisted operation schema coordinates within the hive check/breaking change detection flow (usage data). As long as a persisted operation deployment is active, the field is in usage, even if there is no data in the retention period. After a persisted operation deployment has been deleted/marked as retired/inactive, the deployment schema coordinates removal is no longer blocked by the deployment.
Based on the usage data, we can notify users when a client version seems unused (e.g. old mobile client).
Documentation
Details
Some ideas on how to store stuff...
S3 Key Structure
Here we write the graphql documents as long as the deployment is active - we need to ensure that it is removed from S3 if the deployment gets inactive. Thus a transactional background job seems inevitable.
SQL
When a deployment has been created and "frozen", we could generate the schema coordinate ---> hash mapping, for quick lookups of which a schema coordinate impacts operations. 🤔 Alternatively, we can execute the SQL live for each active deployment.
Unsure whether we should store all the schema coordinates used within a document alongside the document. 🤔
PROs:
Links: