A simple example of online audience engagement could be a Livestream with a host and a chat system for audience members to interact with each other in real-time. Other audience engagement solutions include features such as chat or QAs for participants to communicate while sharing an experience, such as a Watch Party, polls, quizzes, and leaderboards.
Device and User Presence
One aspect of audience engagement is the ability to know who’s participating in a virtual event or a user’s “presence”. Closely linked to presence is the user’s state, for essential functionality such as indicators when someone is typing a message into a chat window, or the real-time location of a device.
With an increasing number of connected, distributed devices, there has been a gradual shift in how data is processed and analyzed. The trend is also based on the growth of emerging technologies, such as the Internet of Things (IoT), microservices, and event-driven applications, which influence the development of real-time analytics.
This Refcard dives into how event stream processing represents this evolution by allowing continuous data analysis in the modern technology landscape.
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).
Should you happen to be researching "Service-Oriented Architecture" (SOA) on the Internet today, the latest articles you are likely to find will typically be titled: "SOA vs microservices". Complicating the battle somewhat is that you will also find respected industry experts, such as Martin Fowler, stating that some “consider microservices to be one form of SOA, perhaps service orientation done right”.
Martin goes on to declare: “The problem…is that SOA means too many different things and that most of the time we come across something called 'SOA' [there is]…a focus on ESBs (Enterprise Service Buses) used to integrate monolithic applications. This common manifestation of SOA has led some microservice advocates to reject the SOA label entirely”. As such, for the remainder of this article, I will assume the use of ESB middleware as a fundamental characteristic of SOA landscapes, as well as representing the most fundamental distinction there is between SOA and REST.
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.
Virtually every software developer in the world has heard of the ‘Model-View-Controller’ (MVC) Design Pattern, which is not entirely surprising given that it was “first introduced by Trygve Reenskaug, a Smalltalk developer at the Xerox Palo Alto Research Center in 1979.” Today, Oracle provides us with a nice representation of a 'Common MVC Implementation:'
Now, more than forty years later, and in the context of an emerging star in software integration — ‘Event-Driven Architecture’ — it seems high time for the next generation of MVC to be announced: the ‘Model-View-Broker’ (MVB) Pattern. Here is a reworked version of the earlier MVC Diagram, with key changes marked in yellow:
Microservices are a hot topic in software design, and for good reason. They have plenty of advantages when it comes to handling infrastructure complexity, many of which were addressed in part one of our related Java posts. Now, it’s time to talk about the code and design. In this post, we’ll take a deep dive into each module.
When creating an application, clean code means thinking about design and architecture. Architecture is the software process that handles flexibility, scalability, usability, security, and other points, so you have more time to focus on business rather than on technology. Some architecture examples include:
Today, architectures such as the onion or hexagonal patterns play an important role in the testability and maintenance of code, its independence from external frameworks, etc. In this tutorial, I will show you how to use clean architecture, with methods and tools such as Domain-Driven Design (DDD), Test (Behavior) Driven Development (TDD), CQRS, Event Sourcing, Containerization, OAuth2, and Oidc to build a microservices architecture.
