Release The Event Hub: Web 3.0 - An Introduction

There are 2 factors of utmost import when coding: size and isolation.  While they both impact each other they are not the same.

Small code has fewer bugs.  Isolatable code has fewer dependencies and is easier to maintain.  So maintable code with few bugs, sign me up for that!

Small code is hard to write because code tends to get bound up in all the other code around it, despite our best efforts.

Especially over time feature creep and bug fixes tend to litter our once small code.  Plus it's just darn simpler at that moment to add code to already existing code instead of starting fresh.  So code grows and grows and without serious discipline that we all lack it never shrinks.

Isolatable code is hard to write because making everything an isolated unit is a giant pain in the ass.  There just is not any incentive day-to-day to write truly isolatable code.  If you do it still needs to be integrated into your application, why you are writing this code in the first place, and no one wants to keep doing that over and over again.  Besides have you ever seen an isolatable piece of
code?  Typically only the must mundane and obvious code is written as isolatable (or you're using 3rd party/open source code) - like obvious AOP stuff like logging and authentication.  Even then authentication is rarely isolatable from the HTTP server.  Same with session management.  Add authorization and message routing to all of that too.  Finally pulling 'business logic' away from the
HTTP server is difficult too.

Dependency management has almost single-handedly destroyed code quality since our ancesctors first hacked code on clay tablets back in the 1960s.  Creating, storing, calling, and destroying foreign objects has led to some of the most unmaintainable, tightly coupled, fan-out-crazy, untestable, downright ugly code imaginable.

With one stroke we can get rid of dependency hell, tightly coupled code, and useless blocking - while enhancing scalability, testability, maintainability, and code isolation.

Release The Event Hub!

Imgaine an army of independent handlers, each handler doing only one thing, communicating via only events and callbacks.  No external dependencies and no HTTP server requirement.  I'm talking about truly independent hunks of code 'Sofware as a Service' connected by an event hub.

Gone are the same-origin policy, HTTP servers routing messages, and tightly coupled code.

So how does it work?  Every independent module of code connects to a central event hub.  This hub can live on a separate host from your HTTP server and is actually a relatively simple piece of code.  It accepts connections from modules and passes emitted events to all connected listeners.  It also proxies callbacks back to the event emitter, is there is one (a callback, that is).

Event emitters connect to the hub and emit events and either:

1. are done
2. are listening for another event in response to theirs (or not)
3. wait for a callback from the listener

Event listeners connect to the hub and wait to service fired events.  In response they:

1. do nothing
2. fire another event
3. execute the provided callback

Of course a hunk of code can be both an event emitter and a listener.

OK that's enough for the first post - next up we'll look at how this actually all works (including sessions and security).  We will all miss multi-threading and method calls greatly: RIP.