lukaswilkeer/event-driven-architecture

A event driven api

• 👋 Hi, I’m @lukaswilkeer
• 👀 I’m interested in javascriprt, nodejs, functional and imperative languages.
• 🌱 I’m currently learning/praticing imperative code style on nodejs enviroments.
• 💞️ I’m looking to collaborate projects that involves streamable interfaces.
• 📫 How to reach me! Infos are on my profile.

event-driven-architecture's Issues

Feature: Asyncrhonous stream events

Need a way to work with asynchronous stream events.

Differences between OOP, imperative and functional design

OOP

On a OOP design, the events can be triggered by calling a dispatcher, that instantiate a new class and calling the derived function. On the first hand, we can conclude that's is just call a function without instantiate a class and this cost less, but introduces a problem. Every function that is a event must receive a (socket, buffer) parameters, in a large codebase can lead to a painful maintenance.There will be an explicit error on system design if you choose this path, that are: multiple calls can lead to a "overloading" of data, (I'm not mentioning methods). In general terms, the data stored on a static var can simple be suppressed/substituted causing and error on how the program handles that specif event. So, there's a necessity to instantiate a new object for every income request. Not much performative but we can count with the GC.

This links to a OOP implementation

Imperative

The problem is between the chair and the keyboard. Easy maintenance, hard to discipline yourself to not construct a outdated codebase. On that case, the process of maintain the codebase become such a painful disaster. So, unit and integration tests is a must have.

Functional

On other hand, despite the fact that is somewhat is something like, the problem of chair-keyboard turns nullish. In contrast we will need to use such tools like Flow and linters to maintain the integrity of the code.

The problem of maintence become less painfull due to the fact that we have types. One change can break a lot of things but we know why.

The cost of this way is what we can call 'functional price', more memory usage due to multiples compositions or more functions declarations,
flow-types parser and etc. In general, a program written is pure functional style is expected to cost more than a program on a imperative style, but introduces such benefits that this all can be reconsidered.

On connections tests can't get the disconnect event

On the connections tests is not possible to handle the disconnect event provided by socket.io to verify the integrity of the application against malformed requests, tokens or expired tokens.