Learn Scala Programming

A comprehensive guide covering functional and reactive programming with Scala 2.13, Akka, and Lagom

Slava Schmidt

• Éditeur: Packt Publishing
• Année: 2018
• ISBN:
  9781788830997
• Édition: 1
• Sujet: Computer Science
• Sous-sujet: Programming in Java

A step-by-step guide in building high-performance scalable applications with the latest features of Scala.

Key Features

• Develop a strong foundation in functional programming and Scala's Standard Library (STL)
• Get a detailed coverage of Lightbend Lagom—the latest microservices framework from Lightbend
• Understand the Akka framework and learn event-based Programming with Scala

Book Description

The second version of Scala has undergone multiple changes to support features and library implementations. Scala 2.13, with its main focus on modularizing the standard library and simplifying collections, brings with it a host of updates.

Learn Scala Programming addresses both technical and architectural changes to the redesigned standard library and collections, along with covering in-depth type systems and first-level support for functions. You will discover how to leverage implicits as a primary mechanism for building type classes and look at different ways to test Scala code. You will also learn about abstract building blocks used in functional programming, giving you sufficient understanding to pick and use any existing functional programming library out there. In the concluding chapters, you will explore reactive programming by covering the Akka framework and reactive streams.

By the end of this book, you will have built microservices and learned to implement them with the Scala and Lagom framework.

What you will learn

• Acquaint yourself with the new standard library of Scala 2.13
• Get to grips with the Grok functional paradigms
• Get familiar with type system to express domain constraints
• Understand the actor model and different Akka libraries
• Grasp the concept of building microservices using Lagom framework
• Deep dive into property-based testing and its practical applications

Who this book is for

This book is for beginner to intermediate level Scala developers who would like to advance and gain knowledge of the intricacies of the Scala language, expand their functional programming tools, and explore actor-based concurrency models.

Project 1 - Building Microservices with Scala

During this book, we have gradually increased the scope of our interests. In the first part, we started with language constructs and small building blocks, such as types and functions. The second part was dedicated to the patterns of functional programming. In the third part, we looked at even bigger abstractions—the actor model and streaming.

In this section, we'll zoom out once again, this time moving from design aspects up to the architectural level. We will use what we've learned so far to build two fully-scoped projects.

Nowadays, it goes without saying that all server-side software should provide an API, specifically an HTTP RESTful API. Software providing an API is called a service and if it conforms to a set of principles, it is often called a microservice. We will follow the crowd and design our projects as microservices.

In this chapter, we'll cover two topics. First, we'll discuss the concept of microservices and describe their advantages and building principles. We'll also take a look at few technical and organizational challenges related to the microservice-based approach.

Second, we'll use the knowledge gained from the rest of the book to build two real projects from scratch. Both represent simple microservices implementing stateful REST APIs, which represent the grocery shop you're familiar with from the third section of the book. This time, we'll provide not only an opportunity to place orders, but also to create and delete articles, and to replenish items in stock and get the current status of the stock.

The first project will be built on principles covered in the second section of this book. We will build it using open source functional programming libraries—http4s and circe for the client API, and doobie for database access.

The second project will be built using reactive programming libraries and techniques covered in the third section of this book. We'll use Akka-HTTP to construct an API layer, and Akka Persistence to implement the stateful part of it.

The following topics will be covered in this chapter:

• Essentials of microservices
• Purely functional HTTP APIs with http4s
• Purely functional database access with doobie
• API integration testing with Http1Client
• Reactive HTTP API with Akka-HTTP
• Event-sourced persistent state with Akka Persistence

Technical requirements

Before we begin, make sure you have the following installed:

• SBT 1.2+
• Java 1.8+

The source code for this chapter is available on GitHub at https://github.com/PacktPublishing/Learn-Scala-Programming/tree/master/Chapter14.

Essentials of microservices

When discussing microservices, it is better to start with the question of size. Evidently, software systems are growing in size in response to increasing demands from users. The number of features, their complexity and sophistication grow and so do the lines of code in software projects. Even in well-structured living systems, the size of components and their number is getting bigger over time. Given limited human mental capabilities, the proportion of the system that is understood by a single programmer shrinks, which leads to the increased number for developers in the team. Bigger team size leads to the growth of the communication overhead and so less time for writing code, leading to the need for additional developers, which introduces a self-reinforced cycle.

The traditional monolithic way to build systems as a single project with a single deployment module or executable and a single database is therefore becoming less and less efficient, and ultimately just makes it impossible to deliver working software in a timely manner. An alternative approach is to split the monolith into separate projects, called microservices, that can be developed independently.

Microservices look like the only feasible alternative to the monolithic approach, and are therefore becoming more and more popular. But, what are they precisely? According to http://microservices.io, microservices—also known as the microservice architecture—is an architectural style that structures an application as a collection of loosely-coupled services, which implement business capabilities.

What does it mean? In essence, this is what would happen to the well-structured application if one would tear it apart and make an autonomous application from each module responsible for single business feature.

The autonomy in this definition applies on multiple levels:

• Codebase and technological stack: The code of the service should not be shared with other services.
• Deployment: The service is deployed independently of other services both in terms of time and underlying infrastructure.
• State: The service has its own persistent store and the only way for other services to access the data is by calling the owning service.
• Failure-handling: Microservices are expected to be resilient. In the case of failures of downstream services, the one in question is expected to isolate failure.

These aspects of autonomy allow us to reap a number of benefits from a microservice-based architecture:

• Continuous delivery even for very complex applications
• The complexity of each service is low because it is limited to a single business capability
• Independent deployment implies independent scalability for services with different loads
• Code-independence enables polyglot environments and makes the adoption of new technologies easier
• Teams can be scaled down in size, which reduces communication overhead and speeds up decision-making

Of course, there are downsides to this approach as well. The most obvious drawbacks are related to the fact that microservices need to communicate with each other. To name a few important difficulties:

• Unavailability of habitual transactions
• Debugging, testing, and tracing calls involving multiple microservices
• The complexity shifts from the individual service into the space between them
• Service location and protocol discovery require lots of effort

But don't be scared! In the reminder of this chapter, we'll build just a single microservice so we won't be affected by these weaknesses.

Building a microservice with http4s and doobie

Let's take a look at how a microservice with a RESTful interface will look if implemented with open source libraries based on the principles we've learned in first two sections of the book.

We will start with the discussion of the building blocks that constitute the application and how they connect together. Speaking of blocks, we'll need to briefly talk about the FS2 library, which is a foundation of other libraries we will use and thus shapes the ways we join them together. After that, we'll go over database migrations, project configurations, the imp...