Book Image

Hands-On Swift 5 Microservices Development

Book Image

Hands-On Swift 5 Microservices Development

Overview of this book

The capabilities of the Swift programming language are extended to server-side development using popular frameworks such as Vapor. This enables Swift programmers to implement the microservices approach to design scalable and easy-to-maintain architecture for iOS, macOS, iPadOS, and watchOS applications. This book is a complete guide to building microservices for iOS applications. You’ll start by examining Swift and Vapor as backend technologies and compare them to their alternatives. The book then covers the concept of microservices to help you get started with developing your first microservice. Throughout this book, you’ll work on a case study of writing an e-commerce backend as a microservice application. You’ll understand each microservice as it is broken down into details and written out as code throughout the book. You’ll also become familiar with various aspects of server-side development such as scalability, database options, and information flow for microservices that are unwrapped in the process. As you advance, you’ll get to grips with microservices testing and see how it is different from testing a monolith application. Along the way, you’ll explore tools such as Docker, Postman, and Amazon Web Services. By the end of the book, you’ll be able to build a ready-to-deploy application that can be used as a base for future applications.
Table of Contents (19 chapters)

Understanding when to communicate

Let's face it your microservices will, sooner or later, communicate with each other. In this section, we will explore when they should communicate and what should be communicated. The cases in which microservices can communicate with each other can be limited to the following cases:

  • Data verification
  • Data processing
  • Data aggregation
  • Data management

Notice that they all start with Data? That is actually an important hint: microservices usually only communicate with each other for internal purposes. This means that the request that is sent from one service to another almost never happens synchronously with a user request but rather through internal jobs, such as cron jobs.

For example, let's say we want to verify some user input, such as an order. The order contains products, and those products have prices. Of course, we want...