Posted on

Why the Cool Kids Use Event Loops

When I was working in software development back in the 1990s, nearly all the software libraries that I worked on made use of event loops. This was because at the time most hardware had just one single CPU. Back in the day, I remember the excitement when threads were introduced into our development framework. It was revolutionary that we could now run two things at once, or rather appear to run two things at once, since a lot of the hardware at that time still only had a single core, and hence our threaded code was never really truly concurrent.

Over the years I've had mixed feelings about threads. Some of the most challenging systems that I’ve maintained have suffered from the overuse or misunderstood impact of concurrency. Even today I have discussions around if a piece of code is truly thread-safe and although the libraries (for example, the Java Concurrency Library) have made massive improvements reducing the burden of developing with threads, it is still somewhat of a challenge to ensure that we are not calling code which is not thread-safe when we have assumed it is. This is something that is generally not easily picked up by either static analysis or software compilers.

Posted on

How to Develop Event-Driven Architectures

Last month, I wrote an article on open-source Chronicle Wire that discusses how we could serialize an application’s state into different message formats.

Now in this article, I'm going to look at how we can use open-source Chronicle Queue and Chronicle Wire to structure applications to use event-driven architecture (EDA). EDA is a design pattern in which decoupled components (often microservices) can asynchronously publish and subscribe to events. 

Posted on

Events Are the New Data

The Oxford Dictionary defines ‘Data’ as: “Facts … collected together”. Should we instead use the specialized language of application architects, ‘Data’ can be more accurately defined as: ‘Events folded together’. ‘Folding’ represents the act of merging a particular Entity’s (State-changing) Events, in chronological order, to compute the latest Entity ‘State’ — what we typically refer to today as a Data 'Record'. Data — unlike Events — is an abstract notion. Whilst ‘Events’ represent actual changes to an Entity’s State (e.g. PurchaseOrder.Deleted), ‘Data’ represents no more than the calculated State of a particular Entity, once all preceding Events have been folded together; something that cannot even be performed should you ever lose any Events. 

At some point in history it was decided — clearly owing to restrictive hardware costs at the time — that we could not possibly store all State-changing ‘Events’ in our Data-bases, but that instead, we could only store ‘Data’: the current ‘Folded State’ of each business Entity (until such a time as even that was archived, owing to archaic hardware constraints).

Posted on

Event-Driven Architecture: 5 More Myths

In a previous post, I discussed what event-driven architecture (EDA) is and the common claims associated with it. Since EDA is not a common concept and has been around in the industry for over 20 years now (yes that's right!), it has accumulated a lot of claims associated with it and, over the years, some of these claims have been busted as myths or proven as facts.  

In this post, I will discuss 5 more claims about EDA and providing an argument as to whether each is a myth or a fact. Let's get started!

Posted on

Event-Driven Architectures: 5 Myths

Event-Driven Architecture: Bust or Fact?

Alright, let's face it—there is a lot of content talking about how REST vs messaging APIs and how one is more fir than the other for a microservices architecture design. I wrote a blog post about My journey to learning EDA that highlights what event-driven architecture is. Whether you are new to event-driven architecture (EDA) or have some background with it via dabbling with gRPC, kafka, rabbitMQ, Solace, or whatever messaging API, I am here to share with you 5 claims about EDA that I will be busting or confirming. 

I Will Have to Re-Design My Rest-Heavy Architecture From Scratch To Adopt EDA

MYTH

Advanced event brokers allow for protocol translation within the broker. What does this mean you might ask? Well, it is very common in any software architecture design approach to have a polyglot of protocols and APIs in an application. Whether you are using REST, or different messaging protocols (MQTT, AMQP, Solace, Kafka...etc) you would want your different microservices to communicate with each other. 

Posted on

Mobile Apps Dataset

Introduction

My main job is related to mobile advertising, and from time to time, I have to work with mobile application datasets.

I decided to make some of the data publicly available for those who want to practice building models or get an idea of some of the data that can be collected from open sources. I believe that open-source datasets are always useful as they allow you to learn and grow. Collecting data is often a difficult and dreary job, and not everyone has the ability to do it.

Posted on

Contract-First Development — the Event-Driven Way!

Introduction

Contract first application development is not limited to synchronized RESTFul API calls. With the adoption of event-driven architecture, more developers are demanding a way to set up contracts between these asynchronous event publishers and consumers. Sharing what data format that each subscriber is consuming, what data format is used from the event publisher, in a way OpenAPI standards is going to be very helpful.

But in the asynchronous world, it is ever more complex, not only do you need to be caring about the data schema, there are different protocols, serializing, deserializing mechanisms, and various support libraries. In fact, there are talks on AsyncAPI. But I am going to show you that what can be done today,  is to use ONE of the most commonly used solutions in building EDA, “Kafka”. And show how to do Contract First Application Development using Camel + Apicurio Registry.