36.
Microservices, Part 1
Written by Tim Condon
Heads up... You’re accessing parts of this content for free, with some sections shown as text.
Heads up... You’re accessing parts of this content for free, with some sections shown as text.
Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.
Unlock now
In previous chapters, you’ve built a single Vapor application to run your server code. For large applications, the single monolith becomes difficult to maintain and scale. In this chapter, you’ll learn how to leverage microservices to split up your code into different applications. You’ll learn the benefits and the downsides of microservices and how to interact with them. Finally, you’ll learn how authentication and relationships work in a microservices architecture.
Microservices
Microservices are a design pattern that’s become popular in recent years. The aim of microservices is to provide small, independent modules that interact with one another. This is different to a large monolithic application. Such an approach makes the individual services easier to develop and test as they are smaller. Because they’re independent, you can develop them individually. This removes the need to use and build all the dependencies for the entire application.
Microservices also allow you to scale your application better. In a monolithic application, you must scale the entire application when under heavy load. This includes parts of the application that receive low traffic. In microservices, you scale only the services that are busy.
Finally, microservices make building and deploying your applications easier. Deploying very large applications is complex and prone to errors. In large applications, you must coordinate with every development team to ensure the application is ready to deploy. Breaking a monolithic application up into smaller services makes deploying each service easier.
Each microservice should be a fully contained application. Each service has its own database, its own cache and, if necessary, its own front end. The only shared part should be the public API to allow other services to interact with that microservice. Typically, they provide an HTTP REST API, although you can use other techniques such as protobuf or remote procedural calls (RPC). Since each microservice interacts with other services only via a public API, each can use different technology stacks. For instance, you could use PostgreSQL for one service that required it, but use MySQL for the main user service. You can even mix languages. This allows different teams to use the languages they prefer.
Swift is an excellent choice for microservices. Swift applications have low memory footprints and can handle large numbers of connections. This allows Swift microservices to fit easily into existing applications without the need for lots of resources.
The TIL microservices
In the first few sections of this book, you developed a single TIL application. You could have used a microservices architecture instead. For instance, you could have one service that deals with users, another that deals with categories and another for acronyms. Throughout this chapter, you’ll start to see how to do this.
The user microservice
Navigate to the TILAppUsers directory in Terminal. Enter the following the start the database:
docker run --name postgres -e POSTGRES_DB=vapor_database \
-e POSTGRES_USER=vapor_username \
-e POSTGRES_PASSWORD=vapor_password \
-p 5432:5432 -d postgres
open Package.swift
The acronym microservice
Keep the user service running and navigate to the TILAppAcronyms directory in Terminal. Enter the following the start the database:
docker run --name mysql -e MYSQL_USER=vapor_username \
-e MYSQL_PASSWORD=vapor_password \
-e MYSQL_DATABASE=vapor_database \
-e MYSQL_RANDOM_ROOT_PASSWORD=yes \
-p 3306:3306 -d mysql
open Package.swift
Dealing with relationships
At this point, you can create both users and acronyms in their respective microservices. However, dealing with relationships between different services is more complicated. In Section 1 of this book, you learned how to use Fluent to enable you to query for different relationships between models. With microservices, since the models are in different databases, you must do this manually.
Getting a user’s acronyms
In the TILAppAcronyms Xcode project, open AcronymsController.swift. Below updateHandler(_:), add a new route handler to get the acronyms for a particular user:
func getUsersAcronyms(_ req: Request)
throws -> EventLoopFuture<[Acronym]> {
// 1
let userID =
try req.parameters.require("userID", as: UUID.self)
// 2
return Acronym.query(on: req.db)
.filter(\.$userID == userID)
.all()
}
routes.get("user", ":userID", use: getUsersAcronyms)
Getting an acronym’s user
You can already get an acronym’s user with the current projects. You make a request to get the acronym, extract the user’s ID from it, then make a request to get the user from the user service. Chapter 37, “Microservices, Part 2” discusses how to simplify this for clients.
Authentication in Microservices
Currently a user can create, edit and delete acronyms with no authentication. Like the TIL app, you should add authentication to microservices as necessary. For this chapter, you’ll add authentication to the TILAppAcronyms microservice. However, you’ll delegate this authentication to the TILAppUsers microservice.
Logging in
Open the TILAppUsers project in Xcode. The starter project already contains a Token type and an empty AuthContoller. You could store the tokens in the same database as the user. Since every validation request requires a lookup and you have multiple services, you want this to be as quick as possible. One solution is to store them in memory. However, if you want to scale your microservice, this doesn’t work. You need to use something like Redis. Redis is a fast, key-value database, which is ideal for storing session tokens. You can share the database across different servers which allows you to scale without any performance penalties.
docker run --name redis -p 6379:6379 -d redis
import Redis
app.migrations.add(CreateUser())
// 1
let redisHostname: String
if let redisEnvironmentHostname =
Environment.get("REDIS_HOSTNAME") {
redisHostname = redisEnvironmentHostname
} else {
redisHostname = "localhost"
}
// 2
app.redis.configuration =
try RedisConfiguration(hostname: redisHostname)
func loginHandler(_ req: Request)
throws -> EventLoopFuture<Token> {
// 1
let user = try req.auth.require(User.self)
// 2
let token = try Token.generate(for: user)
// 3
return req.redis
.set(RedisKey(token.tokenString), toJSON: token)
.transform(to: token)
}
// 1
let authGroup = routes.grouped("auth")
// 2
let basicMiddleware = User.authenticator()
// 3
let basicAuthGroup = authGroup.grouped(basicMiddleware)
// 4
basicAuthGroup.post("login", use: loginHandler)
Authenticating tokens
Now that users can log in and get a token, you need a way for other microservices to validate that token and retrieve the user information associated with it.
struct AuthenticateData: Content {
let token: String
}
func authenticate(_ req: Request)
throws -> EventLoopFuture<User.Public> {
// 1
let data = try req.content.decode(AuthenticateData.self)
// 2
return req.redis
.get(RedisKey(data.token), asJSON: Token.self)
.flatMap { token in
// 3
guard let token = token else {
return req.eventLoop.future(error: Abort(.unauthorized))
}
// 4
return User.query(on: req.db)
.filter(\.$id == token.userID)
.first()
.unwrap(or: Abort(.internalServerError))
.convertToPublic()
}
}
authGroup.post("authenticate", use: authenticate)
Authenticating with other microservices
Go back to the TILAppAcronyms project in Xcode and stop the app. Open User.swift and add the following at the bottom of the file:
extension User: Authenticatable {}
import Vapor
struct AuthenticateData: Content {
let token: String
}
struct UserAuthMiddleware: Middleware {
// 1
func respond(to request: Request, chainingTo next: Responder)
-> EventLoopFuture<Response> {
// 2
guard let token =
request.headers.bearerAuthorization else {
return request.eventLoop
.future(error: Abort(.unauthorized))
}
// 3
return request.client.post(
"http://localhost:8081/auth/authenticate",
beforeSend: { authRequest in
// 4
try authRequest.content
.encode(AuthenticateData(token: token.token))
// 5
}).flatMapThrowing { response in
// 6
guard response.status == .ok else {
if response.status == .unauthorized {
throw Abort(.unauthorized)
} else {
throw Abort(.internalServerError)
}
}
// 7
let user = try response.content.decode(User.self)
// 8
request.auth.login(user)
// 9
}.flatMap {
// 10
return next.respond(to: request)
}
}
}
let authGroup = routes.grouped(UserAuthMiddleware())
authGroup.post(use: createHandler)
authGroup.delete(":acronymID", use: deleteHandler)
authGroup.put(":acronymID", use: updateHandler)
routes.post(use: createHandler)
routes.delete(":acronymID", use: deleteHandler)
routes.put(":acronymID", use: updateHandler)
struct AcronymData: Content {
let short: String
let long: String
}
// 1
let data = try req.content.decode(AcronymData.self)
// 2
let user = try req.auth.require(User.self)
// 3
let acronym = Acronym(
short: data.short,
long: data.long,
userID: user.id)
return acronym.save(on: req.db).map { acronym }
let updateData = try req.content.decode(AcronymData.self)
let user = try req.auth.require(User.self)
acronym.userID = user.id
Where to go from here?
In this chapter, you learned how to split the TIL app into different microservices for users and acronyms. You’ve seen how to handle authentication and relationships across different services.