Can Event‑Driven Architecture Revolutionize Web Frameworks?

Background

In past framework design discussions, the most useful advice was to first define the ideal framework without being constrained by existing technologies, then evaluate feasibility and compromise only when necessary. This article follows that advice to imagine the future evolution of web frameworks.

Data and Logic

Any application can be reduced to two essentials: data and logic . A data dictionary describes the data; a process diagram describes the logic.

Using a simple pseudo‑code model:

User : {
  name : string
}

Post : {
  title : string,
  content : text
}

Tag : {
  name : string
}

User -[created]-> Post
Post -[has]-> Tag

Logic can be expressed similarly. For example, creating a post with tags and optional @‑mentions:

class User {
  createPost(content, tags = []) {
    var post = new Post({content: content});
    post.setTags(tags.map(tagName => new Tag(tagName)));
    return post;
  }
}

// with @‑mention handling
class User {
  createPost(content, tags = []) {
    var post = new Post({content: content});
    post.setTags(tags.map(tagName => new Tag(tagName)));
    if (at.scan(content)) {
      at.getUser(content).forEach(atUser => {
        system.mail(atUser);
      });
    }
    return post;
  }
}

To keep code short, maintainable, and extensible, the article proposes using an event system where each business operation is an event and listeners implement the actual work.

// emitter is the event center
emitter.on("post.create", function savePost(){...});

emitter.on("post.create", function createTags(){...}, {before:"savePost"});

emitter.on("post.create", function scanSensitiveWords(post){
  if (system.scanSensitiveWords(post)) {
    return new Error("you have sensitive words in post.");
  }
}, {block:"all"});

emitter.on("post.create", function scanPopTags(){...});

// fire the event
emitter.fire("post.create", {...args});

This structure makes each operation single‑purpose and the overall code tidy. The order of execution can be expressed with parameters like {before:"savePost"}, aligning code order with logical description.

Advantages include clear maintainability (code mirrors business flow) and extensibility (adding or removing listeners does not affect other code). The event stack can be visualized as a flowchart, enabling automatic testing, monitoring, and even generating code from diagrams.

From Ideal to Reality

The article discusses using graph databases (e.g., Neo4j) for data modeling, where relationships are expressed naturally as edges, avoiding the impedance mismatch of relational schemas. Querying with pattern‑matching (Cypher) aligns with the “data‑first” philosophy.

On the logic side, implementing an event system is straightforward in any language, and a unified event stack format enables cross‑language integration (Node.js, Python, Go, etc.). This opens possibilities for language‑agnostic services and container‑based deployment.

Examples of a prototype todo application built with React (frontend) and Koa (backend) illustrate the concepts, showing directory structure, data files, and event‑driven code for creating posts and handling @‑mentions.

Afterword

The author reflects on the philosophical inspiration behind the architecture, drawing parallels between human cognition and adaptable systems. By modeling applications as data + logic and using events to reflect business processes, the framework aims to achieve high development speed, maintainability, and extensibility.

Discussion Record

Participants compare the approach to Flux, discuss event‑bus scalability, namespace control, and the importance of keeping events focused on business logic rather than technical implementation.