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
Unexpected errors can occur when resolvers.js is loaded as part of the deploy process.
For example, it's common to create things like DB connections outside of the handler so that they persist as long as the lambda is running without being recreated on each call. Another thing that I'm experiencing is that I instrument my lambdas with aws xray and that loads and instruments http which can errors.
If this require was replaced with a fs read file and it was parsed differently it would still be possible to determine the keys under Query and Mutation.
The text was updated successfully, but these errors were encountered:
Using AST is low-level and complicated, so I don't think it'd be worth it for this use case. I was hoping you could share what you mean by "parsing differently" because AST is the only thing I could think of? 😅
hypexr
changed the title
Shouldn't require resolvers.js when deploying the built in resolvers lambda
Shouldn't require/execute resolvers.js when deploying the built in resolvers lambda
Dec 30, 2020
Right, I don't know of a better way, but it does seem like AST is appropriate for this problem. Otherwise it should be specified in a configuration file.
Unexpected errors can occur when resolvers.js is loaded as part of the deploy process.
For example, it's common to create things like DB connections outside of the handler so that they persist as long as the lambda is running without being recreated on each call. Another thing that I'm experiencing is that I instrument my lambdas with aws xray and that loads and instruments http which can errors.
If this require was replaced with a fs read file and it was parsed differently it would still be possible to determine the keys under Query and Mutation.
The text was updated successfully, but these errors were encountered: