Skip to end of banner
Go to start of banner

Remote storage integration implementation options

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

  1. Call the accession method from the UI.

Pros:

  • UI have all the necessary data
  • UI still needs to show the popup, so the business logic for getting this info will be still on UI. The last remaining action would be to make one call to remote-storage module.
  • It will be better for performance because in such case server won't need to verify, that the location is remote on every save action and then call another service if it has remote flag.

Cons:

  • Usually such business logic is supposed to be on server side

      2. Initiate the accession from inventory by making a request to remote-storage module
Pros:

  • Not so complicated
  • The action is initiated by server

Cons:

  • Will affect performance of Inventory
  • Adding partly related business logic to inventory will make the code more complicated
  • There will be still logic on UI about showing the message. So comparing with 1. option, the logic will be kind of duplicated on server and UI


       3.  Inventory will send Kafka messages to the topic with ids of changed items/holdings along with the attributes, which are changed.
Remote-storage module will subscribe to these notifications and check if the location was changed to the remote one. For this checking it will need to go to database (or cache this info for some reasonable time or use some cache eviction policy).
Pros:

  • No remote-storage related business logic in Inventory
  • It could be the common mechanism, as the same Kafka topic cab be used for search (but worth mentioning, that search won't need the changed attributes info)
  • Event-sourcing from inventory provide decoupling of services and could be beneficial in many future use cases


Cons:

  • Really more complicated than other options
  • Location information caching policy is not clear
  • There will be still logic on UI about showing the message. So comparing with 1. option, the logic will be kind of duplicated on server and UI


 4. Use database triggers as @Tod Olson suggested in the doc to add the item to the queue, if the location is changed to remote.
Pros:

  • Extremely simple

Cons:

  • Accession by button cannot be implemented in such case
  • Business logic in the database
  • Completely different approach will be for Caisoft
  • No labels