beatlabs/patron

Consolidate and Simplify examples

mantzas opened this issue · 2 comments

Is your feature request related to a problem? Please describe

We have a lot of examples and we have also a lot of repetition.
We should consolidate our examples to show off only the component usage as clients seems very straight forward.
We could even create just one example in order to consolidate them all into one. After all Patron was build exactly to handle multiple components.
By creating this single example we could actually introduce a component test to verify that we have not broken anything major.
This component test will also test the usage of the clients in this case.

Describe the solution

  • Create only one example which should contain all our components (AWS SQS, AMQP, HTTP, gRPC)
  • Create a component test by running the above example in a container and by using the various components we should be able to verify how it works.

The above can be implemented by introducing an map that holds all the messages send sync or async which can be checked with a HTTP and gRPC endpoint.

👍 I agree with the point about repetition; From a reader's perspective, it can be difficult to navigate through very similar examples to find what you're looking for

Regarding consolidating the examples into one:
I find that one example per component is more valuable than consolidating all examples into one.

  • As a patron user, I mainly look at examples when I want to see the usage of a specific component.
  • For this use case, I think that having just one example with everything will increase the noise for the reader

I agree that one example is valuable, but I think it's not as helpful as one example per component.
Maybe we could have both:

  • One example per component showcasing most of the functionality of the component and the corresponding client
  • One example containing multiple components showcases the basic use of multiple components

The proposal is to create an example service which:

  • Exposes some HTTP endpoints
  • Exposes a gRPC endpoint
  • Creates a kafka, AWS SQS, MQTT consumer

The concept could be to use the sync API to publish messages to the async consumenrs.
We can create a HTTP endpoint to publish a message in Kafka which is then consumed by the Kafka consumer.
The flow could be the following:

  • HTTP POST to publish to Kafka with a UUID. Kafka target can be a field in the payload and we can support other brokers.
  • Consume from Kafka/SQS/etc and save it in a DB/Memory
  • HTTP GET with the UUID to get the message

The same can be done for gRPC.

The benefits of such a simple setup are:

  • Extensibility. We just support more targets for publishing e.g. MQTT
  • Testability. The service can be used as a component test and be part of the CI
  • Example for developers to see how to do things
  • Simple approach versus the current multi-example approach. All in one