Add Redis caching to PreferredName / demographics call

wesrowe commented 3 months ago

Blocked: AuthExp team is moving Profile from v2 to v3, this should accomplish most of the work scoped in this ticket. They're planning to deliver by end of July (as of 6/13)

Description

User story

As a Cartography team member, I want the REST client on vets-api to cache calls to the demographics service on the Profile API, so that the service only receives one request per user session regardless of how many pages are viewed.

Notes

The recommendations and policies are captured in
- Notes in the sensitive repo
- The post-mortem (PR here, not sure where final file lives)
There is at least one user/API of the demographics API endpoint. Do we want to have that user/API use the Redis caching as well?
Use the existing calls to test the demographics endpoint. MHV Landing page's personalization uses this endpoint. You can search the codebase for other places this endpoint is used.
Refer to How-to Guide: Caching with Redis-Namespace in Vets API Introduction for more Redis info.

Possible tasks:

figure out Redis caching
meet with Tom Harrison from AuthExp team for alignment
implement Redis caching for the demographics service
test however you can without going to staging or prod (testing will come in next ticket, #79924)
Do we need a feature flag for this caching? It will probably depend on the architecture.
Informed VA Profile team of the addition of the caching before merging, so they know to expect changes to the traffic and can monitor for errors

Acceptance criteria

Informed VA Profile team of the addition of the caching before merging.
The Vets API demographics service uses Redis caching for API requests.
Existing Vets API services that use the demographics service are not affected by the change.

wesrowe commented 4 weeks ago

I'm pretty sure we meant to pull this into the sprint – it wasn't supposed to be in Ready still. Moving to in progress.

dcloud commented 4 weeks ago

Since the preferred name work was reverted per https://github.com/department-of-veterans-affairs/vets-api/pull/16015, I'm looking for things caching-related, but came across some relevant policy code that I will cross-post on the policy ticket:

https://github.com/department-of-veterans-affairs/vets-api/blob/74b1e8551bed8e605a40e5dfcbc91ddb787553e3/app/services/users/profile.rb#L96-L113

dcloud commented 3 weeks ago

Notes from mtg with Tom

Platform work

Platform support team is making changes to VAProfile code to migrate to v3 service to get contact information. This will use the API endpoint where you ask for multiple pieces of information in one call: we should piggyback off that.

It might not make sense to proceed on this ticket if Platform is building essentially the same thing. Rachel Cassity from Platform is likely the point person for the Platform effort: department-of-veterans-affairs/va.gov-team/issues/83187

Epic: department-of-veterans-affairs/va.gov-team/issues/83181

Caching strategy

If we have the V3::ProfileInformation::Service in place, then we can cache that call. We'd probably invalidate the cached data object when one data attribute is changed, such as preffered_name, gender_identity, etc.

We could invalidate per data attribute, but we'd need additional code to manager per-attribute caching, changing the API call, etc., and we think the added complexity is not worthwhile.

Ideally caching and invalidation would be handled at the service level, so the VAProfileService would handle that logic for calling code

Next Steps

Tom to set a meeting with Rachel to discuss V3::ProfileInformation::Service implementation, time. Daniel will attend
Daniel to check on timelines for team work, see if we can align with the planned Platform work

Links

https://qa.vaprofile.va.gov:7005/profile-service/swagger-ui/index.html?urls.primaryName=ProfileServiceV3#/Profile-v3 (must be on VA network)
https://github.com/department-of-veterans-affairs/va.gov-team-sensitive/blob/master/products/identity-personalization/profile/military_info/backend_documentation.md (see bioPath code example)

wesrowe commented 3 weeks ago

Refinement 6/12: Daniel and Tom to get clarity on timeline in the next couple days.

dcloud commented 3 weeks ago

Per Tom H., the platform product team is doing prep work for department-of-veterans-affairs/va.gov-team/issues/83181 in this sprint, and have the upgrade work scheduled

dcloud commented 2 weeks ago

It looks like https://github.com/department-of-veterans-affairs/va.gov-team/issues/83186 was moved into the current sprint today

department-of-veterans-affairs / va.gov-team