diff --git a/src/api/parser/README.md b/src/api/parser/README.md
index 3a5e3a8686..a6219742aa 100644
--- a/src/api/parser/README.md
+++ b/src/api/parser/README.md
@@ -1,6 +1,6 @@
-# Parser Service: (To be updated when Parser service is dockerized and live)
+# Parser Service:
-The Parser service parses posts from user's feeds to populate Redis
+Read more on Parser at `src/web/docusaurus/docs/api-services/parser.md`
## Install
@@ -23,7 +23,3 @@ pnpm dev
```
By default the server is running on .
-
-### Examples
-
-## Docker
diff --git a/src/web/docusaurus/docs/api-services/parser.md b/src/web/docusaurus/docs/api-services/parser.md
index 30fa10cb44..f4d0edb8d2 100644
--- a/src/web/docusaurus/docs/api-services/parser.md
+++ b/src/web/docusaurus/docs/api-services/parser.md
@@ -1,6 +1,6 @@
### Parser Service
-Telescope's back-end began as a single, monolithic node.js app. During the 2.0 release, much of the back-end was split into separate microservices. Parts of the legacy back-end code were still in use, see `src/backend/*` which were removed in 3.0 release, telescope now consists of only microservices/workspaces.
+Telescope's back-end began as a single, monolithic node.js app. During the 2.0 release, much of the back-end was split into separate microservices. Parts of the legacy back-end code were still in use but removed in 3.0 release, Telescope now consists of only microservices/workspaces.
The current system uses the parser service in order to run the feed parser and feed queue, see [`src/api/parser/data/feed.js`](https://github.com/Seneca-CDOT/telescope/blob/master/src/api/parser/src/data/feed.js). The processed feeds and posts are then stored in `Redis` (cache) and `Elasticsearch` (indexing) databases, and various microservices use these in order to get their data.
diff --git a/src/web/docusaurus/docs/architecture.md b/src/web/docusaurus/docs/architecture.md
index ab71a16f41..7a78ed53c0 100644
--- a/src/web/docusaurus/docs/architecture.md
+++ b/src/web/docusaurus/docs/architecture.md
@@ -18,32 +18,15 @@ It shows RSS/Atom blog feeds (on the left) being downloaded (1) and then queued
The following gives an overview of the current (i.e. 2.4.0) design of Telescope. There are a number of major systems that make up the app:
-- legacy monolithic back-end (1.0)
- back-end microservices (2.0)
- front-end web app
- SAML2-based authentication and authorization
- autodeployment server
- test, build, and other automation tooling
-### Legacy Monolithic Back-end (1.0)
-
-Telescope's back-end began as a single, monolithic node.js app. During the 2.0 release, much of the back-end was split into separate microservices (see below). However, parts of the legacy back-end code are still in use, see `src/backend/*`.
-
-The current system uses the legacy backend in order to run the feed parser and feed queue, see `src/backend/feed/*`. The processed feeds and posts are then stored in Redis (cache) and Elasticsearch (indexing) databases, and various microservices use these in order to get their data.
-
-Telescope's data model is built on Feeds and Posts. A feed represents an RSS/Atom feed, and includes metadata about a particular blog (e.g., URL, author, etc) as well as URLs to individual Posts. A Post includes metadata about a particular blog post (e.g., URL, date created, date updated, etc).
-
-The legacy back-end is started using `pnpm start` in the root of the Telescope monorepo, and it (currently) must be run alongside the microservices. When it runs, the logs show information about feeds being parsed in real-time, which continues forever.
-
-The parser downloads the [CDOT Feed List](https://wiki.cdot.senecacollege.ca/wiki/Planet_CDOT_Feed_List#Feeds), parses it, creates `Feed` objects and puts them into a queue managed by [Bull](https://github.com/OptimalBits/bull) and backed by Redis. These are then processed in `src/backend/feed/processor.js` in order to download the individual Posts, which are also cached in Redis.
-
-There is code duplication between the current back-end and the Parser microservice (see `src/api/parser`), and anyone changing the back-end will also need to update the Parser service at the same time (for now). One of the 3.0 goals is to [remove the back-end and move all of this logic to the Parser service](https://github.com/Seneca-CDOT/telescope/issues?q=is%3Aissue+is%3Aopen+parser+service).
-
-In production, the legacy back-end is deployed as a container named `telescope` (see `docker/production.yml`), and its Dockerfile lives in the root at `./Dockerfile`.
-
### Back-end Microservices (2.0)
-The legacy back-end has been split into a series of microservices. Each microservice follows a similar architectural pattern and has a single focuses. The current microservices include:
+Telescope consists of a series of microservices. Each microservice follows a similar architectural pattern and has a single focuses. The current microservices include:
- SSO Auth Service (`src/api/sso`) - authentication and authorization with Seneca's SSO service
- Feed-Discovery Service (`src/api/feed-discovery`) - blog feed discovery and validation
@@ -52,7 +35,7 @@ The legacy back-end has been split into a series of microservices. Each microser
- Posts Service (`src/api/posts`) - API for accessing Post and Feed data in Redis (probably not well named at this point)
- Search Service (`src/api/search`) - API for doing searches against Elasticsearch
- Status Service (`src/api/status`) - API for accessing Telescope status information, as well as providing the Dashboards
-- Parser Service (`src/api/parser`) - feed and post parsing. Currently disabled, see
+- Parser Service (`src/api/parser`) - feed and post parsing.
All microservices are built on a common foundation, the [Satellite module](https://github.com/Seneca-CDOT/telescope/tree/master/src/satellite). Satellite provides a common set of features for building Express-based microservices, with proper logging, health checks, headers, authorization middleware, as well as connections to Redis and Elasticsearch. It saves us having to manage the same set of dependencies a dozen times, and repeat the same boilerplate code.
diff --git a/src/web/docusaurus/docs/contributing/debugging.md b/src/web/docusaurus/docs/contributing/debugging.md
index 0c21c7c196..99f4d1daef 100644
--- a/src/web/docusaurus/docs/contributing/debugging.md
+++ b/src/web/docusaurus/docs/contributing/debugging.md
@@ -32,7 +32,6 @@ Now that we know how to launch the server. We will look at different launching o
![VS Launch Options Screenshot](../../static/img/VS-Launch-Options.png)
-1. Launch Telescope -> Launches index.js and tries to run the backend.
1. Launch Auto Deployment -> Launches autodeployment found in tools.
1. Launch All Tests -> Runs all the tests in the tests folder.
1. Launch Opened Test File -> Will run a test that is currently opened in a VS code tab.
diff --git a/src/web/docusaurus/docs/getting-started/environment-setup.md b/src/web/docusaurus/docs/getting-started/environment-setup.md
index 0d9dac1f4f..aaf14b5afd 100644
--- a/src/web/docusaurus/docs/getting-started/environment-setup.md
+++ b/src/web/docusaurus/docs/getting-started/environment-setup.md
@@ -260,8 +260,6 @@ This is the default setting, you do not need to copy or modify any `env` file.
```bash
pnpm services:start
-
-pnpm start
```
Then visit `localhost:8000` in a web browser to see Telescope running locally. `localhost:3000/posts` will show you the list of posts in JSON
diff --git a/src/web/docusaurus/docs/tools-and-technologies/pino.md b/src/web/docusaurus/docs/tools-and-technologies/pino.md
index bc7e1619e0..2b35bdab2b 100644
--- a/src/web/docusaurus/docs/tools-and-technologies/pino.md
+++ b/src/web/docusaurus/docs/tools-and-technologies/pino.md
@@ -4,12 +4,12 @@ sidebar_position: 5
# Logging Support Using Pino
-This project uses [Pino](http://getpino.io/#/) to provide support for logging in Production as well as development environments. The [logger.js](https://github.com/Seneca-CDOT/telescope/blob/master/src/backend/utils/logger.js) module exports a logger instance that can be used in other modules to implement logging for important events.
+This project uses [Pino](http://getpino.io/#/) to provide support for logging in Production as well as development environments.`Satellite` exports a `logger` instance (https://github.com/Seneca-CDOT/telescope/blob/master/src/satellite/src/logger.js) that can be used in modules to implement logging for important events.
## How to use the logger
```javascript
-const { logger } = require('../src/backend/utils/logger');
+const { logger } = require('@senecacdot/satellite');
logger.info('Important information...');
logger.trace('Information About Trace');