Versions Compared

Old Version 2

changes.mady.by.user Viacheslav Kolesnyk

Saved on

compared with

New Version 3

changes.mady.by.user Viacheslav Kolesnyk

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...



Pub-sub between mod-users and mod-kb-ebsco-javaBulk api for users in mod-users
Query data every time it's neededimplement scheduler to periodically update assigned users data
Advantages

Most preferable way for data consistency achievement.

Good performance for UX.

No need to store duplicate data and worry for data consistency.

Ensures data consistency.

Good performance for UX.

DisadvantagesWill cause a lot of "dummy" network traffic and unnecessary component load because kb-ebsco needs info only about certain users not all.Worst user-experience cause we need query data from multiple sources to display assigned users info so this will cause delays for data displaying.

Wasted processor time in most cases and delays in data consistency depending on scheduler rate.

Also unnecessary api calls in cases data is already consistent.

Potentially can cause big performance issues as database grows.

Developers effort to implement

Almost no changes to current code.

Add producer on mod-users on data changes and consumer for mod-kb-ebsco  to updated data based on notifications.

Rework database structure in mod-kb-ebsco (remove user-related info) to store only kb-id to user-id relations and update user assignment flow.

Implement bulk api in mod-users.

Add bulk api call to mod-kb-ebsco user assignment flow.

Implement bulk api in mod-users.

Add bulk api call to mod-kb-ebsco scheduler or implement api and let okapi run it periodically to update data.

Conclusion:

Pub-sub looks like the most acceptable way to achieve data consistency for users assigned to kb credentials in It was decided to remove user data from mod-kb-ebsco  .Also it was discussed that it not necessary to display patron group for assigned users so we can simplify user assignment by removing Patron group .and query user-related info every time it is needed. Bulk api is not needed because users can be queried using cql.

To be implemented:

NoteWork to be doneSideStory
Do anytime

Remove call to "/groups" api (i suppose it's even not used now)

Note: actually this is not a part of this spike, just wonder whether this api call is dummy. If so - it should be removed, but spike can be completed without this.

front-end
Do first

Rework "GET /kb-credentials/{kb-credentials-id}/users" api:

  • get assigned users from db (only user ids by kb_credentials_id)
  • query users info from `mod-users` for assigned users using "/users" api and cql (Check the max possible amount of users we can query this way and implement batches so if for example we have 200 assigned users in db and the limit is 50 then we should execute 4 queries with 50 users each and compose results then)
  • query groups info using "/groups" api of  `mod-users`
  • aggregate received info and pass as response
back-end/mod-kb-ebsco
Do together

Update "POST /eholdings/kb-credentials/{kb-credentials-id}/users":

  • remove "firstName", "lastName", "patronGroup", "userName" from api
  • update repository interaction (save only kb_id to user_id relation)
back-end/mod-kb-ebsco

Update call to "POST /eholdings/kb-credentials/{kb-credentials-id}/users":

  • remove "firstName", "lastName", "patronGroup", "userName" from request body
  • also do not depend on this fields in response
front-end
Do last

Schema updates:

  • remove `kb_users` table from db
  • update `assigned_users` constraint(user id is a foreign key now, but users table will be removed)

Code updates:

  • remove unused repository
  • update repository for new schema
  • remove other unused code related to user data
back-end/mod-kb-ebsco