Worked with @sydney to design a sensible request queuing system for the frontend. We started out developing using a model where each request that's pending is marked as pending in the state, which led to a lot of complication and replication of boilerplate code in the redux actions and reducers.
We decided to redesign the entire request model so each request is identified by a unique id generated by the requesting component. This id is placed in a section of state when the request is resolved by the backend, so the component can then adopt the new state. This is exactly the sort of model needed to implement the more complicated state-swapping functionality I described earlier in the week, plus it cleans up the actions and reducers nicely.
The idea going into building the alpha was to get something done quickly, but our tendency to overengineer and ensure everything is built as elegantly as possible has resulted in it taking much longer than originally intended. Hopefully this extra time will pay off in the future with fewer bugs and scaling issues.