After a long series of RC releases, many planned and unplanned changes, the 3.0.0 release is here. Let’s take a brief look at what’s new & changed.
It’s the Scala HTTP client that you always wanted! More elaborately, quoting the documentation:
sttp client is an open-source library which provides a clean, programmer-friendly API to describe HTTP requests and how to handle responses. Requests are sent using one of the backends, which wrap other Scala or Java HTTP client implementations. The backends can integrate with a variety of Scala stacks, providing both synchronous and asynchronous, procedural and functional interfaces.
Backend implementations include ones based on akka-http, async-http-client, http4s, OkHttp, and HTTP clients which ship with Java. They integrate with Akka, Monix, fs2, cats-effect, scalaz and ZIO. Supported Scala versions include 2.11, 2.12, 2.13 and 3. …
Let’s apply functional programming to a practical problem. Can you guess what it’s going to be?
We’ll walk step-by-step through the implementation of a simple web socket application, written using “functional” libraries. All of the code is on GitHub, if you’d like to follow having the code in your favorite IDE!
Here are the ingredients that we are going to use:
Tapir is a library for describing HTTP endpoints as immutable values, using a type-safe, composable API. Until recently, tapir’s main functionalities included the ability to describe “regular” REST-like endpoints, and interpret these descriptions as a server, client or OpenAPI documentation.
One of the most-voted feature request was web socket support, and here it is, in version 0.17! It is now possible to describe a web socket endpoint, expose it as an akka-http or http4s server, interpret as an sttp client, or generate AsyncAPI documentation!
Let’s look at the design of the feature in detail.
In tapir, we already have a couple of ways of describing the body, e.g.
streamBody[AkkaStreams]. Hence, it seems natural to add one more possibility:
webSocketBody. However, unlike the descriptions mentioned before, this one can only be used as an output of an endpoint: we cannot send a websocket to a server, but a server can respond with an established websocket when an appropriate request is received. …
Time flies, and before you know it, we have another Java release. In line with the half-year release schedule, it’s time for Java 15, which paves the way for the upcoming Java 17 LTS (a year from now).
Java has seen a steady stream of improvements, many of them influenced by other JVM languages and functional programming. This includes features such as lambdas, limited local type inference or switch expressions. Scala is an especially rich source of ideas, due to its innovative object-oriented and functional programming blend.
Let’s take a look at how the (preview or final) features available in Java 15 relate to constructs known in Scala. We’ll be focusing on language features, skipping improvements to the JVM or cleaning up of the standard library. Also note that some of the described components are already available in earlier Java versions (as previews/betas). …
Recently at our semi-regular architecture discussion group, we’ve been looking at the Auth0 service: what it is, how it works and when it might be a good idea to use it.
I’d like to focus on the last aspect, using Auth0 as a case-study for the more general problem of when to use external services in our microservices mix, and when to roll your own.
On one hand, it’s totally reasonable not to write yet another
UserService which handles user authentication and authorization. It’s been done before, and we all like to reuse code. …
For the past three months we’ve been working on an update to sttp client, which is now available as version 3.0.0-RC4.
The main theme of the release is making sttp client simpler, safer and more developer-friendly.
More than ever, sttp client is THE Scala HTTP client you always wanted :)
There’s a couple of breaking changes — take a look at the release notes for the full overview. We’ll cover some of the new features below.
sttp client introduced web socket support in version 2. While the design was comprehensive, it was unnecessarily complex (too flexible!) and irregular. …
A function or a method is pure, if:
We will be most interested in the first property, that is lack of side effects. An example of a side effect is anything that changes the “state of the world”, such as modifying a global variable or performing any kind of I/O.
Purity doesn’t have to be a binary property, though. There are some side effects that we care more about than others. For example, logging isn’t often counted as a side effect (even though it performs I/O), and hence a function which makes some computations and performs logging might be still considered pure. …
ZIO, a toolkit for type-safe, composable asynchronous and concurrent programming for Scala, has recently received a overhaul of its “environment” component: a new approach to defining the dependencies required to run a computation.
What is ZIO’s environment? A (potentially asynchronous/concurrent) process in ZIO is described using a value of type
ZIO[R, E, A]. The
E type specifies the possible errors, with which the computation might fail;
A specifies the type of the result of the computation, should it succeed; and finally
R describes the environment (or requirement) that is needed by the computation.
You can think of
ZIO[R, E, A] as a description of a function
R => E | A, that is a function which takes a value of type
R, and outputs either an error
E, or success
A. Of course, ZIO’s process descriptions are much more powerful than “normal” Scala functions. We get a number of combinators which make it feasible and safe to define computations which run asynchronously, spawn concurrent processes, signal and recover from errors, as well as define various environmental requirements. …
Rest assured, as everything this year, also Scalar and our traditional whiteboard voting “contest” (see here for 2019 results) was virtual. Despite the new setting, we managed to run the conference without technical issues — all thanks to our great team.
To conduct the voting itself, we employed a simple, though I think effective method of voting with reactions on our Scalar Slack channel. Let’s see how the results are shaping this year!
Please note: the below analysis shouldn’t be taken too seriously. The survey was done without any scientific basis, on a small, non-representative group of Scalar attendees. …
Thea, Ralph and Jessie all use tapir to describe their HTTP endpoints. They like the programmer-friendly API of the library, the way the shape of the endpoints are described, the ability to use the same description to generate a server, client or documentation, and the abstraction possibilities.
However, when it comes to defining the server logic for the endpoints — that is, what should happen when their endpoints are interepreted as a server and exposed to the outside world — they have different needs. Luckily, all three use cases are now covered by tapir!
Let’s look at them one by one. …