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 Microservices Communication

Microservices are designed and intended to operate as independently as possible. Still, they need to talk to each other once in a while. In this chapter, you will learn what good communication between microservices looks like and what you should avoid. Microservices sometimes have to communicate with each other; for example, when it comes to validating or aggregating information. Imagine that one microservice needs to get data from another one to then visualize it. The first microservice could, of course, access the database directly, but this might threaten the integrity of the second microservice. This is also dangerous because of the database's structure changes, or even the database itself, which means that the first microservice won't be able to operate anymore. So, for the first database to retrieve reliable information...