Use resolvers context to access dgraph and postgres #106
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolve #101
It may be a good idea to use shared context in resolvers to obtain connections to our storages (dgraph and postgres). At least, this is how it said in Apollo server docs 😁
@gzigzigzeo was concerned about resources freeing and connection pooling. I guess, pg-promise got us covered here, it has a connection pool, it's described in the README. Dgraph case is more complicated for me because its JS client uses protobuf (so we're talking about gRPC connections, right?), and I am not familiar with that. However, they are just an HTTP connections? What problems can we have here? What bothers me is that
dgraph-js
docs state, that resources must be cleared explicitly. We do that on ingest, but we don't do that on queries. Maybe we can useexpress
server, and put dgraph "resources freeing" in some "after request" hook?What do you think about it?
Yeah, also I renamed vaguely named
Connection
class here toDgraph
This change is