Dealing with errors

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”

Leveraging the type system to avoid mistakes

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”

Load-Balancing strategies

A load-balancing strategy is a strategy allowing to spread the load (e.g. HTTP requests) over a fleet of instances providing some functionality. If you’re like me you probably think of a sort of load-balancer (e.g. Nginx, AWS ELB, …) in front of several nodes (e.g. EC2 instances, docker containers, …). This is, indeed, a very common pattern but there are other alternatives with different pros and cons. Continue reading “Load-Balancing strategies”

Back-pressure in Grpc-akkastream

Grpc-akkastream, the akka-stream implementation built on top of GRPC looks good on the surface but if you look under the hood there is one problem: it doesn’t provide any support for back-pressure.

Akka-streams (as any reactive-stream implementation) provides a way for back-pressure and GRPC (at least the Java version) also has an API that support back-pressure. Let’s see how we can wire everything together and provide a truly reactive akka-stream implementation for GRPC! Continue reading “Back-pressure in Grpc-akkastream”

Making sense of SBT

SBT is probably the most popular (as in “most used”) build tool for Scala yet people (including me) experienced a hard time figuring out why it doesn’t perform as they expect.

Originally known as the “Simple Build Tool” it has later been renamed to “Scala Build Tool” (maybe to acknowledge the fact that it was not so simple?)

Part of the reason is that it’s not really intuitive. True, there is documentation available but how many developers don’t bother reading it (at least until the effort overcomes the pain of using SBT) plus it’s much easier to copy/paste code snippets without completely understanding what they do.

That being said SBT is not magic, so let’s try to understand how it works so that next time we’re not reduced to copy/paste cryptic code snippets until it works. Continue reading “Making sense of SBT”

Refined types, what are they good for?

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?”

Querying DynamoDB from Scala

As we’ve seen in this comparison with Apache Cassandra, DynamoDB may be a valuable choice for storing data. It’s fully maintained by AWS you just have to configure your instance and you can start using it straight away.

Being one of the Amazon web services DynamoDB offers a JSON/HTTP interface and Amazon provides a set of client for a variety of language. Unfortunately Scala is not one of them but there is a Java client available. Sadly it suffers from big performance issues due to poor design choices.

So what are the alternatives? This is what we’re going to see in this post: How can we get the most out of the official driver and are there better alternatives both in terms of performance or integration with the Scala ecosystem. Continue reading “Querying DynamoDB from Scala”

Amazon DynamoDB vs Apache Cassandra

Cassandra and DynamoDB both origin from the same paper: Dynamo: Amazon’s Highly Available Key-value store. (By the way – it has been a very influential paper and set the foundations for several NoSQL databases).

Of course it means that DynamoDB and Cassandra have a lot in common! (They have the same DNA). However both AWS DynamoDB and Apache Cassandra have evolved quite a lot since this paper was written back in 2007 and there are now some key differences to be aware of when choosing between the two.

This post aims at comparing these 2 distributed databases so that you can choose the one that best matches your requirements. Continue reading “Amazon DynamoDB vs Apache Cassandra”

Akka stream interface for gRPC

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”

Introduction to Tagless final

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”