Event-driven architecture in Express - Step-by-Step Execution

Concept Flow - Event-driven architecture

Event Occurs

↓

Event Emitted

↓

Event Listeners Check

↓

Listener 1

↓

Listener 1 Action

↓

Continue Program

When an event happens, it is emitted. Listeners waiting for that event react by running their actions.

Execution Sample

Express

const EventEmitter = require('events');
const emitter = new EventEmitter();

emitter.on('greet', () => {
  console.log('Hello!');
});

emitter.emit('greet');

This code sets up a listener for a 'greet' event and then emits that event, causing the listener to run.

Execution Table

Step	Action	Event	Listeners Present	Listener Action	Output
1	Create EventEmitter instance	N/A	None yet	None	No output
2	Add listener for 'greet'	'greet'	1 listener added	Listener waits	No output
3	Emit 'greet' event	'greet'	1 listener active	Run listener callback	Prints 'Hello!'
4	No more events	N/A	Listeners remain	No action	Execution ends

💡 No more events emitted, program stops listening.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
emitter	undefined	EventEmitter instance	Same instance with listener	Same instance	Same instance
listeners for 'greet'	0	0	1 listener function	1 listener function	1 listener function

Key Moments - 2 Insights

Why does the listener run only after emit is called?

Listeners wait silently until the event is emitted (see Step 3 in execution_table). Emitting triggers all listeners for that event.

Can multiple listeners respond to the same event?

Yes, multiple listeners can be added and all run when the event is emitted (concept_flow shows branching to multiple listeners).

Visual Quiz - 3 Questions

Look at the execution_table, what is the output at Step 3?

A Prints 'Hello!'

B No output

C Error thrown

D Listener removed

💡 Hint

Check the 'Output' column at Step 3 in execution_table.

At which step is the listener added for the 'greet' event?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look at the 'Action' and 'Listeners Present' columns in execution_table.

If we emit 'greet' twice, how would the output change?

A Prints 'Hello!' once

B Prints 'Hello!' twice

C No output

D Error on second emit

💡 Hint

Each emit triggers all listeners; see Step 3 behavior in execution_table.

Concept Snapshot

Event-driven architecture in Express:
- Create an EventEmitter instance
- Add listeners with .on(event, callback)
- Emit events with .emit(event)
- All listeners for that event run on emit
- Allows decoupled, asynchronous reactions to events

Full Transcript

Event-driven architecture means your program waits for events to happen, then reacts. In Express, you create an EventEmitter object. You add listeners that wait for named events. When you emit an event, all listeners for that event run their code. This lets your app respond to things like user actions or data arriving without blocking other work. The example code shows adding a listener for 'greet' and then emitting 'greet' to print 'Hello!'. Listeners only run when their event is emitted. You can have many listeners for the same event. Emitting multiple times runs listeners each time.

Practice

1. What is the main purpose of using EventEmitter in an Express app?

easy

A. To allow the app to react to events asynchronously

B. To handle HTTP routing and middleware

C. To connect to a database

D. To serve static files

Solution

1. Step 1: Understand the role of EventEmitter

   EventEmitter is used to create and listen for events, enabling asynchronous reactions in the app.

2. Step 2: Compare with other Express features

   Routing, database connections, and static file serving are handled by other parts of Express, not EventEmitter.

3. Final Answer:

   To allow the app to react to events asynchronously -> Option A

4. Quick Check:

   EventEmitter = async event handling [OK]

Hint: EventEmitter means reacting to events, not routing or DB [OK]

Common Mistakes:

• Confusing EventEmitter with routing or middleware
• Thinking EventEmitter manages database connections
• Assuming EventEmitter serves static files

2. Which of the following is the correct way to create an event emitter in Express?

easy

A. const emitter = require('events').EventEmitter();

B. const EventEmitter = require('events').EventEmitter; const emitter = new EventEmitter();

C. const emitter = new require('events');

D. const EventEmitter = require('events'); const emitter = new EventEmitter();

Solution

1. Step 1: Recall correct import syntax

   The events module exports EventEmitter as a property, so you must access it before creating an instance.

2. Step 2: Check each option's syntax

   const EventEmitter = require('events').EventEmitter; const emitter = new EventEmitter(); correctly imports EventEmitter and creates a new instance. const EventEmitter = require('events'); const emitter = new EventEmitter(); misses the .EventEmitter property. Options A and C misuse the constructor call.

3. Final Answer:

   const EventEmitter = require('events').EventEmitter; const emitter = new EventEmitter(); -> Option B

4. Quick Check:

   Correct import and new instance = const EventEmitter = require('events').EventEmitter; const emitter = new EventEmitter(); [OK]

Hint: Remember to get EventEmitter from require('events').EventEmitter [OK]

Common Mistakes:

• Calling EventEmitter as a function without new
• Missing .EventEmitter when requiring events
• Using new with require() directly

3. What will be the output of this Express event-driven code?

const EventEmitter = require('events').EventEmitter;
const emitter = new EventEmitter();
emitter.on('greet', (name) => {
  console.log(`Hello, ${name}!`);
});
emitter.emit('greet', 'Alice');

medium

A. Hello, Alice!

B. greet Alice

C. Error: greet event not found

D. No output

Solution

1. Step 1: Understand event registration

   The code registers a listener for the 'greet' event that logs a greeting with the given name.

2. Step 2: Analyze event emission

   When emitter.emit('greet', 'Alice') runs, it triggers the listener, printing "Hello, Alice!".

3. Final Answer:

   Hello, Alice! -> Option A

4. Quick Check:

   Emit triggers listener output = Hello, Alice! [OK]

Hint: emit triggers on() listener with arguments [OK]

Common Mistakes:

• Expecting no output without console.log
• Confusing event name with output text
• Thinking emit returns a value

4. Identify the error in this Express event-driven code:

const EventEmitter = require('events').EventEmitter;
const emitter = new EventEmitter();
emitter.emit('start');
emitter.on('start', () => {
  console.log('Started');
});

medium

A. emit method does not exist

B. EventEmitter is not imported correctly

C. Listener callback syntax is invalid

D. The event listener is registered after the event is emitted

Solution

1. Step 1: Check event listener registration timing

   The listener for 'start' is added after emitter.emit('start') is called, so it misses the event.

2. Step 2: Verify other code parts

   Import and syntax are correct; emit exists and callback syntax is valid.

3. Final Answer:

   The event listener is registered after the event is emitted -> Option D

4. Quick Check:

   Listener must be before emit to catch event [OK]

Hint: Register listeners before emitting events [OK]

Common Mistakes:

• Emitting event before listener causes no output
• Assuming emit queues events for future listeners
• Misreading import or callback syntax

5. You want to build a real-time notification system in Express using event-driven architecture. Which approach best organizes your code for scalability?

hard

A. Create a single global EventEmitter instance and emit all events through it

B. Use only middleware functions without events for notifications

C. Create separate EventEmitter instances for different modules and communicate via events

D. Handle notifications by polling the database every second

Solution

1. Step 1: Consider modular event handling

   Using separate EventEmitter instances per module keeps code organized and decoupled, improving scalability.

2. Step 2: Evaluate other options

   A single global emitter can become a bottleneck. Middleware alone doesn't handle async events well. Polling is inefficient and not event-driven.

3. Final Answer:

   Create separate EventEmitter instances for different modules and communicate via events -> Option C

4. Quick Check:

   Modular emitters = scalable event-driven design [OK]

Hint: Use modular EventEmitters for clean, scalable code [OK]

Common Mistakes:

• Using one global emitter causing tight coupling
• Ignoring event-driven benefits by polling
• Relying only on middleware for async events