[vtadmin-web] The tiniest possible first implementation of vtadmin-web

[doeg]

Description

This is the tiniest possible first implementation of vtadmin-web that "does something", even though that "something" (rendering static, albeit strongly typed, data) is simple and, honestly, a little dumb. 😎

That said, if you feel this is too simple + useless to merge, I'm happy to wait until we implement data fetching. However, pretty much anything interesting we'd want to do beyond this will require #7187 to be merged first. :)

Likely the best way to review this PR is to pull the branch and run it locally following the "Getting Started" section of the README. Please let me know if you run into any trouble + I would be delighted to help debug. 🙇‍♀️

Here's a screenshot of what it looks like with the ⚠️ immense caveat ⚠️ that this UI is just a placeholder! I ✨ promise ✨ the real UI will be 10000x more amazing. 😁

Here's what it looks like when developing locally with npm start. create-react-app's development server comes with all the devxp niceties you'd expect, like hot reloading:

vtadmin-dev-setup.mov

Despite its (very!) humble appearance, this PR does a bunch of necessary, foundational work. I did my best to document everything in the README, but here's a brief tl;dr:

• The front-end is scaffolded using create-react-app, since we all have (many, many) better things to do than to maintain webpack configs.

• Everything is strongly typed with TypeScript. Even better, we generate TypeScript bindings and utility classes from the very same .proto files we use in vtadmin-api and elsewhere. 🎉 This means we get strongly typed API responses, even though we'll be using HTTP (rather than gRPC). So, in other words, even though this PR uses dumb fake data, that dumb fake data implements the exact same types we'll expect from our real API. :)

• On the topic of HTTP... for this PR, I did the simplest possible thing and defined a handful of fake tablets here. Once Initial vtadmin-api, clusters, and service discovery #7187 is merged, we can set up the data fetching layer (which will be using react-query!)... and then things will start getting interesting. 😼 It's also when I'll add the first tests and environment variables.

• I've added a fairly comprehensive set of linters and formatters, as well as some notes on setting up VS Code for those that use it. I'm happy to add these to CI, although I'll have to read up on how GitHub Actions works. 😊

• Examples of how we can use SCSS modules and :root variables for styling are included. This is a set-up that's worked super well for the internal Vitess tooling we've built, and the best part is that it makes implementing dark mode super easy later on. 😎

I'm happy to expound on any of the above! 😁

Related Issue(s)

• RFC: VTAdmin Architecture #7117 (VTAdmin RFC)
• Initial vtadmin-api, clusters, and service discovery #7187 (initial vtadmin-api implementation)

Checklist

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

Deployment Notes

N/A (we'll add deployment notes once vtadmin-web and vtadmin-api are deployable together.)

Impacted Areas in Vitess

Components that this PR will affect:

• Query Serving
• VReplication
• Cluster Management (though not really, since VTAdmin is completely isolated from any critical build/deploy paths)
• Build

[doeg]

This file was thieved directly from https://github.com/vitessio/vitess/pull/7187/files#diff-eeea62c2adbce1061fd9db0eb38fcb936efb2e158ed0d332bfa5568db563a1c3

[rohit-nayak-ps]

lgtm