3 ms·
> Those interactions are held in the queue only as long as the server needs before dequeuing. How sure are you that this invariant holds? Under what conditions
by agentultra 10y ago
> Those interactions are held in the queue only as long as the server needs before dequeuing.
How sure are you that this invariant holds? Under what conditions do you expect it to fail?
Clearly this is a fairly new project. 148 commits. No tests, benchmarks, or specifications.
Keep at it. :)
- tron1k 10y agoThanks for the feedback and support! We have added unit tests this morning and will continue to add more. Also, we have been using Artillery.io for load testing to measure the performance gains from multiple Node workers and the linked-list messaging queue.
- mxvzr 10y agoI too think this is a bit premature, especially when I see placeholder code like this [1]. I'd also mention the redis dependency somewhere, IMO I shouldn't have to go all the way here [2] to find about it. Somewhat less important feedback: - I want my libraries to be quiet; currently there is a lot going out to stdout. I see you already depend on debug, why not use it some more? (somewhat related: are the emojis really necessary?) - IMO libraries shouldn't listen for uncaughtException. Libraries don't have enough context, or even the guarantee these errors belong to said library. - require all your deps at the top; I'd like to pay that cost upfront when I start the process rather than after calling a function, potentially in the middle of doing something. - only use backticks if you are actually doing variable interpolation. [1] https://github.com/team-emt/razorframe/blob/master/lib/Razorframe.js#L224-L238 https://github.com/team-emt/razorframe/blob/master/lib/Razor... [2] https://github.com/team-emt/razorframe/blob/master/lib/Razorframe.js#L8-L10 https://github.com/team-emt/razorframe/blob/master/lib/Razor...