When an assignment is created on the schedule, a suggested time entry is created for each day in the assignment. The budget graphs in the sidebar are based on data from a reports endpoint that calculates future scheduled and budget. These graphs rely on the suggestions being fully created before calculations will be accurate. So, at what point can we know with certainty that the requisite data has been created before attempting to re-render the graphs?
Cost scale: 1-5. 1=low, 5=high
Overview: When an assignment is created, determine the number of expected time entries to be created. Then poll the assignments show endpoint (e.g., /api/v1/projects/1234?with_suggestions=true). When the number of suggestions matches the expected, re-render the graphs.
Pros:
- Relatively straighforward to implement
- Could potentially reuse some of reports polling code (or at least its approach)
Cons:
- May need to lock UI, otherwise, we risk expected time entries being off if the assignment start or end dates are altered
Cost: 2
Overview: After page load, get all data needed to calculate the effect of an assignment creation, deletion, or edit on the future scheduled and budget calculations (bill rates, holidays, availability).
Pros:
- We don't need to ask the server when we're done, we can know reliably through the front end
Cons:
- Represents a significant departure from our current approach to data calculation
- Significant data dependency (adds complexity and has performance implications)
- Risks calculation being different from reports (also a risk with current implementation)
- Porting over calculations from current front end will require a great deal of massaging and refactoring
- Manual porting over of calculations risks missing special cases hidden in legacy code
Cost: 3.5-4
Overview: On page load, open a websocket connection. When an assignment is created, suggested time entries are generated like they are today. When the creation is complete, the server pushes a websocket notification to the client, which responds by re-rendering the graphs.
Pros:
- Adds sophistication to the product
- Most elegant of the solutions presented here
- Addition of websockets could enable us to use them elsewhere, such as the schedule (keeping the schedule in sync between viewers in an org in real time)
Cons:
- Rails 5 dependency
- Introduces new protocol and new technologies
- Potentially creates an infrastructure requirement (bigger server, or dedicated node)
Cost: Uknown (estimated 3)
Overview: On the creation of an assignment, a special flag is passed to the server to tell it not to delay the creation of suggested time entries. It creates them and returns as normal.
Pros:
- Most straightforward to implement
- Long running requests may be mitigated by segregated queue
Cons:
- May have to introduce a cap on assignment length
- Risks hitting request timeout for a sufficiently long assignment (liklihood unknown)
- Risks resulting in request queuing with potentially hundreds of simultaneous long-running requests
- May result in infrastructure overhead (beefing up delayed jobs server or re-jiggering the workers or both)
Cost: 1
Overview: Queue the delayed job for the creation of suggetions when an assignment is created. Queue another delayed job that checks the status of the other delayed job and re-queues itself until the other job is finished. A custom REST endpoint can be given params to check the status of the overseer job. The front end polls that endpoint, and when it returns success, re-renders the graphs.
Pros:
- Approach has already been used by Kristen on bulk import
- Heavy lifting is done by delayed job library
Cons:
- Implements polling on both client and server (potentially risky)
- Custom endpoints break REST conventions
Cost: 2