3 ms·

I'm not a JS programmer so the intended "simultaneous" waits only vaguely registered as possibly problematic. However, after reading the article it is, at wors

I'm not a JS programmer so the intended "simultaneous" waits only vaguely registered as possibly problematic. However, after reading the article it is, at worst, a performance problem. ...and performance should come after the code is correct and I don't think the code is even semantically correct in the first place. I'm assuming that "members" and "non-members" are distinct subsets of all People. i.e. it's not possible to be in the "members" and "non-members" sets at the same time. Additionally, everyone is in one or the other. Because the set membership is queried with 2 independent queries (designed in a reasonable and common RESTful manner) there is a race condition where an object (that changes in the time between the two calls) might appear in neither or both of the sets. These results are then blindly concatenated together. If the API wants to retain its RESTful design, it must include metadata about the consistency between calls. For example some kind of token that can be compared to check that the replies to the two queries represent a consistent view of the data. If the tokens, differ, the "transaction" can be retried. Alternatively, the API can be designed, possibly making it less RESTful in the process, so that the transaction is implemented on the server. There are many other ways to guarantee a correct and consistent result. Either change has big enough implications that optimising for performance at this stage would be premature because of the amount of refactoring necessary to implement `getPeople` in a way that provides consistent and correct semantics.

brundolf 6y ago
You make a valid point, which I probably should have mentioned, that this doesn't apply for stateful calls. But in my experience it's a common use-case (at least on the front-end) to grab two or more independent datasets, from stateless endpoints, at the same time, for display purposes. And putting those into a sequence can have a dramatic impact on perceived performance. I don't think a performance factor of 2x or more is a micro-optimization that one should hold off on making until a later pass.

brundolf 6y ago

You make a valid point, which I probably should have mentioned, that this doesn't apply for stateful calls. But in my experience it's a common use-case (at least on the front-end) to grab two or more independent datasets, from stateless endpoints, at the same time, for display purposes. And putting those into a sequence can have a dramatic impact on perceived performance. I don't think a performance factor of 2x or more is a micro-optimization that one should hold off on making until a later pass.