Authority API Moving

Overview

The main goal of this document is to provide the benefits of moving the Authority API from the mod-inventory-storage module to the mod-entities-links.

NFRs:

1. Data integrity: Centralized storage for authority data should remove possible inconsistencies between microservices.
2. Maintainability: Implementation of features related to handling and managing authorities should not require overhead on crosschecking between mod-inventory-storage and mod-entities-links.
3. Performance: Removal of HTTP requests and Kafka interaction overhead should improve the performance of linking and import.

Baseline Architecture

Interactions between the mod-entities-links and mod-inventory-storage modules:

1. Event Consumption: The mod-entities-links module consumes events from the mod-inventory-storage module when authority records are updated or deleted. This ensures that the links stay synchronized with any changes happening in the inventory module.

2. Statistical Authority Data Storage: The mod-entities-links module stores statistical authority data by partially copying certain fields that are used for linking, link creating/updating, and automating linking. So module will maintain an almost full copy of the inventory database when most authorities are being linked.

3. Integration with mod-search: The mod-entities-links module makes calls to the mod-search module to retrieve authority data for suggesting links in the automate linking feature. 

Target Architecture

1. Required

1. Rename mod-entities-links to mod-authority-manager.
2. Fully move Authority API, Authority Note Types API, and Authority Source Files API from mod-entities-links to mod-authority-manager. This API provides just CRUD operations and does not have any business logic.
3. Move authority reindex API.
4. Adjust mod-authority-manager to use an internal database instead of interacting with mod-inventory-storage and mod-search.
5. Disable the above APIs in mod-inventory-storage and remove APIs implementation and enable it in mod-authority-manager. The dependent UI and BE modules will not experience any differences.
6. Create a migration script for existing authorities.

Estimation

2. Optional/Future

1. Consume data-import authority events to increase the performance of authority data-import flow. (8 SPs)
2. Simplify authority stats generating
3. Move mapping rules

Benefits

Moving the Authority API from the mod-inventory-storage module to the mod-entities-links module can bring several benefits, particularly in terms of reducing dependencies, minimizing interactions, and eliminating duplication of authorities. Here are some arguments to support this movement:

1. Dependency Reduction: By moving the Authority API to the mod-entities-links module, the number of dependencies required by the mod-inventory-storage module can be reduced. This streamlining of dependencies can lead to a more modular and efficient architecture.

2. Minimizing Interactions: Currently, mod-entities-links and mod-inventory-storage modules may have significant interactions related to authorities. This can result in increased complexity and potential performance bottlenecks. By consolidating the Authority API within the mod-entities-links module, the number of interactions between the modules can be minimized, leading to improved performance and better code maintenance.

3. Eliminating Duplication: Having authorities stored in both the mod-entities-links and mod-inventory-storage databases can lead to data redundancy and potential synchronization issues. Merging the Authority API into the mod-entities-links module allows for a single source of truth for authority-related data. This eliminates the need for duplicating authorities and ensures data consistency across the system.

4. Simplified Development and Maintenance: Moving the Authority API to the mod-entities-links module can simplify the development and maintenance process. Developers will have a clearer understanding of where to find and update authority-related functionality, leading to improved code maintainability and reduced development efforts.

5. Improved Scalability and Extensibility: With a more streamlined architecture and reduced dependencies, the mod-entities-links module can become more scalable and extensible. The separation of concerns and elimination of duplication allows for easier integration of new features and enhancements, facilitating future system growth.

6. Enhanced Data Integrity: By centralizing authority-related operations within the mod-entities-links module, stricter data integrity checks and validations can be enforced. This ensures that authority data remains consistent and accurate throughout the system.

7. New functionality: Moving the Authority API from the mod-inventory-storage module to the mod-entities-links module will enable effective management of links and provide new capabilities, such as generating blind authority reports and creating a facet in the MARC Authority app for linked and not-linked authorities. 
8. Timeliness: It is essential to initiate the migration of the Authority API now, before further authority functionality is implemented. As the system evolves, introducing more features and functionalities can lead to increased complexity and potential conflicts. By moving the Authority API at this stage, you can establish a solid foundation and ensure that future authority-related functionalities align with the consolidated approach. This proactive approach saves time and effort by avoiding potential rework and mitigating compatibility issues in the future.

Overall, moving the Authority API from the mod-inventory-storage module to the mod-entities-links module offers the advantages of reduced dependencies, minimized interactions, elimination of duplication, simplified development and maintenance, improved scalability, and enhanced data integrity. These benefits contribute to a more efficient, maintainable, and robust system architecture. 

Open questions:

1. How to handle permissions?

Questions for POs