Add support for inspecting multiple clients

[jerelmiller]

Fixes #822

Adds support for connecting and inspecting multiple Apollo Client instances simultaneously. This allows apps that use multiple client instances (for example with a microfrontends) to inspect the state of each of these client instances. This takes advantage of the upcoming feature in 3.11 that will enable users to name their client instance making it easy to identify which client they're inspecting.

This works with the "Explorer" tab as well. Changing clients will rerun the introspection query for that client and send GraphQL requests through that client.

---

This PR includes a major refactor to several areas of the code base. Up to this point, much of the logic for handling messages from the hook script was handled in the devtools.ts script. That script was then responsible for syncing data to the React app running the UI. The UI used its own ApolloClient instance to sync data to the UIs, but it did so exclusively through manual cache updates in combination with the @client directive.

This PR switches to use a SchemaLink in combination with RPC calls to treat it more like client/server setup. This means we can move things like data polling to the React app. This has the added benefit that we only need to sync the data requested by a particular view. For example, we know longer need to sync all mutation data and cache data when looking at the "Queries" tab, which should be more efficient and add less strain on the running app. This is a natural result of switching to the resolver model for syncing that data.

The devtools script is now not much more than a message bus between the client port and the panel window, which drastically simplifies it. Moving forward, we'll add much more of the logic-heavy code to the React app itself, making it feel more like a traditional SPA; a pattern we are all familiar with.

[relativeci]

#710 Bundle Size — 1.5MiB (+16.41%).

c653494(current) vs c223f14 main#702(baseline)

Warning

Bundle contains 13 duplicate packages – View duplicate packages

Warning

Bundle introduced 21 new packages: @xstate/react, @graphql-tools/schema, use-isomorphic-layout-effect and 18 more – View changed packages

Bundle metrics   6 changes 3 regressions

	Current #710	Baseline #702
Initial JS	1.46MiB(+16.88%)	1.25MiB
Initial CSS	0B	0B
Cache Invalidation	97.17%	2.54%
Chunks	5	5
Assets	12	12
Modules	1216(+16.92%)	1040
Duplicate Modules	51(+4.08%)	49
Duplicate Code	3.34%(-14.8%)	3.92%
Packages	182(+12.35%)	162
Duplicate Packages	10	10

Bundle size by type   1 change 1 regression

	Current #710	Baseline #702
JS	1.46MiB (+16.88%)	1.25MiB
IMG	35.85KiB	35.85KiB
HTML	810B	810B
Other	778B	778B

---

Bundle analysis report Branch jerel/multiple-clients Project dashboard

[phryneas]

Only very minor nits so far.

[phryneas]

Suggested change

	const knownClients = new Map<ApolloClient<SafeAny>, string>();
	const knownClients = new WeakMap<ApolloClient<SafeAny>, string>();

Let's ensure that the devtools don't cause any memory leaks

[jerelmiller]

Unfortunately I need to be able to traverse this map to be able to look up which client belongs to which id, otherwise it defeats the purpose of this feature.

I probably could use some combination of WeakRef and WeakSet/WeakMap for this to be able to perform some kind of iteration along with FinalizationRegistry to detect when the client has been garbage collected, but definitely a bit more complicated than it seems. How do you feel about a followup PR that does this in isolation?

[phryneas]

This seems to have problems with older AC versions - the dropdown doesn't show up. Once that's fixed, LGTM

[phryneas]

Could I suggest a skipPollAttempt watchQuery defaultOption? That would synchronize this even if we had it in multiple places.

[jerelmiller]

Will look to address this in a followup PR to avoid holding up this release. Thanks for the review!

[jerelmiller]

Discussed over Slack, but posting here for transparency:

The issue with the older client versions wasn't a bug with the devtools, but rather because the client config updated in this PR is using the newer devtools option that will be introduced in 3.11 instead of the now-deprecated connectToDevtools option. The connectToDevtools option, when not set explicitly, will only be set to true if it doesn't detect a window.__APOLLO_CLIENT__ instance: https://github.com/apollographql/apollo-client/blob/3f6d023db2d7d6bf977060dd5db6291fd64e85e6/src/core/ApolloClient.ts#L204-L206

After downgrading and reverting back to the explicit connectToDevtools: true option, multiple clients started showing up again in the devtools.

Discovered non-blocking change and will address additional feedback in followup PR