Book Image

Python Microservices Development

Book Image

Python Microservices Development

Overview of this book

We often deploy our web applications into the cloud, and our code needs to interact with many third-party services. An efficient way to build applications to do this is through microservices architecture. But, in practice, it's hard to get this right due to the complexity of all the pieces interacting with each other. This book will teach you how to overcome these issues and craft applications that are built as small standard units, using all the proven best practices and avoiding the usual traps. It's a practical book: you’ll build everything using Python 3 and its amazing tooling ecosystem. You will understand the principles of TDD and apply them. You will use Flask, Tox, and other tools to build your services using best practices. You will learn how to secure connections between services, and how to script Nginx using Lua to build web application firewall features such as rate limiting. You will also familiarize yourself with Docker’s role in microservices, and use Docker containers, CoreOS, and Amazon Web Services to deploy your services. This book will take you on a journey, ending with the creation of a complete Python application based on microservices. By the end of the book, you will be well versed with the fundamentals of building, designing, testing, and deploying your Python microservices.
Table of Contents (20 chapters)
Title Page
Credits
About the Author
About the Reviewer
www.PacktPub.com
Customer Feedback
Preface
Introduction

Chapter 5. Interacting with Other Services

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 could also have more service-to-service interactions, where an event in a service triggers a series of reactions...