Reference application developed in the Functional event-driven architecture: Powered by Scala 3 book.
The web application allows users to subscribe/unsubscribe to/from symbol alerts such as EURUSD
, which are emitted in real-time via Web Sockets.
It is written in Elm and can be built as follows.
$ cd web-app && nix-build
$ xdg-open result/index.html # or specify browser
There's also a shell.nix
handy for local development.
$ cd web-app && nix-shell
$ elm make src/Main.elm --output=Main.js
$ xdg-open index.html # or specify browser
If Nix is not your jam, you can install Elm by following the official instructions and then compile as usual.
$ cd web-app
$ elm make src/Main.elm --output=Main.js
$ xdg-open index.html # or specify browser
Here's an overview of all the components of the system.
- Dotted lines: Pulsar messages such as commands and events.
- Bold lines: read and writes from / to external component such as Redis.
The back-end application is structured as a mono-repo, and it requires both Apache Pulsar and Redis up and running. To make things easier, you can use the provided docker-compose.yml
file.
Note: The docker-compose
file depends on declared services to be published on the local docker server. All docker builds are handled within the build.sbt
using sbt-native-packager
. To build all of the service images, run sbt docker:publishLocal
.
$ docker-compose up -d pulsar redis
To run the Kafka Demo (see more below), only Zookeeper and Kafka are needed.
$ docker-compose -f kafka.yml up
If we don't specify any arguments, then all the containers will be started, including all our services (except feed
), Prometheus, Grafana, and Pulsar Manager.
$ docker-compose up
Creating network "trading_app" with the default driver
Creating trading_pulsar_1 ... done
Creating trading_redis_1 ... done
Creating trading_ws-server_1 ... done
Creating trading_pulsar-manager_1 ... done
Creating trading_alerts_1 ... done
Creating trading_processor_1 ... done
Creating trading_snapshots_1 ... done
Creating trading_forecasts_1 ... done
Creating trading_tracing_1 ... done
Creating trading_prometheus_1 ... done
Creating trading_grafana_1 ... done
It is recommended to run the feed
service directly from sbt
whenever necessary, which publishes random data to the topics where other services are consuming messages from.
The back-end application consists of 9 modules, from which 5 are deployable applications, and 3 are just shared modules. There's also a demo module and a web application.
modules
├── alerts
├── core
├── domain
├── feed
├── forecasts
├── it
├── lib
├── processor
├── snapshots
├── tracing
├── ws-server
└── x-demo
Capability traits such as Logger
, Time
, GenUUID
, and potential library abstractions such as Consumer
and Producer
, which abstract over different implementations such as Kafka and Pulsar.
Commands, events, state, and all business-related data modeling.
Core functionality that needs to be shared across different modules such as snapshots, AppTopic
, and TradeEngine
.
Generates random TradeCommand
s and ForecastCommand
s followed by publishing them to the corresponding topics. In the absence of real input data, this random feed puts the entire system to work.
Registers new authors and forecasts, while calculating the author's reputation.
The brain of the trading application. It consumes TradeCommand
s, processes them to generate a TradeState
and emitting TradeEvent
s via the trading-events
topic.
It consumes TradeEvent
s and recreates the TradeState
that is persisted as a snapshot, running as a single instance in fail-over mode.
The alerts engine consumes TradeEvent
s and emits Alert
messages such as Buy
, StrongBuy
or Sell
via the trading-alerts
topic, according to the configured parameters.
It consumes Alert
messages and sends them over Web Sockets whenever there's an active subscription for the alert.
A decentralized application that hooks up on multiple topics and creates traces via the Open Tracing protocol, using the Natchez library and Honeycomb.
All unit tests can be executed via sbt test
. There's also a small suite of integration tests that can be executed via sbt it/test
(it requires Redis to be up).
It contains all the standalone examples shown in the book. It also showcases both KafkaDemo
and MemDemo
programs that use the same Consumer
and Producer
abstractions defined in the lib
module.
JVM stats are provided for every service via Prometheus and Grafana.