A few good arguments for adopting an asynchronous messaging pattern in a microservice environment include high scalability,
loose coupling and better use of resources. Instead of continuously polling the source system, the flow of communication is inverted. Messages are produced by the source system in order to inform consumers of noteworthy events. Those events are expressed in messages that are distributed by a message broker. The design of those messages has a direct impact on the implementation of the producing and consuming services.
<h2>Message Design</h2>
Events are supposed to inform consumers that something has happened. In frontend applications that could either apply to an application state change triggered by an action or to a context change, an event captured by the browser, like a page scroll, cursor movements and there like. Without loss of generality, in a classic CRUD based backend application it usually relates to a state change: A record was inserted, updated or deleted.
<h3>Operations on Entities</h3>
A simple representation of an event is the full state of a data item and a fixed set of operations that can be applied to this state. This is quite similar to the application of the REST pattern, where a <code>POST</code> (creation) and <code>PUT</code> (update) HTTP request include the full payload of the entity to be inserted or updated. In order to inform the consumer about the nature of the event, metadata could be added to the event.
For a todo that was just added to a list of todos, the message representing such an event could look like this:
<pre class="language-json"><code class="language-json">{
 "metadata": {
 "action": "INSERT"
 },
 "data": {
 "id": 1,
 "text": "My first todo.",
 "completed": false
 }
}
</code></pre>
Let's imagine the owner of this todo has completed the task and an <code>UPDATE</code> message is published. It is structured in the same way, only now the <code>action</code> property is assigned to <code>UPDATE</code> and the <code>completed</code> property is set to <code>true</code>. For a consumer it is not clear, what triggered the event and what in particular changed. It is only obvious, that something has changed, and it is up to the consumer to find out what it was.
In some scenarios this could still be sufficient though: If it is not necessary to react to events but rather store the latest state for the purpose of extending the service's dataset, it should be fine to include the full state in each message. Choosing this approach also reduces the dependency between each event sine every event self-contained as it includes all the information to represent a data item's current state.
<h3>Occurrences of Actions</h3>
Another way to tackle the message design is to think of events as occurrences of actions in a well-defined process. Every action leads to state change. Therefore, each message should describe the action that occurred and the properties of the state that changed as a consequence.
A completed todo item could be represented for example like this:
<pre class="language-json"><code class="language-json">{
 "event": "TodoCompleted",
 "id": 1
}
</code></pre>
The consumer is now able to easily understand what happened (<code>&quot;event&quot;: &quot;TodoCompleted&quot;</code>). The reaction to that event is entirely up to the consumer. It could mean updating the todo's state by setting the <code>complete</code> property to <code>false</code>.
In the end a series of events leads to the current state of an entity. This is called &quot;event sourcing&quot;. Although the messages are much more succinct and carry a stronger semantic meaning as they represent an event very specifically, there are extra costs on the implementation side. It's up to the consumer to interpret those events and to react to them appropriately. There could be a multitude of events that are emitted, which makes documentation essential.
<h3>Order</h3>
Ideally, events are self-contained in a sense that they do not have any other dependencies towards other events and can appear in any particular order. This reduces complexity both for the message queue, which might otherwise be required to order messages by a certain criterion, and the consumer, that otherwise needs to make additional queries and decision based on the order of events.
If the text of a task has changed multiple times (e.g. <code>ToDoTextChanged</code>) and the events are not ordered, the consumer has no way of determining the most recent text of the todo item.
This can be solved by adding a criterion by which the consumer is able to order the sequence or decide on an appropriate action. If the service has already seen at least one event and the following one has a lower sequence number, it can simply choose to ignore this event for example. But this also means the service needs to query the latest sequence number or store it in memory, make the comparison, which introduces additional overhead.
<h2>Other Event Types</h2>
Events are pretty flexible in what they actually express. The word &quot;message&quot; was chosen deliberately, since it carries the notion of informing the consumers about an event. As soon as the message leaves the sender, the sender's job is done, and it has no idea how the consumers of the message will react to it. This is exactly what manifests the loose coupling between sender and consumer and enables the scaling as the sender can carry on with its duties, while the message broker distributes the message amongst the consumers.
There are other patterns, like the <a href="https://martinfowler.com/bliki/CQRS.html">Command Query Responsibility Segregation (CQRS)</a>, pattern, that describes asynchronous communication based on &quot;query&quot; and &quot;command&quot; events. In contrast to plain messages, the sender sends a message with the clear intent to invoke a certain action or process on the receiver's side. Furthermore, the result of the invocation is even sent back to the original sender. In this case asynchronicity is they key selling point, but loose coupling only to a certain extent - if at all.
So the question is, what fits the underlying business process and what technological requirements are in place. Based on the answer, the implementation of an event-driven architecture can be designed. Of course there are also enough cases, that don't fit the asynchronous messaging approach at all.

