3 ms·

Both the deepstream.io server https://github.com/deepstreamIO/deepstream.io https://github.com/deepstreamIO/deepstream.io And node client https://github.com/

• partycoder 10y ago
  Uses JSDoc, and the code is well structured. But it has lots of statefulness, some of the state is structured as a finite state machines in ways that are easy to break (similar to the "request" module, also a FSM that is incredible easy to break). Function parameters are not validated.
  • gbrits 10y ago
    What do you mean by breaking the fsm? Isn't the whole point of having a fsm to explicitly describe the entire app-state? Honest question
    • partycoder 10y ago
      A state machine has states and transitions. Some transitions are valid, others are not. Therefore when you implement a state machine in code the consequence is sequential coupling. Imagine a car class: You have StartCar(), Accelerate(), Break(), StopCar(), SwitchGear(). Can you accelerate with your car turned off? no. Can you stop your car twice? No. So there should be validations in state transitions. Since in this code those are missing, it's possible to arrive to invalid states that can cause undesired behavior. In the "request" npm module (an ambiguous module name that wastes a lot of my time in a regular basis), you can abort a request that has not started. That causes an exception. It took me a lot of time to find it. It was all because of a broken state machine.
  • deleted 10y ago
    [deleted]