I decided to build a Event Driven Stock Price Application using Event Grid, SignalR, and ReactJS. Just a little something to play with as I prepare to join Microsoft Consulting Services. I thought I would recount my experience here. First, here is what the flow looks like:

While the diagram may look overbearing it really is quite simple:

• Producer console app starts with some seed data of stock prices I gathered
• It adjusts these values using some random numbers
• The change in price is sent to an Event Grid topic with an EventType declared
• The EventGrid subscriptions look for events with a matching EventType
• Those that match will fire their respective Azure function
• The Azure Function will then carry out its given task

I really prefer Event Grid for my event driven applications. Its fast, cost effective, and has a better interaction experience than Service Bus topics, in my opinion. The subscription filters can get down to analyzing the raw JSON coming through and it supports the up and coming Cloud Events (cloudevents.io) standard. It also can tie into the tenant providers and respond to native Azure events, such as blob creation/deletion. All in all, it is one of my favorite Azure services.

So regarding the application, I choose to approach this from a purely event driven fashion. All price changes are seen as events. The CalculateChangePercent receives all events and, using the symbol as the partition key, looks up the most recent price stored in the database.

Based on this and the incoming data it determines the change percent and creates a new event. Here is the code for that:

	[FunctionName("CalculateChangePercent")]
	public void CalculateChangePercent(
	[EventGridTrigger] EventGridEvent incomingEvent,
	[Table("stockpricehistory", Connection = "AzureWebJobsStorage")] CloudTable stockPriceHistoryTable,
	[EventGrid(TopicEndpointUri = "TopicUrlSetting", TopicKeySetting = "TopicKeySetting")] ICollector<EventGridEvent> changeEventCollector,
	ILogger logger)
	{
	var stockData = ((JObject)incomingEvent.Data).ToObject<StockDataPriceChangeEvent>();
	var selectQuery = new TableQuery<StockDataTableEntity>().Where(
	TableQuery.GenerateFilterCondition(nameof(StockDataTableEntity.PartitionKey), QueryComparisons.Equal, stockData.Symbol)
	);
	var symbolResults = stockPriceHistoryTable.ExecuteQuery(selectQuery).ToList();
	var latestEntry = symbolResults.OrderByDescending(x => x.Timestamp)
	.FirstOrDefault();
	if (latestEntry != null)
	{
	var oldPrice = (decimal) latestEntry.Price;
	var newPrice = stockData.Price;
	var change = Math.Round((oldPrice – newPrice) / oldPrice, 2) * –1;
	stockData.Change = change;
	}
	changeEventCollector.Add(new EventGridEvent()
	{
	Id = Guid.NewGuid().ToString(),
	Subject = $"{stockData.Symbol}-price-change",
	Data = stockData,
	EventType = "EventDrivePoc.Event.StockPriceChange",
	DataVersion = "1.0"
	});
	}

view raw create-event.cs hosted with ❤ by GitHub

This is basically “event redirection”, that is taking one event and create one or more events from it. Its a very common approach to handle sophisticated event driven workflows. In this case, once the change percent is calculated the information is ready for transmission and persistence.

This sort of “multi-casting” is at the heart of what makes event driven so powerful and, so risky. Here two subscribers will receive the exact same event and take very different operations:

• Flow 1 – this flow takes the incoming event and saves it to a persistence store. Usually, this needs to be something high availability, consistency is usually not something we care about.
• Flow 2 – this flow takes the incoming event and sends it to the Azure SignalR service so we can have a real time feed of the stock data. This approach in turn allows connecting clients to also be event driven since we will “push” data to them.

Let’s focus on Flow 1 as it is the most typical flow. Generally, you will always want a record of the events the system received either for analysis or potential playback (in the event of state loss or debugging). This is what is being accomplished here with the persistence store.

The reason you will often see this as a Data Warehouse or some sort of NoSQL database is, consistency is not a huge worry and NoSQL database emphasize the AP portion of the CAP theorem (link) and are well suited to handling high write volumes – this is typical in event heavy systems, especially as you get closer to patterns such as Event Sourcing (link). There needs to be a record of the events the system processed.

This is not to say you should rely on a NoSQL database over an RDBMS (Relational Database Management System), each has their place and there are many other patterns which can be used. I like NoSQL for things like ledgers because they dont enforce a standard schema so all events can be stored together which allows for easier re-sequencing.

