Agenda

• Motivation
• Demo
• Design

Monolith

Monolith: Pros & Cons

Pros

• Simplicity

Cons

• Rigidity
• Scalability

Distributed

Distributed: Pros

• Flexibility
  • Independent teams, tech stacks, deployments
• Scalability
  • Scale out just the critical nodes

Distributed: Cons

• Complexity
  • Communication across program boundaries
  • Dependencies between nodes

Crossing Program Boundaries

Java RMI

val b: B = service.compute(a)

• Remote invocation as an A => B function!
• Compile-time errors

Java RMI: Cons

• Blocking, inefficient
• No streaming
• Network failures surface as runtime exceptions

Illusion of Transparency

“Distribution transparency is impossible to achieve in practice. Precisely because of that impossibility, it is dangerous to provide the illusion of transparency”. Rachid Guerraoui et al., 1999

Akka

import akka.actor.typed.scaladsl.AskPattern._

val eventualB: Future[B] = serviceRef.ask(ref => Compute(a, ref))

• Non-blocking, efficient
• Streaming (with Akka Streams)
• Same guarantees for local and remote invocations
  • Location transparency is not a lie!

Akka: Cons

• Remote invocation as an (A, ActorRef[B]) => Unit function
  • Tedious plumbing
• All the nodes have to use the Akka communication protocol
  • Not appropriate to expose a public API

HTTP Services

val eventualB: Future[B] =
  httpClient.post("http://service/compute", a.toJson)
    .filter(_.status == 200)
    .flatMap(_.entity.asJson.to[B])

• Clients and servers can have their own tech stack

HTTP Services: Cons

• Building HTTP requests is tedious
• Documenting an HTTP API is tedious
• Untyped
  • No compile-time guarantee that requests are well-formed
  • No IDE assistance

WSDL

val eventualB: Future[B] = service.compute(a)

(assuming that you have generated service implementation class with a tool like scalaxb)

• Brings back type-safety
• Makes invocation simple

WSDL: Cons

• No streaming
• XML service definitions are tedious to read or write
• Relies on code generation
  • Requires extra step in build
  • Generated code sometimes does not compile
  • Generated code may impose constraints on the way it can be used
  • Limited expressivity of the service definition language

gRPC

• Service definitions written in a human-readable format
• Better performance (HTTP2, binary serialization)
• Streaming
• But still, relies on code generation!

Meta-Programming

Idea: mitigate code generation issues by synthesizing code with macros instead

trait Service {
  def compute(a: A): B
}

val service = synthesized.Client[Service]
val eventualB: Future[B] = service.compute(a)

Meta-Programming: Cons

• Poor tooling support
• Second-class citizen

Just a Boring Library

First-Class Scala Values

• No code generation
• No new language
• Seamless integration in your project

No Macros

• No surprising semantics
• IDE friendly

Modularity

Modularity²

Extensibility

Thanks for your attention

Any questions?