chapter seven

7 Structuring Concurrent Pipelines

 

This chapter covers

  • Designing convenient-to-use package APIs.
  • Structuring and writing a concurrent HTTP client.
  • Diving into the concurrent pipeline pattern.

We'll write a concurrent client package called hit (the HIT client). This package simulates sending concurrent requests to an HTTP server and measures the server's performance. This simulation approach will allow us to explore concurrency more deeply without getting bogged down in the details of handling HTTP requests (which we'll dive into in the next chapter).

The command-line tool we crafted previously will provide an interface for the HIT client.

Note

Find the source code of this chapter at the link: https://github.com/inancgumus/gobyexample/tree/main/hit

7.1 Laying out the groundwork

We'll first explore the hit package's (the HIT client) design and implement the package. Then, we'll dive into the concurrent pipeline pattern, a technique used to structure concurrent code into a series of concurrent stages or operations. It has many benefits:

  • Maintainability: Easier to fix and update.
  • Readability: Makes code clear and easy to follow.
  • Reusability: Parts can be used again in different places (i.e., programs).

Let's design an easy-to-use and maintainable API for the HIT client.

What makes a good API?

API is everything exported from a package, which is critical because that's what other packages depend on and use. Here are some guidelines for creating a good API:

7.1.1 Result

7.1.2 Client

7.1.3 Wrap up

7.2 Concurrent pipeline pattern

7.2.1 What is a concurrent pipeline?

7.2.2 Producer stage: Generating requests

7.2.3 Throttler stage: Slowing down the pipeline

7.2.4 Splitter stage: Sending requests in parallel

7.2.5 Connecting the stages

7.2.6 Concurrency is an implementation detail

7.2.7 Wrap up

7.3 Exercises

7.4 Summary