[vtadmin-web] Query vtadmin-api from vtadmin-web with fetch + react-query

[doeg]

Description

tl;dr:
This PR implements the humble beginnings of our vtadmin-api HTTP fetchers using native fetch and react-query. The API boundary is one of the spicier parts of any client, particularly when it comes to testing and (strong) typing. To that end, I focused on adding a bunch of tests + commentary -- I would love your feedback on these parts, in particular, if you have any.

Now the usual rambling...

react-query is still somewhat new to me, and Mock Service Workers are brand new to me. I really like how this implementation came together, but I expect a lot of unknown unknowns (for me) here. So I've tried to keep this implementation very modular + flexible in anticipation of us wanting to, say, swap in redux instead of react-query, or use gRPC instead of HTTP.

I expect the functions in api/http.ts to become more general as we add more bindings for other vtadmin-api endpoints. I also have a feeling we'll want to pull out the Mock Service Worker parts of api/http.test.ts (especially since we could re-use it as a hermetic/offline development server, which might be interesting). For this PR, though, I tried to keep things straightforward and co-located.

This is also the first use of one (1) environment variable!

It still doesn't look like much... but! The exciting thing is that vtadmin-web is now issuing HTTP requests against vtadmin-api and populating the UI with ✨ real data ✨ from the local Vitess + Docker example.

A couple of TODOs for me that I'll need to ticket:

• Add CI targets for vtadmin-web unit tests + linting
• Streamline the local development process described in the README

Related Issue(s)

• [vtadmin-api] Add static file service discovery implementation #7229

Checklist

• Should this PR be backported?
• Tests were added or are not required
• Documentation was added or is not required

Deployment Notes

N/A (yet)

Impacted Areas in Vitess

Components that this PR will affect:

• Query Serving
• VReplication
• Cluster Management
• Build

[ajm188]

I really really like this setup. I have one concern about error testing, but after that this lg2m

[ajm188]

but where did the lighter fluid come from?

[doeg]

(muffled final_countdown.wav plays in the distance)

[ajm188]

(curious) As a Go programmer, this trailing comment line looks odd to me. Is this JS/TS convention that I should learn to get used to?

[doeg]

Nah I just like whitespace for multi-paragraph comments. I can remove it though!

[ajm188]

No, totally fine!

[doeg]

Too bad I did it anyway!!! 😈

[ajm188]

God I love union types so much, go2 pls 🥺

[ajm188]

One of the potential downsides to doing exact equality checks on error messages means that if we ever add additional context to errors, then we can potentially break a bunch of tests for an unrelated change. Do we want to force that, or does it make sense to expect().contains()?

[doeg]

Hm, probably the best way is to extend Error with custom subclasses. Unfortunately, this is pretty cumbersome to do in JS/TS (especially compared to go 🥺) BUT we can then do assertions like expect(e.name).toEqual('InvalidHttpEnvelope') or whatever, which also gives us more flexibility with e.message.

I considered this before and didn't do it because I'm uh... well, it's a little bit of work 😬 but it's super worth it, so thanks for pointing this out!

[doeg]

@ajm188 thank you for the great suggestions. 🙏 I made a couple of changes:

• I defined subclasses of Error for anticipated failure scenarios in api/http.ts per your comment here. The tests are a lot sturdier now.

• I added a test case for when /api/tablets returns an { ok: false } response.

• I added a dumb error placeholder to the UI, which looks silly but shows off how nice react-query's error handling is.