Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shouldn't require/execute resolvers.js when deploying the built in resolvers lambda #12

Open
hypexr opened this issue Aug 12, 2020 · 4 comments

Comments

@hypexr
Copy link

hypexr commented Aug 12, 2020

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.

@eahefnawy
Copy link
Member

eahefnawy commented Aug 26, 2020

how could it be parsed differently? AST? 🤔

@hypexr
Copy link
Author

hypexr commented Aug 26, 2020

Woah, never heard of AST before, but looks like a perfect fit.

@eahefnawy
Copy link
Member

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 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
@hypexr
Copy link
Author

hypexr commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants