In an effort to see how effective this cache is in production during this
alpha phase, we'll print out the stats on the document store every 60
seconds.
The implementation of object-size approximation which is used for cache
eviction purposes in the `InMemoryLRUCache` implementation (via `lru-cache`)
was a short-term location for extensible logic which is better located
within `ApolloServerBase`.
This is particularly important since future logic may necessitate knowing or
understanding the current size (roughly, memory usage) of the in-memory
storage. Effective immediately, this adds support for providing a `dispose`
function which is called when an object is purged from the cache to make
room for another.
While the implementation of the `documentStore` is currently simple enough
to never throw (it is in-memory), it makes some sense to guard against future
extended functionality where an exception might be raised.
Since storing this object in a distributed memory store isn't currently
feasible, I'm not sure what such an exception would be right now, but I
don't mind being proactive!
Ref: https://github.com/apollographql/apollo-server/pull/2111/files#r247618501
Without this change, the `document` property was not set on the
`requestContext` for consumption by request pipeline plugins.
To further guard against this oversight, I've removed the extra `document`
variable which was being used as scoped state for the document and switched to
directly using (and assigning to) the `requestContext.document`.
Nice catch, @glasser!
Ref: https://github.com/apollographql/apollo-server/pull/2111/files#r247617469
Since the registry should be fixed, this should be the last time that we
need to search and replace those resolutions in this file to avoid merge
conflicts and unnecessary staging of `package-lock.json` changes which are
otherwise unrelated to our changes.
(Though to be clear, the registry setting always takes precedence over the
resolutions in this `package-lock.json` file so the scheme was already
strictly enforced to `http` unless the user's local npm configuration had
been manipulated to behave otherwise.)
Ref: https://npm.community/t/some-packages-have-dist-tarball-as-http-and-not-https/285/50
This specific port per integration is pretty brittle to begin with, but it
does work. Currently, the fact that it works is facilitated by the fact
that most people don't use 5555 (Hapi) and 6666 (Express) for anything.
That said, the ever-popular Gatsby uses 8888 by default, so let's use 9999!
