Add breadcrumbs

Author: brianlovin

docs/admin/intro.md

@@ -1,3 +1,5 @@
+[Table of contents](../readme.md)
+
 # Admin
 
 This directory runs an internal application for viewing core metrics on the platform. While it can be built and run locally, we don't encourage contributors to spend much time here as the dashboard itself will only ever be used internally by the Spectrum team. The code can of course be reviewed for those interested to see what kind of numbers and tools are accessible to our team.

docs/api/graphql/fragments.md

@@ -1,3 +1,5 @@
+[Table of contents](../../readme.md) / [API](../intro.md) / [GraphQL](./intro.md)
+
 # Fragments
 
 Fragments help us to always know exactly what kind of data will be returned for a given query and ensure that we are consistent in what data should be returned to any given component.

docs/api/graphql/intro.md

@@ -1,3 +1,5 @@
+[Table of contents](../../readme.md) / [API](../intro.md)
+
 # GraphQL Intro
 
 We use [`graphql-tools`](http://dev.apollodata.com/tools/graphql-tools/index.html) which lets us use the GraphQL schema language to design our schema. This schema written in the schema language is then combined with our resolvers (which live somewhere else) using `graphql-tools`, which outputs our finished schema that's then used.

docs/api/graphql/pagination.md

@@ -1,3 +1,5 @@
+[Table of contents](../../readme.md) / [API](../intro.md) / [GraphQL](./intro.md)
+
 # Pagination with GraphQL
 
 Even though there is no specific built-in way to paginate GraphQL queries there is a quasi-standard that most people (including us) follow called [Relay Connections Specification](https://facebook.github.io/relay/graphql/connections.htm). Rather than reading a spec that might not help you in pratical applications we recommend reading these two article to get a grasp of the why and how:

docs/api/graphql/testing.md

@@ -1,3 +1,5 @@
+[Table of contents](../../readme.md) / [API](../intro.md) / [GraphQL](./intro.md)
+
 # Testing
 
 We use [Jest](https://facebook.github.io/jest/) for testing. (we recommend reading through the documentation, since it has a lot of great features you might not expect) Most of our tests are "e2e". That's in quotes because with GraphQL "e2e" tests don't do any network request, they still hit our database though and all that. (which is awesome since it's much faster!)

docs/api/graphql/tips-and-tricks.md

@@ -1,3 +1,5 @@
+[Table of contents](../../readme.md) / [API](../intro.md) / [GraphQL](./intro.md)
+
 # Tips and Tricks
 
 ## Keep resolvers as small as possible

docs/api/intro.md

@@ -1,3 +1,5 @@
+[Table of contents](../readme.md)
+
 # API
 
 The Spectrum API is a Node.js web server based on Express.js and GraphQL. It's also houses a websocket server for all of our subscription needs.

docs/deployments.md

@@ -1,8 +1,10 @@
-# Deployment
+[Table of contents](./readme.md)
+
+# Deployments
 
 We use [`now`](https://now.sh) by Zeit for all of our deployments.
 
-## Installation
+### Installation
 
 We recommend installing the [now desktop app](http://zeit.co/download) as it'll keep the command line tool up to date automatically!
 
@@ -12,11 +14,11 @@ If you'd rather not install an app (or are using Windows Substem for Linux) you
 npm install -g now
 ```
 
-## Naming scheme
+### Naming scheme
 
 All our workers are aliased to `<workername>.workers.spectrum.chat`, with the one exception being the API (the API server) which runs at `api.spectrum.chat`. 
 
-### Path aliases
+#### Path aliases
 
 [Now's path alias feature](https://zeit.co/docs/features/path-aliases) takes care of routing requests to the right workers. To see our current production aliases check the `rules.json` file in the root of the project.
 
@@ -28,11 +30,11 @@ now alias spectrum.chat -r rules.json
 
 The same command with a different URL and slightly adapted rules can also be used to create an alpha/beta/staging/... version of the site.
 
-## Frontend and Hyperion 
+### Frontend and Hyperion 
 
 Since the frontend is the part that changes the most often the repo is set up such that typing `now` in the root directory will deploy the frontend with hyperion. (the server-side rendering worker)
 
-### Deploying
+#### Deploying
 
 First, make sure you're in the Space Program `now` team:
 
@@ -60,11 +62,11 @@ now alias spectrum-grtertb34.now.sh hyperion.workers.spectrum.chat
 
 And that's it, you've now deployed a new version of hyperion and the frontend!
 
-## Other workers
+### Other workers
 
 We use [`backpack`](https://github.com/palmerhq/backpack) to get a nice development setup and build process in place for our workers. Since this is a mono-repo and `now` doesn't have any special functionality to handle monorepos we have to deploy the _built_ version of the workers. (compared to the frontend deploy where you deploy the raw code which gets built on the server)
 
-### Deploying
+#### Deploying
 
 First, build the worker you want to deploy to get a bundle with the newest code rather than deploying a stale version:
 
@@ -91,7 +93,7 @@ now build-athena
 
 This will give you an immutable deploy with a unique URL of this worker, something like `https://build-athena-ahsgut23sdyf.now.sh`.
 
-### Replacing the old deploy
+#### Replacing the old deploy
 
 Since we want to keep the workers alive even if nobody sends a request to their healthcheck endpoints we alias them to `<workername>.workers.spectrum.chat`. This ensures `now` overrides the older deploy and only the newest code is running.
 

docs/hyperion (server side rendering)/development.md

@@ -1,3 +1,5 @@
+[Table of contents](../readme.md) / [Hyperion](./intro.md)
+
 # Hyperion development
 
 ### Normal development workflow

docs/hyperion (server side rendering)/intro.md

@@ -1,3 +1,5 @@
+[Table of contents](../readme.md)
+
 # Hyperion
 
 *Hyperion: (/haɪˈpɪəriən/) is one of the twelve Titan children of Gaia and Uranus.*

docs/operations/deleting-users.md

@@ -1,3 +1,5 @@
+[Table of contents](../readme.md)
+
 # Deleting users
 
 Occassionally people request that their account gets deleted on Spectrum. We have a safe way to do this so that it respects the integrity of data across the rest of the database.

docs/operations/importing-rethinkdb-backup.md

@@ -1,3 +1,5 @@
+[Table of contents](../readme.md)
+
 # Importing production data locally
 
 Sometimes it's useful to have production data running locally in rethinkdb for debugging and testing. To get production data running locally, follow these steps:

docs/testing/integration.md

@@ -1,3 +1,5 @@
+[Table of contents](../readme.md) / [Testing](./intro.md)
+
 # Integration tests
 
 We use [Cypress](https://cypress.io) to run our integration tests, which gives you a nice GUI that you can use for your test runs. To run integration tests you have to have both api and the client running. You also need API to be connected to the test database, which you do by setting `TEST_DB`:
@@ -40,7 +42,7 @@ Note that while the Cypress API looks synchronous, it's actually totally asynchr
 
 Also note that Cypress uses Mocha under the hood, where our unit tests use Jest. This means rather than `expect().toEqual()` you'd have to write `expect().to.equal()` due to the syntax difference between the `expect` implementations.
 
-#### Test IDs
+### Test IDs
 
 To verify that certain elements are or aren't on the page we use custom `data-cy` attributes. You render them from React like so:
 

docs/testing/intro.md

@@ -1,3 +1,5 @@
+[Table of contents](../readme.md)
+
 # Testing
 
 We have a test suite consisting of a bunch of unit tests (mostly for the API) and integration tests to verify Spectrum keeps working as expected. The entire test suite is run in CI for every commit and PR, so if you introduce a breaking change the CI will fail and the PR will not be merge-able.

docs/testing/unit.md

@@ -1,4 +1,6 @@
-## Unit tests
+[Table of contents](../readme.md) / [Testing](./intro.md)
+
+# Unit tests
 
 We use [`Jest`](https://github.com/facebook/jest) for our unit testing needs. To run Jest in watch mode locally so the tests run automatically while you're developing run:
 

docs/workers/athena/intro.md

@@ -1,3 +1,5 @@
+[Table of contents](../../readme.md) / [Workers](../intro.md)
+
 # Athena
 
 *Athena (/əˈθiːnə/) is the goddess of wisdom, craft, and war.*

docs/workers/background-jobs.md

@@ -1,3 +1,5 @@
+[Table of contents](../readme.md) / [Workers](intro.md)
+
 # Background jobs
 
 We use [`bull`](https://github.com/OptimalBits/bull) for all of our background job needs. (at the moment that mostly means notification processing and emails) `bull` uses redis under the hood (see docs/setup.md for instructions on how to install redis) to store information about these jobs.

docs/workers/chronos/intro.md

@@ -1,3 +1,5 @@
+[Table of contents](../../readme.md) / [Workers](../intro.md)
+
 # Chronos
 
 *Chronos (/ˈkroʊnɒs/) is the personification of Time in pre-Socratic philosophy*

docs/workers/hermes/intro.md

@@ -1,3 +1,5 @@
+[Table of contents](../../readme.md) / [Workers](../intro.md)
+
 # Hermes
 
 *Hermes (/ˈhɜːrmiːz/) is the messenger god, moving between the worlds of the mortal and the divine.*

docs/workers/intro.md

@@ -1,3 +1,5 @@
+[Table of contents](../readme.md)
+
 # Workers
 
 Our asynchronos background job processing is powered by a series of worker servers.

docs/workers/mercury/intro.md

@@ -1,3 +1,5 @@
+[Table of contents](../../readme.md) / [Workers](../intro.md)
+
 # Mercury
 
 *HMercury (/ˈmɜːrkjʊri/) is the patron god of financial gain, commerce, eloquence (and thus poetry), messages/communication (including divination), travelers, boundaries, luck, trickery and thieves*

docs/workers/pluto/intro.md

@@ -1,3 +1,5 @@
+[Table of contents](../../readme.md) / [Workers](../intro.md)
+
 # Pluto
 
 *Pluto was the ruler of the underworld in classical mythology*

docs/workers/vulcan/intro.md

@@ -1,3 +1,5 @@
+[Table of contents](../../readme.md) / [Workers](../intro.md)
+
 # Vulcan
 
 *Vulcan is the god of fire, including the fire of volcanoes, metalworking, and the forge.*