Challenge Overview
Are you new to Topcoder? You may implement this task and submit your solution until the deadline. Reviewers would score it and 2 people with higher scores (not less than minimal) would get the prizes. Learn "How to compete" and read the task below.
Challenge Objectives
Implement a bulk update endpoint for milestones and remove code for cascading updates.
Project Background
Topcoder Project Service is the main backend service of Topcode Connect – the client-facing application of Topcoder. We have a Timeline model, which may have multiple associated Milestone objects. When we add or update one milestone sometimes we have to make cascading updates to other milestones and timeline itself if we change properties like "order", "start/end dates", "duration" and others. Making such implicit cascading updates makes it hard getting updated data client-side. To resolve this, instead of making such implicit cascading updated server-side, we would remove such logic and create an endpoint that could update multiple milestones at one time. So later, the client could do all these cascading updates by itself and submit all the changes to the server-side by calling a single endpoint.
Technology Stack
-
Node.js
-
PostgreSQL
Code access
The work for this challenge has to be done in 1 repository:
- Project Service repo https://github.com/topcoder-platform/tc-project-service branch `feature/bulk-milestone-updates` commit `2fd32ce2d19e9ca22bb7722be738b5e238561013` or later.
- Please, follow the Local Development guide for local setup. (The setup should work good on macOS and Linux, Windows is not currently supported).
- Config for local setup is provided on the forum.
Individual requirements
1) Remove cascading updates
When we add, update or delete one milestone, there is some logic that changes other milestones or timeline. We have to remove all such logic. Below, most places to remove are listed. Please, check carefully, that the necessary code wouldn't be removed, but all the code related to cascading updates is removed. The places below are listed for easier start and understanding, still, check that nothing is missed. If you have some concerns, please, ask on the forum.
- Remove updating "order" of other milestones when a milestone is added, see code
- Remove sending RabbitMQ event after adding milestone, see code
- Remove sending Kafka events for cascading updates after adding milestone, see code
- Remove sending RabbitMQ event (it's already redundant) after deleting milestone, see code
- Remove updating "order" of other milestones when a milestone is updated, see code
- Remove updating other milestones and timeline because of "completionDate", "duration" or "actualStartDate" is updated, see code
- Remove sending RabbitMQ events for cascading updates after updating a milestone, see code
- Instead of sending a message to Kafka using such a custom code with cascading updates, see code, send Kafka message using "util.sendResourceToKafkaBus" as we do in add and delete endpoints.
- Disable listening to RabbigMQ events which we wouldn't send any more: EVENT.ROUTING_KEY.MILESTONE_ADDED and EVENT.ROUTING_KEY.MILESTONE_UPDATED.
- DO NOT remove code in file src/events/milestones/index.js. We want to keep it for now, even though most likely it wouldn't be called anywhere after this challenge.
2) Implement a Milestones Bulk Update Endpoint
Implement a new endpoint `PATCH /v5/timelines/:timelineId(\\d+)/milestones` which would update all milestones of a timeline at once. Implement it in file `src/routes/milestones/bulkUpdate.js`.
-
As a body to this endpoint we should send an array of milestones:
- if a milestone in array doesn't have an "id" it means it's a new milestone which has to be created
- if a milestone in array has an "id" and any of the properties has been updated it means this milestone has to be updated (note, that we have to pass all milestones even if they are not updated so they are not removed)
- if there is an existent milestone in the timeline which is not listed in the array, it means such a milestone has to be deleted
You may check example of how such a bulk request should work in this comment. -
This endpoint should work as a single transaction which means that if at least one operation above fails, then:
- all other operations should be reverted back
- the error should be returned for the whole endpoint -
Each operation like CREATE/UPDATE/DELETE milestones in this endpoint should follow the same logic as individual endpoints to CREATE, UPDATE or DELETE milestones including all the validations, checking permissions for operations or additional logic like this. Avoid code duplication, create a reusable code that can be used in single operation endpoints and in the new bulk operation endpoint. Please, try to keep the logic clear and easy to understand here.
-
For each created, updated or deleted milestone in a successful bulk request we have to send a Kafka message (so "project-processor-es" would get it and update milestones in the ES index accordingly). See how we do it in CREATE or DELETE endpoints. NOTE: These messages should be only sent to Kafka if all the operations are succeeded, as otherwise, we would revert operations and don't send Kafka messages.
-
Implement unit tests.
- While we don't require a particular percentage for unit test coverage we need to implement unit tests to cover all requirements of this challenge where possible: correct detecting of all the operations, reverting back of other operations if one fails, sending Kafka messages only if the whole bulk update success and so on.
- Don't have to repeat detailed unit tests we have for individual endpoints as we have to reuse the same code for most of the logic.
General requirements
-
Update the swagger file accordingly to the changes.
-
Add bulk update endpoint to Postman file.
-
Adjust existing unit tests according to the changes. If you think that some unit test doesn’t have sense anymore after changes, please confirm on the forum before removing.
-
Add JSDoc for new functions.
-
Lint should pass (don’t disable lint rules).
-
All unit tests should pass.
Deployment guide and validation document
Provide a validation document which would describe how to validate bulk update endpoint:- how to create initial data
- how to call bulk update endpoint to see various cases including successful and failed
Final Submission Guidelines
Submit a zip file which would include:
-
git patch with changes you’ve made to the code in our repositories
-
Validation document in any common format: markdown, doc, pdf, html and so on.
Additionally, the winner would be required to raise pull requests to the repositories after the challenge is completed.