Entity Component Types in Kalix

Reading Time: 3 minutes

First, Let’s get to know what Kalix is then we will see what an entity Is and what Its type is.

Notes: All the codes in the blog are written in Scala.

kalix-social-master-kalix-logo-1024-576

Kalix is a Platform-as-a-Service (PaaS) that combines an API-first, database-less programming model with a serverless runtime. Now what It means is that Kalix is a service that makes It easy for developers to develop and deploy an application without needing experience in OPs. Kalix makes a unifying application layer that pulls together the necessary pieces. These include databases, message brokers, caches, service meshes, API gateways, blob storages, CDN networks, CI/CD products, etc and abstracts away the implementation details of the underlying architecture. Kalix tells you to focus on creating data objects that make sense for their service without needing to know how that data needs to be saved in storage.

What is an Entity Component?

An entity is a service component which is one of the fundamental software building blocks of kalix where an entity is conceptually equivalent to a class, or a type of state which will have multiple instances of itself, and each of those instances will have a unique ID and be able to handle commands. An entity has an API that looks like It has a Code and state.

Now Let’s see what are Its types:

Types of Entity Components in Kalix

  • Key-Value Entity
  • Event-Sourced Entity
  • Replicated Entity

These entity components each have their own method to implement. So let’s see and understand them.

Key-Value Entity

In Key-Value Entity the main Idea is that the state changes that occur with each command persist in some form of Persistent Data Store but It stores only the current changes. and to achieve this Kalix needs to serialize that data to send it to the underlying data store, this is done with Protocol Buffers using protobuf types. Let’s see a Key-Value Entity Implementation behavior to understand It better.

class Counter(context: ValueEntityContext) extends AbstractCounter {

  override def emptyState: CounterState = CounterState()

Here in the code generated by the protobuf files, the class counter extends the generated AbstractCounter, which extends ValueEntity.

Event-Sourced Entity

Event-Sourced Entity stores the changes in Its state by making a journal of events that records something that has happened. It not only persists the current state but all the events that make up the current state. To load an entity Kalix reads the journal and replays events to compute the Entity’s current state. Also by default In Kalix As an optimization, Event Sourced Entities persist state snapshots periodically. This allows Kalix to recreate an Entity from the most recent snapshot plus any events saved after the snapshot.

class ShoppingCart(context: EventSourcedEntityContext) extends AbstractShoppingCart 

{

  @nowarn("msg=unused")

  private val entityId = context.entityId

  override def emptyState: Cart = Cart.defaultInstance

Here the Shopping Cart extends the generated AbstractShoppingCart, which extends EventSourcedEntity.

Replicated Entity

Replicated Entities do not persist their data anywhere. But are actually backed up by replicating It across a distributed environment which provides low latency and high availability. The replicated Entities distribute state using a conflict-free replicated data type (CRDT). The underlying CRDT semantics allow Replicated Entity instances to update their state independently and concurrently and without coordination. The state changes will always converge without conflicts, but It also means the state is eventually consistent so reading the current data may return an out-of-date value.

class ShoppingCart(context: ReplicatedEntityContext) extends AbstractShoppingCart {  

}

Conclusion

While all three entities are different and the way they approach data. Kalix as a service makes It so that all three are possible to do when creating a software.