From 525ad08d81ef5fd3332188598ebb4177d9724694 Mon Sep 17 00:00:00 2001 From: Daniel Baptista Dias Date: Fri, 8 Sep 2023 10:33:33 -0300 Subject: [PATCH] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Julianne Fermi Co-authored-by: Adnan Rahić --- docs/docs/live-examples/pokeshop/overview.md | 4 ++-- .../pokeshop/use-cases/import-pokemon-from-stream.md | 10 +++++----- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/docs/live-examples/pokeshop/overview.md b/docs/docs/live-examples/pokeshop/overview.md index e3581e7e66..8d27784152 100644 --- a/docs/docs/live-examples/pokeshop/overview.md +++ b/docs/docs/live-examples/pokeshop/overview.md @@ -18,7 +18,7 @@ We have three use cases that use each component of this structure and that can b - [Get Pokemon by ID](./use-cases/get-pokemon-by-id.md): Given a Pokemon ID, this endpoint returns the data of a Pokemon. If the same Pokemon was queried, the API will use its cache to return it. - [List Pokemon](./use-cases/list-pokemon.md): Lists all Pokemons registered into Pokeshop. - [Import Pokemon](./use-cases/import-pokemon.md): Given a Pokemon ID, this endpoint does an async process, going to PokeAPI to get Pokemon data and adding it to the database. -- [Import Pokemon from Stream](./use-cases/import-pokemon-from-stream.md): Listening to a Stream, this usecase also does an async process, going to PokeAPI to get Pokemon data and adding it to the database. +- [Import Pokemon from Stream](./use-cases/import-pokemon-from-stream.md): Listening to a Stream, this use case also does an async process, going to PokeAPI to get Pokemon data and adding it to the database. ## System Architecture @@ -28,7 +28,7 @@ The system is divided into two components: - a **Queue Worker** who deals with background processes, receiving data from the API - a **Stream Worker** who handles import events sent from a stream -The communication between the API and Queue Worker is made using a `RabbitMQ` queue, and both services emit telemetry data to Jaeger and communicate with a Postgres database. Additionaly, a Stream Worker listens to a `Kafka` stream to see if there is any import event sent on it to execute. +The communication between the API and Queue Worker is made using a `RabbitMQ` queue, and both services emit telemetry data to Jaeger and communicate with a Postgres database. Additionally, a Stream Worker listens to a `Kafka` stream to see if there is any import event sent on it to execute. A diagram of the system structure can be seen here: diff --git a/docs/docs/live-examples/pokeshop/use-cases/import-pokemon-from-stream.md b/docs/docs/live-examples/pokeshop/use-cases/import-pokemon-from-stream.md index 725bb5cce6..0db2264215 100644 --- a/docs/docs/live-examples/pokeshop/use-cases/import-pokemon-from-stream.md +++ b/docs/docs/live-examples/pokeshop/use-cases/import-pokemon-from-stream.md @@ -1,8 +1,8 @@ # Pokeshop API - Import Pokemon from Stream -This use case showcases a more complex scenario involving an async process. Usually, when working with microservices, there are use cases where some of the processing needs to happen asynchronously, for example, when triggering a user notification, generating reports or processing a payment order. With this endpoint, we provide an example of how users can implement trace-based testing for such scenarios. +This use case showcases a more complex scenario involving an async process. Usually, when working with microservices, there are use cases where some of the processing needs to happen asynchronously. For example, when triggering a user notification, generating reports or processing a payment order. With this endpoint, we provide an example of how users can implement trace-based testing for such scenarios. -Here the process listens to a stream, and whenever an event is read from it it triggers the following process: +Here the process listens to a stream, and whenever an event is read from it, the following process is triggered: ```mermaid sequenceDiagram participant Stream as Kafka @@ -35,13 +35,13 @@ Using Tracetest, we can [create a test](../../../web-ui/creating-tests.md) that ### Traces -Running these tests for the first time will create an Observability trace like the image below, where you can see spans for the stream messaging, the PokeAPI (external API) call and database calls. +Running these tests for the first time will create a distributed trace like the image below, where you can see spans for the stream messaging, the PokeAPI (external API) call and database calls. ![](../images/import-pokemon-from-stream-trace.png) ### Assertions -With this trace, we can build [assertions](../../../concepts/assertions.md) on Tracetest and validate the API and Worker behaviors: +With this trace, we can build [assertions](../../../concepts/assertions.md) with Tracetest and validate the API and Worker behavior: - **A message was received from Kafka stream:** ![](../images/import-pokemon-from-stream-message-received.png) @@ -59,7 +59,7 @@ Now you can validate this entire use case. ### Test Definition -If you want to replicate this entire test on Tracetest, you can replicate these steps on our Web UI or using our CLI, saving the following test definition as the file `test-definition.yml` and later running: +If you want to replicate this entire test with Tracetest, you can replicate these steps in the Web UI or using the CLI, saving the following test definition as the file `test-definition.yml` and running: ```sh tracetest run test -f test-definition.yml