Message Design In An Event Driven Architecture

I've been working on an enterprise reporting tool for the past year.
The frontend of that tool consists only of a couple of views and one of them
is a relatively complex form, which is also the heart of this reporting tool.
<h2>Challenges</h2>
It consists of a lot of features that make the implementation of a form quite
challenging. There are dropdown fields filled with items dynamically loaded from
an API endpoint (1).
Other dropdowns show a list of items based on the selection of a dependent field (2).
The money input fields format the number based on the chosen locale while keeping
an unformatted, pure JavaScript number in the state. Other money input fields
depend on one or multiple money input fields and are sometimes calculated
automatically (3,5). To make things harder, some calculations are bidirectional
between multiple fields.
Imagine a price value and a commission percentage. Multiplying those values equals
the value of the commission input. Should the change of the commission now change
the percentage or the price value?
And to make things even more exciting, complete parts of the form are exchanged
based on other fields (4).
<img 
 src="../images/articles/formik-in-complex-forms/form.png"
 srcset="../images/articles/formik-in-complex-forms/form.png,
 ../images/articles/formik-in-complex-forms/form@2x.png 2x"
 alt="Simplified mockup of the complex form"
/>
<h2>Formik</h2>
It makes sense to choose a library to handle all the internals of form state handling,
validation and so on not to reinvent the wheel. Formik is such a library: It has earned
more than 28.5k stars on GitHub (<a href="https://github.com/formium/formik">link</a>)
and is even mentioned briefly in the React documentation (<a href="https://reactjs.org/docs/forms.html#fully-fledged-solutions">link</a>).
Formik comes with a couple of appealing features: Support for a custom validation
mechanism, provides hooks to read from and update the state as well as a couple
of standard handlers for <code>onChange</code> and <code>onBlur</code>. It also has a component to deal
with lists and offers functions to deal with them accordingly (e.g. adding and
removing items).
With more than twenty fields with such special behaviors as described previously,
each of which reacts to every key press, a form library is challenged not only in
terms of its functionality, but also in terms of performance.
<h2>Performance</h2>
And indeed an input lag was noticeable which led to the discovery of Formik's
<code>FastField</code> component (<a href="https://formik.org/docs/api/fastfield">link</a>):
<blockquote>
<code>&lt;FastField /&gt;</code> is an optimized version of <code>&lt;Field /&gt;</code> meant to be used on large forms
(~30+ fields) or when a field has very expensive validation requirements.
</blockquote>
The problem is that every field update causes the whole form state to be rewritten.
This on the other hand triggers every field that is either rendered with the
<code>&lt;Field /&gt;</code> component or uses the <code>useField()</code> hook.
This is calling for trouble and the sheer co-existence of <code>&lt;FastField /&gt;</code> raises
the question, why the other components are not optimized for performance from the
beginning on.
One a half years ago a GitHub issue was opened to raise awareness to the performance
issues that come with the <code>useField()</code> hook, but it's not resolved. According to a
GitHub user commenting in this thread (<a href="https://github.com/formium/formik/issues/2268">link</a>)
Formik's architecture makes it nearly impossible to implement an efficient solution.
Instead he proposes to rely on <code>React.memo</code> to avoid unnecessary rerenders.
Unfortunately that's close to the solution we were forced to apply in order to
prevent those costly rerenders: Intead of wrapping the <code>useField()</code> hook, which is
smart, we decided to wrap our custom input field components, like the money input
field and the dropdowns for example.
<h2>Conclusion</h2>
Formik offers a clean documentation, a great set of hooks and components to get
the job done, and is a sufficient solution for smaller forms. Due to the serious
performance bottlenecks in complex forms and the lack of improvement over the
course of the past one and a half years, a choice in favor of Formik should
be considered carefully.
React Final Form (<a href="https://final-form.org/react">link</a>) is another library that offers &quot;high performance subscription-based form state management&quot;:
<blockquote>
For small forms, redrawing your entire form on every keypress is no problem. But when your form grows, performance can degrade.
</blockquote>
<blockquote>
No other form library allows such fine tuning to manage exactly which form elements get notified of form state changes.
</blockquote>
Its API is quite similar to Formik in a lot of components, and therefore it's relatively
easy to switch to this solution. There is even a migration guide available (<a href="https://final-form.org/docs/react-final-form/migration/formik">link</a>).
Additional features, like decorators (<a href="https://final-form.org/docs/final-form/types/Decorator">link</a>), only add to its
value and reduce the amount of code that needs to implemented manually otherwise.