In the previous chapter, the Runnerly monolithic app was split into several microservices, and more network interactions between the different parts were consequently added.
When a user looks at the main web view, the application needs to fetch the list of runs and races from the database and the races. The network calls that are triggered by that request are synchronous because we want to display the results immediately.
On the other hand, the Celery workers are doing their duty in the background, and they receive their order via a Redis broker asynchronously.
There are also cases where a mix of synchronous and asynchronous calls are useful. For instance, letting the user pick a new training plan can trigger the creation of a series of new runs in the background while displaying some info about the plan itself.
In future versions of Runnerly, we...
