Event-sourced architecture, travelling Java -> Scala (Part 3: Continuations)

No threads - the Akka's way

Erlang OTP as any great solution can't hold 'monopoly' position forever. Akka has taken the best from the Erlang OTP and other frameworks or languages. One of the most important questions for the threadless design - can we avoid blocking of the native threads under JVM? The answer is - yes we can. Let's look closer to TypeSafe platform. Akka come with two 'colours' for Actors:

• Thread based - self describing name: Actors are binded to Threads, via Threads execution pool, sometimes with pool variations, but the main idea is always the same - Actors is wrapper around the native thread - it helps to manage the locking, synchronisation and etc, but the engine is based on thread itself.
• Event based - threadless implementation, coming to bring behaviour from Erlang practices.

Event-sourced architecture, travelling Java -> Scala (Part 2: Threads, connections)

Http sever, threads.

When we are talking about scalability we should always start from IO. It is well reworked during last years, let's look into the history.

HTTP 1.0

Nobody remembers how it was, just the fact that on each call server to client connection was opened and closed. Some overhead of course.

HTTP 1.1

Persistente connections helped to solve the issue with opening closing the TCP connection for each request, now connection can be reused for several request - response sessions.

From the session protocol, until the coming of Web Sockets we weren't expect any possible improvements. Some rework was done on server level:

Event-sourced architecture, travelling Java -> Scala (Part 1: Into)

Intro

I ve been interested with event-sourced approach during previous 3 years. Actually I had the feeling that regular CRUD application isn't the best one candidate to redesign into event-sourced architecture. Previous week my friend shared with me the source code of interesting commercial project - engine for online game. Actually it follows the best practices and even implements the dreams of modern Java coders. Of course there is some legacy code - but project management pushing the team to follow processes based on BDD and TDD, that keeps technical debt in controlled borders. Code is in good shape (well refactored), covered with specs and tests. From the start project had a Java code only - but for now it's migrated mostly to Scala. Of course language is just one of the tools and it's more important to know the whole technology stack. It is: Spray -> Akka -> JPA -> MySQL. In the current moment team is actively looking for the ways of performance improvement. When I reviewed the business of the application - it is the best one candidate for event-sourced approach. Keep the whole instance world as immutable state in the memory - and track all actions as the log.

Dynamic scope pattern

It's became industry standart for the most languages how the scope of variable is determined. Passing as a parameter, if there are many parameters: creation of value classes, if there are many clients (readers) - we can always create global field.

Visibility of scope is becoming predictable by looking into nesting braces in the source code. That makes it easy to read and understand the code, but in some cases isn't enough for automations and doesn't abstract from non functional TODOs like - automated caching or transaction management, while context for the same should be passed across the whole flow as explicite parameter. 

Loan pattern in Scala

Loan pattern is really coming from loaning some context to some block, which doesn't care about lifecycle of the context, just using it (as you can find isn't not real world loan, but it work in magic Scala's borders;-)).
A lot of boilerplate in Java can't be avoided when we have to work with connection, resources, threads and etc.

for example: