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
Refer #693 for some context, as this seems to be an extension of the other issue and specifically this comment from @benjie in 2018:
Are you trying to load it up as an executable schema? If so you cannot do that via JSON because the schema is generated in memory. We don't have a way for doing that currently - it's highly dynamic.
Thing that works:
A process generates the SDL in postgraphile using writeCache option and stores this Graphql SDL.
API call triggers the lambda, which then reads this SDK using the readCache option, which then handles the query and returns the response.
Problem:
Our instrumentation shows that that createPostgraphileSchema function takes ~2-2.5 seconds of time to read the cache file and then make the call to database to resolve the query. Our response times during has changed from 1-2 secs overall to >4 seconds now. One problem might be the size of the SDL, which on an average for us is ~2.5MB as JSON.
Question:
I try to use createPostgraphileSchema in the first lambda run, and then try to cache the postgraphile object (in some caching system like memcached or redis or such; memcached response times are in milliseconds) and then reload it in a subsequent lambda run. A serialisation operation of the schema and resolvers (in the first run) and a comparatively faster deserialisation of the object in memory should be much faster than reading the schema repeatedly and creating the object in memory for every Lambda API call.
Apparently, it seems to not work as thought as serialising the GraphQL schema object seems to be impossible. Is there a way the community has handled this issue when using Graphql on serverless and tuning for performance?
The text was updated successfully, but these errors were encountered:
In V5 you can export your schema as executable code, then you simply run that code (no PostGraphile, no Graphile Build hooks system, just new GraphQLObjectType(...) and similar calls) directly - completely eradicating this issue.
Refer #693 for some context, as this seems to be an extension of the other issue and specifically this comment from @benjie in 2018:
Thing that works:
writeCache
option and stores this Graphql SDL.readCache
option, which then handles the query and returns the response.Problem:
Our instrumentation shows that that
createPostgraphileSchema
function takes ~2-2.5 seconds of time to read the cache file and then make the call to database to resolve the query. Our response times during has changed from 1-2 secs overall to >4 seconds now. One problem might be the size of the SDL, which on an average for us is ~2.5MB as JSON.Question:
I try to use
createPostgraphileSchema
in the first lambda run, and then try to cache the postgraphile object (in some caching system like memcached or redis or such; memcached response times are in milliseconds) and then reload it in a subsequent lambda run. A serialisation operation of the schema and resolvers (in the first run) and a comparatively faster deserialisation of the object in memory should be much faster than reading the schema repeatedly and creating the object in memory for every Lambda API call.Apparently, it seems to not work as thought as serialising the GraphQL schema object seems to be impossible. Is there a way the community has handled this issue when using Graphql on serverless and tuning for performance?
The text was updated successfully, but these errors were encountered: