Before OOP languages, the programmer would control how the program is executed, and that would be the main routine of the application. In modern programming, this control is delegated to external non-main circuits, and the main routine becomes an event loop that waits for events to occur and then executes it with the appropriate event handler.
This new programming model (however, it has been used since the 70s) is called event-driven programming.
What is event-driven programming?
In event-driven programming, user actions and interactions are triggers that trigger the next stream of events. Applications built in 2021 are usually made with the user at the center of the programmer’s thinking, and as such are created to respond to all kinds of user commands.
This asynchronous programming model, as mentioned above, usually has an event loop that searches for new events as they arrive. Once an event is initiated, the event handler is triggered at a specific time when the event is generated.
These start-up procedures can be either stored routines or external programs. Thus, the control of the flow of program execution is external, largely invisible to the programmer, and the control is not perceptible.
What are 3factor applications?
The 3factor application is a modern artificial model for building modern full-stack applications. The 3-factor architecture pattern is fully aligned with the event-driven programming paradigm and uses the following 3 “factors”:
- Real-time GraphQL.
- Reliable transaction.
- Asynchronous (Async) serverless.
Here is an example of a food ordering application built on a traditional model compared to a 3-factor methodology:
The core of the whole model is that all business logics are triggered through events.
1. Real-time GraphQL
The GraphQL layer allows flexible API access and is used to modify and manipulate states while receiving real-time updates for state changes. This GraphQL level should be:
- Low latency: The user must be able to receive immediate feedback from the app on any activity.
- Supports orders: Avoid constant query by being able to consume real-time data from the backend service through GraphQL subscriptions.
The traditional model used REST APIs to interact with the backend system, retrieved related information through multiple calls, used tools such as Swagger for API documents, required to configure custom APIs in real time (or for query). Meanwhile, 3factor uses GraphQL APIs for backend interaction, can retrieve all kinds of data from a single cell, create the entire API model and related documents automatically, and use native GraphQL subscriptions to consume data in real time.
2. Reliable transaction
From the example diagram above, we can see that transactions use business logic, leaving your API level free of complex state management that can be delegated to specifically created logic programs or functions.
It is recommended that events continue due to the visibility of the history of change throughout the state. The transaction system should also be:
- Atom: Any application state mutations should create an atomic event (s).
- Reliable: Transactions must be delivered at least once a warranty.
In the 3-factor model, the API call, we can generate and maintain events that represent activity and the event is essentially asynchronous. But seamless error recovery handling is undoubtedly the most advantageous advantage in making an application event-based. The traditional workflow must have additional error recovery logic that must be implemented in the event of a crash, but such logic is not required because the application sends atomic events that can be easily retried in the event of a crash.
3. Async Serverless
Because the main routine is just an event loop consisting of event handlers, complex business logic can be present in the event processing functions themselves, where each function is small and consistent and handles only one event. These features can be deployed on serverless back-end systems, which reduces back-end functionality and is very cost-effective when scaling.
These serverless functions with complex business logic should be:
- Idempotent: Must be prepared to submit duplicate transactions.
- Out of order: Sharks are known to eat underwater copper lines that use the Internet a lot. This and more realistic problems can cause events to be received out of order, so the code should be able to handle this without the expected sequence of events.
The 3-factor model allows us to write loosely connected event handlers, allows us to deploy to serverless platforms, does not require us to perform runtime management (the platform does it), does not require operational expertise, and is inherently automatic scaling.
Event-driven programming paradigm combined with 3-factor application architecture pattern is the most modern way to build applications in 2021. There are arguments against event-driven programming that only GUI applications benefit and others do not need it or it is too complex for simple applications but together with 3factor methodology a powerful tool that focuses on speed, reliability, scalability and where the user is focused.