baker

baker copied to clipboard

With Baker 2, we used Baker.eventsWithTimestampAsync to implement an algebra resembling

trait OrderService[F[_], Stream[_, _], OrderRequest, OrderHandle, OrderEvent] {

  /** Command that instantiates a recipe */
  def placeOrder(request: OrderRequest): F[OrderHandle]

  /** Emits past and present event instances, marshalled to [[OrderEvent]] */
  def getOrderEvents(id: OrderHandle): Stream[F, OrderEvent]
}

The Baker method enabled us to obtain all past event instances (RuntimeEvent, similar to current EventInstance). These included a map of the associated ingredient values. This way we could event-source OrderService client state, with OrderService providing the event store by polling Baker.

It looks like in Baker 3.0.0-RC, this method is gone and we can only obtain, using Baker.getRecipeInstanceState:

• a list of the past event instance names
• a map of the present ingredient values, with past ingredient values hidden

Do you plan to bring back to Baker 3 a Baker API that enables us to retrieve past EventInstances including past ingredient values?

Have you developed best practices designing Baker-driven service APIs that would lead to different design decisions?

BTW, the alternative algebra we are now considering resembles

trait AlternativeOrderService[F[_], Stream[_, _], OrderRequest, OrderHandle, OrderState] {

  /** Command that instantiates a recipe */
  def placeOrder(request: OrderRequest): F[OrderHandle]

  /** Emits current accumulated state, and subsequent states in the future */
  def getOrderState(id: OrderHandle): Stream[F, OrderState]
}

This hides the implementation detail that Order state is event-sourced, and this can be implemented using Baker.getRecipeInstanceState. But design-time it forces us to commit to an OrderState representation early, which can sometimes be harder than committing to event representations.

Hello Sander,

The possibility to get Ingredients provided by a specific Event is indeed gone. This was never a future we specifically wanted to provide and was more or less created by accident. We where exposing an internal object (RuntimeEvent) and we should not have.

The idea with Baker is you have Events and you have Ingredients. Ingredients are always the latest version of the data. You should not care where the ingredients are provided from. This could be from an SensoryEvent or as output of a Event from an Interaction. This should not matter, only if the ingredient is available should matter. This will allow you to flexible change your recipe without impacting your other code.

I am sorry to say that we are not planning to bring it back. We have removed this information from the RecipeInstance itself. Removing this and not sending it on each inquire is one of the main reasons Baker V3 has better performance and memory footprint. Sending the data as it used to be would require a refactor of this class again.

I think your last question hits the nail on the head, we are missing guide lines/best practices for developing a API with Baker. This allowed users to use Baker in ways we did not intended.

Regards,

Tim Linschoten

Hello Sander,

The possibility to get Ingredients provided by a specific Event is indeed gone. This was never a future we specifically wanted to provide and was more or less created by accident. We where exposing an internal object (RuntimeEvent) and we should not have.

The idea with Baker is you have Events and you have Ingredients. Ingredients are always the latest version of the data. You should not care where the ingredients are provided from. This could be from an SensoryEvent or as output of a Event from an Interaction. This should not matter, only if the ingredient is available should matter. This will allow you to flexible change your recipe without impacting your other code.

I am sorry to say that we are not planning to bring it back. We have removed this information from the RecipeInstance itself. Removing this and not sending it on each inquire is one of the main reasons Baker V3 has better performance and memory footprint. Sending the data as it used to be would require a refactor of this class again.

I think your last question hits the nail on the head, we are missing guide lines/best practices for developing a API with Baker. This allowed users to use Baker in ways we did not intend.

Regards,

Tim Linschoten

Thank you for the clear response @Tim-Linschoten. Issued https://github.com/ing-bank/baker/pull/288 to add to the release notes.