That said, there are also patterns which periodically read from NoSQL stores and create data into RDBMS – this is often done if data ingestion needs are such that a high volume is expected but the data itself can be trusted to be consistent. This may create data into a system where we need consistency checks for other operations.

Build the Front End

Next on my list was to build a frontend reader to see the data as it came across. I choose to use ReactJS for a few reasons:

• Most examples seem to use JQuery and I am not particularly fond of JQuery these days
• ReactJS is, to me, the best front end JavaScript framework and I hadnt worked with it in some time
• I wanted to ensure I still understood how to implement the Redux pattern and ReactJS has better support than Angular; not sure about Vue.js

If you have never used the Redux pattern, I highly recommend it for front end applications. It emphasizes a mono-directional flow of data built on deterministic operations. Here is a visual:

I first used this pattern several years ago when leading a team at West Monroe, we built a task completion engine for restaurants, we got pretty deep into the pattern. I was quite impressed.

Put simply, the goal of Redux is that all actions are handled the same and state is recreated each time a change is made, as opposed to updating state. By taking this mentality, operations are deterministic meaning the same result will occur no matter how many times the same action is executed. This bakes very nicely with the event driven model from the backend which SignalR carries to the frontend.

Central to this is the Store which facilitates subscribing and dispatching events. I wont go much deeper into Redux here, much better sources out there such as https://redux.js.org/. Simply put, when SignalR sends out a messages it sends an event to listeners – in my case its the UpdateStockPrice event. I can use a reference to the store to dispatch the event, which allows my reducers to see it and change their state.

Once a reducer changes state, a state updated event is raised and any component which is connected will update, if needed (ReactJS uses shadow DOM to ensure components only change if they were actually changed). Here is the code which is used (simplified):

	// located at the bottom of index.js the application bootstrap
	let connection = new HubConnectionBuilder()
	.withAutomaticReconnect()
	.withUrl("https://func-stockdatareceivers.azurewebsites.net/api/stockdata")
	.build();
	connection.on('UpdateStockPrice', data => {
	store.dispatch({
	type: UpdateStockPriceAction,
	data
	});
	});
	connection.start();
	// reducers look for actions and make changes. The format of the action (type, data) is standard
	// if the reducer is unaware of the action, we return whatever the current state held is
	const stockDataReducer = (state = initialState, action) => {
	switch (action.type) {
	case UpdateStockPriceAction:
	const newArray = state.stockData.filter(s => s.Symbol !== action.data.Symbol);
	newArray.push(action.data);
	newArray.sort((e1, e2) => {
	if (e1.Symbol > e2.Symbol)
	return 1;
	if (e1.Symbol < e2.Symbol)
	return –1;
	return 0;
	});
	return { stockData: newArray };
	default:
	return state;
	}
	};
	// the component is connected to the store and will rerender when state change is made
	class StockDataWindow extends Component {
	render() {
	return (
	<div>
	{this.props.stockData.map(d => (
	<StockDataLine stockData={d} key={d.Symbol} />
	))}
	</div>
	);
	}
	};
	const mapStateToProps = state => {
	return {
	stockData: state.stockData
	};
	};
	export default connect(mapStateToProps, null)(StockDataWindow);

view raw update.js hosted with ❤ by GitHub

This code makes use of the redux and react-redux helper libraries. ReactJS, as I said before, supports Redux extremely well, far better than Angular last I checked. It makes the pattern very easy to implement.

So what happens is:

• SignalR sends a host of price change events to our client
• Our client dispatches events for each one through our store
• The events (actions) are received by our reducer which changes its state
• This state change causes ReactJS to fire render for all components, updating Shadow DOM
• Shadow DOM is compared against action DOM and components update where Shadowm DOM differs

This whole process is very quick and is, at its heart, deterministic. In the code above, you notice the array is recreated each time rather than pushing the new price or trying to find the existing index an updating. This may seems strange but, it very efficiently PREVENTS side effects – which often manifest as some of the more nastier bugs.

As with our backend, the same action could be received by multiple reducers – there is no 1:1 rule.

Closing

I wrote this application more to experiment with Event Driven programming on the backend and frontend. I do believe this sort of pattern can work well for most applications; in terms of Redux I think any application of even moderate complexity can benefit.

Code is here: https://github.com/jfarrell-examples/StockApp

Happy Coding