As a programmer we don’t really like to deal with errors. We like to focus on the happy path – the one that provides value – and deal with the errors later because … well, we have to do it!
However dealing with failures is crucial if we don’t want our program to stop on the first error it encounters.
But still we don’t want to mix the “clean” code of the happy path with the “dirty” error handling code. And in fact this is what exceptions were suppose to bring: A clean happy path in a
try statement and the error handling code in a
catch statement. You know everything clean and separated.
In Scala we have a rich type-system which gives us more options to handle errors. But before we start let’s be clear by what we mean by errors. Continue reading “Dealing with errors”
We all know we should write tests to make sure our system behaves as it is supposed to.
Surely tests are necessary to ensure correctness of our programs but they only depend on what the programmer is willing to test (or can think of testing).
What I mean is that there will always be gaps in the test coverage, like uncovered corner cases or improbable combinations of events, …
In Scala we have a powerful type system that we can use to help us avoid some mistakes.
Why would you bother writing a test to make sure a function handle some corner cases correctly when you can use the type system to make sure such cases won’t ever happen. Continue reading “Leveraging the type system to avoid mistakes”
Type refinement is all about making the types more precise. But why would do that? Because using the correct types makes your program safer as you reduce the possibility to introduce bugs.
First let’s think about types. For instance
String is a type we use all the time. A variable of type
String can have many different values (in theory an infinity of values) but it’s quite unlikely that all these values make sense in our application. Continue reading “Refined types, what are they good for?”
Back from holidays let’s continue with some of my favourite topics: AkkaStreams and gRPC.
We’ve already seen how can take advantage of the ScalaPB code generation tool to generate new interfaces (GRPCMonix) on top of the grpc-java implementation or to create new tools to integrate gRPC with other services (GRPCGateway).
Similarly to GRPCMonix which provides a Monix interface – Task, Observable – on top of gRPC, it’s possible to develop an AkkaStream interface on top of gRPC. Continue reading “Akka stream interface for gRPC”
In this previous post we’ve seen that before using Scala’s Future it might be worth taking some time to think of the use cases (especially error cases), the execution model we need, … as it might be more advantageous to choose a solution like Monix’s
Task (although not available in standard library) to gain finer control over the execution. However some might not be able to make a decision at this stage and like to keep their options open. Let’s see how we can revisit our product repository in such way that we don’t have to make a decision too early.
Continue reading “Introduction to Tagless final”
In this previous post we saw how Scala Futures work and why they need an implicit ExecutionContext to run their computation. While there is some trick to pass the ExecutionContext, it’s usually cumbersome and clutter the code.
So the question really is: Do you need an ExecutionContext everywhere? Well, you do as long as you use Futures, but is there any alternatives? Continue reading “Scala Futures vs Monix Tasks”
Viktor Klang recently published a set of useful tips on Scala Futures. While being widespread and heavily used, people (especially newcomers) are still experiencing problems working with Scala Futures.
In my opinion many of the problems come from a misunderstanding or misconception on how Futures work. (e.g. the strict nature of Futures and the way they interact with Execution Contexts to name a few).
That’s enough of an excuse to dive into the Scala
ExecutionContext implementation. Continue reading “Understanding Scala Futures and Execution Contexts”
As many might think, gRPC doesn’t stand for “google Remote Procedure Call” but is a recursive acronym meaning “gRPC Remote Procedure Call”. I don’t know if you buy it but the truth is that is was originally developed by Google and then open-sourced.
If you’ve been in the IT for a while RPC doesn’t necessarily bring back happy memories. On the JVM it all started with RMI in the 90s. RMI was inspired by CORBA and suffered from a lack of interoperability as both the client and the server had to be implemented in Java. RMI was also particularly slow as Java serialisation is not a very efficient protocol.
Later in the 2000s came XML based RPC with XML-RPC and especially SOAP. Both of these formats address the interoperability as it no longer matters how the client/server are implemented. They only need to speak XML. However XML is still not an efficient protocol and communications remain slow.
SOAP provides an interesting definition language (WSDL – Web Service Definition Language) that can be used to generate service implementations.
gRPC addresses all these drawbacks. By default, it uses protobuf (Protocol buffers) for the service definitions and as its serialisation mechanism, which allows it to interoperate with many different languages while providing an efficient serialisation protocol. gRPC also takes advantage of HTTP/2 to add streaming capabilities.
Unfortunately Scala is not in the list! … but we have scalaPB (and sbt-protoc) to save the day! Continue reading “gRPC in Scala”
Today’s focus is on scalameta. In this introduction post we’re going to see how to create a macro annotation to generate protobuf formats for case classes.
The idea is to be able to serialise any case classes to protobuf just by adding a
@PBSerializable annotation to the case class declaration.
Then behind the scene the macro will generate implicit formats in the companion object. These implicit formats can then be used to serialise the case class to/from protobuf binary format.
This is quite similar to Json formats of play-json.
In this post we’re going to cover the main principles of scalameta and how to apply them to create our own macros. Continue reading “Generating protobuf formats with scala.meta macros”
Akka actors fits nicely with DDD (Domain Driven Design) to design an application. E.g. It’s quite natural to model entities as individual actors who can be persisted, …
One of the key aspect in DDD is the notion of bounded context. A bounded context is simply a “self-content” component. It can interact with other components but it is coherent on its own. Each bounded context has its own domain model which belongs only to itself and should not leaked or be influenced by other bounded context.
Anti-corruption layers (aka translation layers or adapter layers) are used to enforce this principle. Basically their role is to translate the core domain objects into/from another domain that is used for communication or persistence.
In this blog post we’re going to try to follow the DDD principles to build a small (contrived) application using Akka and try to figure out the best way to build efficient anticorruption layers. Continue reading “Building anti-corruption layers with Akka”