Design of the reactive skeleton

[cawak]

We need to have additional meetings where we should decide how our application is going to look and behave.

What we should consider:

1. It should be modular both the client such as messengers, sockjs, REST calls etc. and the attached resources such as data bases, various messengers etc.
2. We need to consider to have a kind of a broker / scheduler that will ease us the event batching. This will ease us with the subscription policy.
3. We should have a design for the sessions (both local and global) and have an agreement on that.
4. _____FEEL FREE TO ADD ANYTHING OR MODIFY THE EXISTING____

[cawak]

As for section 2, I think it's worth to read chapter 6 (at least that's what I understood from it's title). Because it deals with pipe flows.

[AlexGr2]

I think we should consider to go with some "hybrid" lean development, divided to stages and divert each stage at the end of the previous. We need to discuss core minimum functionality and have at least three simple diagrams: Use case, sequential and Architecture. It can give as proper meaning and direction to future developing. We need to decide and write it up together. Here is my five cents :

Suggested technical review of program components

Client sends event types to spooler, spooler knows to identify event type, pass control of pipe creation to event and send it to broker. Broker configured to create batches of events in size user choose (it can be time - every 5 seconds, size- 100 events or manually triggered by system on event broadcast - 'give-more-events') broker executes events in batches by RXmerging all event's types and subscribing to them Observer . Observer analyzes, processes pipes results and responsible for event broadcasting (something-went-wrong, all-good, sockets-closed, give-priority-to-socket-in-queue) Events create pipe, pipe have stages, each stage consist actions. Action is the smallest piece of the program, while Event is the biggest. If "subscribe" is an Event, it creates pipe with different stages by RXconcat different "actions" Stage can be made of one or more actions. Lets say saving-stage is made of action to save a socket to global cache and session cache previously checking existing entries to illuminate duplicates (silly thing to do - just for example) on and on. different stages can hold-on or cut pipe in the half in the case Observer have emitted interrupted event (since each stage bind to listed to different broadcast we can emit different action or concat a different stage). Created pipes by events bounded by "concating" different stages, "RXmerged" and "subscribed" by broker and monitored by Observer. Why Observer? Because running pipes are stateless we need something like a "big brother" to be responsible adult in the system if something went wrong or to have more processing engines.

I think in the first stage we should put effort on simplicity and modularity of the system.

WDYT?