Skip to main content

Services

Overview​

The following section is a high level overview of each service. A prerequisite of which is a good understanding of CQRS/ES documented in the architecture document. All API calls are available as an Insomnia file in the phoenix repo. Install Phoenix Insomnia plugin to automatically extract and set JWT tokens.

We're slowly migrating to Insomnia Designer for which there is a separate repo.

We have several microservices, these microservices are DDD aggregates, that is they are domain concepts particular to that domain and each microservice is responsible for it's domain. A simple example would be the User service is concerned with who has just registered but it knows nothing about delivering a Welcome e-mail, that is the responsibility of the Email service.

Each microservice follows a pattern and once you understand one service you will be able to navigate any service within reOS, you will see that certain features are owned entirely by one service and some by multiple services, this information is broadcast on Kafka topics and each service will listen in on certain topics as well as certain events and build a representation of the world as it sees it.

Before diving into each service here is a list of additional patterns and concepts we leverage in order to simplify services, it used by the majority of reOS services with the exceptions being Banking and Easypay.

  • Entity: The entity is responsible for behaviour. Commands are requested against an entity and events are persisted. Events build up the state of the entity.
  • Schedulers: Are responsible for consuming workload on a specific queue and actioning them.
  • Listeners: Are responsible for listening in on specific topics and either inserting data into the database or issuing commands on the Entity.
  • Readside Processors: this is the Q in CQRS. The readside processor will consume all internal events on the service and build up readside information in a database.
  • Service Implementations: Implementation of API call and also responsible for what events are broadcast to the outside
  • Connectors: This is basic ORM functionality to Select/Insert/Update any detail in the database
  • Graphs: Used when we need merge in multiple input streams into 1 output stream

Most services will follow a workflow outlined in high level below. A command is executed against an entity, that command can come from either a scheduler, listener or UI via an API call. Side effects are always handled before the command is handled, never in the event since events can be replayed at any time.

sequenceDiagram participant I as UI participant L as Listener/Scheduler participant E as Entity participant R as Readside participant C as Connector participant T as Topic note over I,E: Commands either come in from a Listener or the UI I->>E: Command comes in and emits Event/s L->>E: Command comes in and emits Event/s note over E,R: Readside processes events E->>R: Process Event note over L,C: Readsides, Listeners and Schedulers predominantly upsert into the database. L->>C: Insert into Database R->>C: Insert into Database note over E,T: Topic broadcasts event externally E->>T: Broadcast Event

Deployment​

The Phoenix stack is hosted on GCE and provisioned using Skaffold. Install gcloud Docker auth by running: gcloud auth configure-docker Git tag the current version before running the commands below. e.g. git tg 0.55 git push --tags Each service has a Skaffold profile which you provide after the -p option

skaffold run -p agency-impl

Testing​

The following commands must be executed in the sbt prompt:

  • If you're working on a single service you can limit tests to that project by first running sbt:phoenix> project agency-impl
  • Check for syntax errors and warnings using: sbt:phoenix> scalestyle
  • Run all unit tests using: sbt:phoenix> test
  • Run test for a specific file: sbt:phoenix> testOnly *FileNameSpec

Cassandra Access​

With Gcloud access you can connect to Cassandra via 

kubectl port-forward -n cassandra cassandra-cassandra-0 9042:9042
cqlsh

Kafka Access​

To read the last messages from wallet topic

kafkacat -C -b _inside._tcp.bootstrap.kafka.svc.cluster.local -o beginning -t wallet-WalletEvent