Closed schickling closed 4 months ago
Note that envelop has a plugin https://www.envelop.dev/plugins/use-graphql-jit that could now be used as part of https://github.com/redwoodjs/redwood/pull/2827
Woah, this would be really nice for performance.
@Tobbe Is this similar to what you did recently with Cells?
@Tobbe Is this similar to what you did recently with Cells?
Not exactly. See: https://github.com/dotansimha/envelop/tree/main/packages/plugins/persisted-operations
The idea behind running persisted operations is to allow clients to run only specific queries, that defined ahead of time. This provides an enhances security and disables (optionally) the execution of other operations
Persisted queries is a way to pre-create the query, give it a key, store that query by key, and then add it to a list of queries that can be whitelisted.
The client can then just request to perform a query by asking for the results by that persisted key.
You can see some examples in the envelop plug-in code.
Implemented in https://github.com/redwoodjs/redwood/pull/9416
Given Redwood is a fullstack end-to-end framework it can provide a lot of great out-of-the-box optimizations. One problem when deploying larger applications (e.g. a GraphQL server) on serverless platforms like AWS Lambda is the cold-start problem which is often related to the size of the deployed application. (See this tweet.)
A possible solution for this problem could be to turn GraphQL queries into persisted queries during the
rw build
step and leverage a similar approach as the Next.js route-based code splitting. I.e. split up a GraphQL schema into multiple smaller "pre-compiled" query endpoints which results in a much smaller code-size footprint per endpoint and allows for massive speed improvements (see graphql-jit).