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)

Upgrading from monolith to microservices

Upgrading from a monolithic architecture to microservices is essentially to continually replace parts of the old application with new microservices. While this section talks about upgrading a monolith, it can also be taken as a planning step for an entirely new application. You will see how to conceptually upgrade a monolith to microservices; there is no code mentioned at this point because you will see this in much more depth later in this book. You should, however, see the concept underneath after reading this section.

They may not fit your specific application but are generally widespread among monolithic applications. This approach is referred to as Model-View-Controller (MVC). The components of this approach are defined as follows:

  • A Model represents an instance of a data type, for example, User, Product, and Order.
  • A Controller represents a logic executor that typically takes input in and returns the output in the form of serialized models, for example, UserController, OrderController, and ProductController.
  • A View represents an output from the controllers, often either HTML, XML, or JSON.

Many current web technologies are built on top of the MVC concept, such as the following:

  • PHP (Laravel, Symfony, and Zend Framework)
  • Ruby (Ruby on Rails)
  • Java (Spring MVC and Vaadin)
  • Go (Revel and Iris)
  • Python (Django)
  • Swift (Vapor, Kitura, and Perfect)
Note: Most of the frameworks mentioned here also allow you to abandon the MVC pattern.

The goal is now to convert an MVC application into a microservice application.

Let's go through the following sections:

  • Decoupling business logic
  • Reorganizing your monolith
  • Integrating microservices

We start by decoupling business logic.

Decoupling business logic

We start by separating business logic. What is your application doing? Answer this question in terms of which aspects are involved. For an online shop application, the answer would look like the following.

What does the application do?

The application does the following things:

  • Takes orders
  • Processes orders
  • Returns products
  • Creates products
  • Updates products
  • Deletes products
  • Accepts credit card for an order
  • Accepts PayPal for an order

You can be as detailed as you like with this list; it is not a final list of microservices. You will then use this list to identify common components.

What are the common components?

By looking at the preceding list, we can easily tell that we are dealing with the following components:

  • Orders
  • Products
  • Payments

This list is now a lot closer to what we want the microservices to define for us. You may still decide to combine one or two entries in this list but you can now see which microservices make the most sense for you.

You want to reorganize your monolith in a way that makes it easy to remove parts of its functionality to be replaced with microservices.

Reorganizing your monolith

Chances are you will not be able (or want to) update the entire application in one big swap. Depending on the size of the project, it can take weeks, months, and even years for this process to be completed. If you plan on swapping your entire monolith with microservices in one go, you can skip this step. Companies such as Facebook have done this over many years while keeping parts of their old stack. However, even when you intend to keep some of your old monoliths, it still needs to be adjusted to work with microservices. The two main areas to adjust are authentication and business logic.

Using authentication

Microservices typically do not use a shared session model for authentication, which is a prevalent model for monoliths. Whichever model you are currently using, your microservices, as well as your monolith, need to interact with it. A very common and often used standard is called JSON Web Token (JWT); it allows microservices to authenticate requests.

You will need to modify your monolith to be able to communicate with microservices. There are more ways than just JWTs but because of their benefits and their popularity, I would recommend you use them. In essence, the following are the characteristics of JWTs:

  • Self-contained (no central verification)
  • Broadly adopted (every framework has a library for them)
  • Easy to debug and troubleshoot
  • A concept that allows easy security
JWTs themselves are neither safe nor the best choice. They do, however, provide a good starting point and are often good enough. If you are developing for a high-security application like in banking, you should not use JWTs.

You could also use a "shared session" token instead of JWTs; the principle remains the same: your monolith, as well as your microservices, need to be able to verify the requests.

Adjusting business logic

Once your monolith can communicate with microservices, you can start to separate the business logic. A well-organized monolith application may have done this already. For example, if you are using controllers, you want to end up with the following for our previous example:

OrdersController
ProductsController
PaymentsController

The reason you want to end up with a structure that separates the business logic is that you can then replace each individual component piece by piece.

So, adjust your monolith to communicate with your microservices and split it up to be easily replaced by them.

Integrating microservices

Now you are at a place where you can introduce your microservices. Each microservice should represent a piece of the business logic and should remain as independent as possible. Given that you have organized your controllers in a way outlined in the previous step, you will now be able to create the following microservices:

Orders Manager 
Products Manager
Payment Manager

You can replace the services as you see fit and as your speed allows. Having your monolith optimized in a way that allows you to replace controllers by services will make this a painless process.

In this section, we learned how to approach integrating a monolith into microservices by decoupling the business logic, reorganizing the monolith, and then lastly, integrating microservices. Let's summarize this chapter!