Event Sourced Orleans Grain

Event Sourced GrainI always thought a Event Sourced Orleans Grain would fit a really well as a stateful Aggregate Root.  Take it a step further and have your Grain be event sourced and also encapsulate a projection of current state.  This post is going to setup the basics of how to Raise events and apply them in our Grain state.  I will be covering persisting the events in the next post.

Blog Post Series:

Event Sourced Grain

I’m going to create a typical example using a bank account.  There are basically two events we will raise.  Deposited event to indicated that we have deposited money into the account and and Withdrawn event to that we have taken money out of the account.

Orleans provides a package Microsoft.Orleans.EventSourcing  to help raise events from you Grain as well as apply them to the state.  From the package, you now can have your grain derive from JournaledGrain<TState, TEvent>.

Grain State

From the example Grain above we are missing our actual grain state, which really a projection so we can keep our current balance.  Once an event is Raised the Grain will call the appropriate Apply(T evnt) method in our state.

Persistence

Next I’ll be persisting our events to Event Store.  This will include once a grain is activated, to pull the events and replay them to get to current state.

More!

If you want to try the demo, all the source is available on my PracticalOrleans GitHub Repo.

Do you have any questions or comments? Are you using Orleans?  I’d love to hear about it in the comments or on Twitter.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Orleans Smart Cache Pattern

Orleans Smart Cache PatternI discovered the Orleans Smart Cache Pattern by listening to a talk by John Azariah and Sergey Bykov.  The idea is that you can use Orleans as a distributed cache in front of (permanent) storage.  This is really ideal if you have a read heavy system, which most are.  You could optionally also choose to buffer your writes when you make state changes.  Ultimately you will reduce load on your storage by accessing data/state from memory.

Blog Post Series:

Video Tutorial

 

State Holder Grain

The idea is we are going to create a Grain that will be used for holding/containing our state.  There are just two methods, setting and getting our state as defined in IStateHolderGrain<T>

Implementation

For this example, I’m creating a POCO CustomerState to hold some customer data.

Then create a ICustomerGrain that just extends IStateHolderGrain where T is our POCO CustomerState.

Our concrete class CustomerGrain that implements that new ICustomerGrain.

Lastly I created a CustomerStateService which just contains some static methods that create and retrieve our POCO.

Usage

As per my previous post, I’m using ASP.NET Core with Botwin Middleware for a route endpoint.  From here I can use the CustomerStateService to create and fetch out our data.

Abstraction

One of the benefits is abstraction as we can have a POCO for our state that can be persisted to permanent storage.  There’s no dependency of Orleans in our POCO or Botwin Module.

Also we have an immediate consistent cache.  If we were to expose methods to modify the state, our grain would persist those to permanent storage when it decides and we are always returning the most up to date state.

More!

If you want to try the demo, all the source is available on my PracticalOrleans GitHub Repo.

Do you have any questions or comments? Are you using Orleans?  I’d love to hear about it in the comments or on Twitter.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Creating a custom ASP.NET Core Output Formatter

ASP.NET Core Output FormatterIf you follow my blog, you may also know that I’ve blogged a bit about Hypermedia.  Because I’m a fan, I’ve decided to start creating an custom ASP.NET Core Output Formatter to handle the Siren hypermedia specification (application/vnd.siren+json).

All the code samples in this blog post are pulled from a sample application of the game Hangman.   I’m creating it in ASP.NET Core.  I will eventually pull out the Output Formatter and create a repo on GitHub and a Nuget.

Output Formatter

Since I’m handling Text, I’m going to be deriving from the TextOutputFormatter.  This requires you to implement two methods:

bool CanWriteType(Type type)

This method determines if your output formatter can handle the type returned from your controller action.

Task WriteResponseBodyAsync(OutputFormatterWriteContext context, Encoding selectedEncoding)

Handle how yo want to transform the object returned from your controller action.

Lastly, you also need to define which media types your output formatter will handle.  In other words, when the client sends an Accept: header, which values apply to your output formatter.

In my case, Siren uses application/vnd.siren+json

MVC Options

Finally, in our startup, we need to add our new Output Formatter in the AddMVC extension method.

Results

Here are two different outputs.  The first is with an Accept: application/json and the second is requestion Siren with Accept: application/vnd.siren+json

Stay Tuned

If you’re interested in supporting Siren in your ASP.NET Core MVC applications, I plan on publishing my small library soon to GitHub as well as Nuget.

Have you created a custom output formatter? I’d love to hear what your creating!  Let me know on Twitter or in the comments.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.