Skip to content

Commit 44e73d4

Browse files
docs: extend contribution guide
1 parent 1a2e3a2 commit 44e73d4

File tree

5 files changed

+861
-126
lines changed

5 files changed

+861
-126
lines changed

ARCHITECTURE.md

+73
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,73 @@
1+
# Architecture
2+
3+
This codebase is set up as a [Cargo workspace](https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html). The `rover` binary is built from the root `bin` target, which is a thin wrapper around the `rover-client` library crate.
4+
5+
## CLI Design
6+
7+
Great thought and attention has been paid to Rover's design, and any new command surface must be considered holistically.
8+
9+
### Command layout
10+
11+
Rover commands are laid out as `rover [NOUN] [VERB]` to create clear separation of concerns for multiple areas of graph management.
12+
13+
### Designing new commands
14+
15+
Generally, we are hesitant to add a new `NOUN` to Rover's surface area, unless there is a clear and real need.
16+
17+
An example of a clear need is the `graph` vs. `subgraph` vs. `supergraph` command structure. Each of these nouns has similar associated verbs.
18+
19+
Let's look at the `fetch` commands as an example. `rover graph fetch` and `rover subgraph fetch` each take a positional required `<GRAPH_REF>` argument, and `subgraph fetch` also has a required `--subgraph` flag. It really looks like there doesn't need to be differentiation between these commands. We could have made this behavior implicit by making `--subgraph` optional, and only returning a subgraph schema if the `--subgraph` argument was provided.
20+
21+
The problem with this approach is that having two different return types from the same command leads to unexpected results and makes it difficult to understand the mental model needed to work with the graph registry. Additionally, it would have made it difficult to design commands that _only_ exist for `subgraphs`, and vice versa (such as `rover subgraph check`).
22+
23+
In general, it is best to keep related commands together, and to avoid cognitive complexity wherever possible. New commands should either be associated with an existing top-level noun, or a new noun should be proposed.
24+
25+
### Error Handling
26+
27+
28+
29+
### Project Structure
30+
31+
- `Cargo.toml`: crate metadata, including definitions for both internal and external dependencies
32+
33+
- `Cargo.lock`: an autogenerated lockfile for Rover's dependencies
34+
35+
- `src`: the `rover` CLI
36+
- `src/bin/rover.rs`: the entry point for the CLI executable
37+
- `src/command`: logic for the CLI commands
38+
- `src/command/output.rs`: Enum containing all possible `stdout` options for Rover commands
39+
- `src/command/{command_name}/mod.rs`: Contains the definition of Rov
40+
- `src/utils`: shared utility functions
41+
- `src/error`: application-level error handling including suggestions and error codes
42+
- `src/cli.rs`: Module containing definition for all top-level commands
43+
- `src/lib.rs`: all the logic used by the CLI
44+
45+
- `tests`: Integration tests
46+
47+
- `crates`
48+
- `crates/houston`: logic related to configuring rover
49+
- `crates/robot-panic`: Fork of `human-panic` to create panic handlers that allows users to submit crash reports as GitHub issues
50+
- `crates/rover-client`: logic for querying apollo services
51+
- `crates/sputnik`: logic for capturing anonymous usage data
52+
- `crates/timber`: output formatting and logging logic
53+
- `crates/xtask`: logic for building and testing Rover
54+
55+
- `.cargo`: Sets up `cargo xtask` commands in the workspace
56+
57+
- `docs`
58+
- `source/*.md`: Individual documentation pages
59+
- `source/assets`: Images and other resources
60+
- `static/_redirects`: [Netlify redirects](https://docs.netlify.com/routing/redirects/)
61+
62+
- `netlify.toml`: Configuration for Rover's [docs](https://apollographql.com/docs/rover)
63+
64+
- `installers`
65+
- `binstall`: Rover's cross-platform installer that downloads and installs prebuilt binaries
66+
- `npm`: Rover's npm installer that downloads and installs prebuilt binaries
67+
68+
- `.github`
69+
- `ISSUE_TEMPLATE`: Issues templates for our GitHub repository
70+
- `workflows/lint.yml`: GitHub Action that checks for idiomatic code style, proper formatting, and broken markdown links
71+
- `workflows/release.yml`: GitHub Action that builds cross-platform binaries and creates a GitHub release when a version is tagged
72+
- `workflows/test.yml`: Runs integration and unit tests on each commit that is pushed to GitHub
73+

0 commit comments

Comments
 (0)