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 why not to choose microservices

You have seen several reasons to choose microservices. Now, let's look at reasons why not to choose microservices. As with everything, the strengths of microservices are also their weakness. While this book is about writing microservices, you should not think that microservices are the answer to every problem. There are many examples of why microservices are actually the wrong choice for certain problems. Here is a list of some of the reasons why not to choose microservices.

Initially more work

The first and most obvious reason why you would not want to choose microservices is that it is usually a bit more work initially. To set up the entire system and connect the services and get them all up and running the way you need to often requires more work than with a monolithic application.

It starts by setting everything up and building a working environment. A monolithic application will require you to run the application only. So, once you start your main application, you are good to go.

A microservices application, however, requires a setup in which multiple applications are running at the same time. Alternatively, you could design your application to receive test data from static files; this, however, does not replace testing with the actual services. You can archive such a setup easily in a deployment situation; cloud providers are doing an excellent job in helping us here. However, when you start developing, it can be a good amount of work to set everything up. In the next chapter, you will set up your own workspace.

Additionally, microservices demand planning. You cannot perform some changes as quickly as you would in a monolithic application. If you are only building a simple proof-of-concept for your backend, you might be better off starting as a monolith. If you need something implemented that is critical in timing, microservices might not be your best option.

So, a good thing to keep in mind when working with microservices is that microservices demand some planning and often take longer to start.

Increased complexity

When developing monolithic applications, you usually have everything in the same code base. As long as a project is small, the lack of complexity makes it easier for you to maintain it. Additional features and changes can be implemented with the same stack, language, and frameworks you have been using so far.

Microservices, on the other hand, can be a bit more complex (or messy even). Adding a new feature is not always trivial and may require changes in numerous services. The services themselves may also have different stacks. You may have a legacy service running PHP combined with a Swift Vapor service for another part of the app. Adding a feature requires you to work in PHP as well as Swift.

If you know your exact scope for a project and don't expect any changes, there is no reason not to implement it like a monolithic application.

Microservices can increase the complexity of a project, compared to traditional technologies such as PHP, which you should keep in mind. The same can be said about most microservice technologies though, regardless of programming language. Let's take a look at troubleshooting and debugging now.

Debugging and troubleshooting

Debugging and troubleshooting is yet another issue you will need to consider. It can be quicker and easier to debug one application as opposed to two or more microservices. Debugging goes hand in hand with complexity; bugs will not be found as quickly as they can be in a monolithic application. As a matter of fact, this topic is important enough for this book to have an entire chapter on it.

If you are dealing with an application that is limited in scope and functionality is not expected to grow, a monolithic approach might be better than a microservice approach. That said, I have personally seen many projects start as "small and manageable" pretty suitable for monolithic applications. But then they grow, and the benefits quickly turn into serious problems. If you think all of your applications should be suitable for growth, take a microservice approach.

It can take more time to find bugs. Because services are often somehow connected, it can be pretty hard to boil a symptom down to a bug. I have seen a small symptom come out of many unrelated errors.

To conclude, debugging a microservice backend is more complex and time-consuming than for monolithic applications, however, there are also great benefits with using them. This is why we will look at a list of companies that are using microservices and have switched away from monoliths.