Developer Research Spike: 526ez Pull Disability list from LIghthouse API (41302)

[austinjprice]

Acceptance Criteria:

• Attach research notes/design approach for changes required to vets-api
• Attach research notes/design approach for changes required to vets-website
• Update the Acceptance Criteria in 526ez | Pull disability list from Lighthouse API #41302

Time-box: 12 hrs per doc (raise if we are approaching limit or think we will)

[NB28VT]

Front End next steps: make time to share findings with someone in bdex-engineers Slack from team 1. Re: how do you think we should plan to approach this?

[SamStuckey]

I accidentally dropped this comment in the wrong ticket. This is a summary of my initial findings pre-ticketing, for posterity.

---

Additional context from my initial research indicates that whoever focuses on the backend of this ticket will need to answer two primary questions:

What is our performance need / availability requirement for this data via that API? This will inform whether or not we decide to cache this data at the application level (likely), or allow for a read through to the lighthouse API. Caching will present the issue of cache breaking to consider, while non-caching will make our API dependent on lighthouse uptime and the appropriate query route being exposed by lighthouse, e.g. do they have a 'fuzzy' match api we can use? This will also depend on the FE use cases captured by the FE researcher here.
What is our current solution for interacting with Lighthouse via the API? In other words, how big of a lift will it be to plug our API into a new route (and potentially a cache busting webhook). Is there an auth pattern to follow? A Lighthouse API wrapper object, etc... To answer this question, research existing API to lighthouse requests.

Existing answers:

1. yes we want some version of caching at the application (API) level
2. yes, we want to support fuzzy search from the front end

[sortizsh]

@tblackwe can you go in and add tasks

• Add 2 tasks to 59815:
• Understand existing lighthouse api and caching
• Serve data to the endpoints Nathan is discovering

[micahaspyr]

It's been tough getting clarity into the workings of Lighthouse, so we'll just treat it as a black box. Because the Lighthouse API endpoint lacks fuzzy searching, we'll just need to search upon the data received on the backend via the ruby controller code. The best way forward is to just cache the list of disabilities, then do some text searching on the values returned by lighthouse. The data needing to be returned looks to just be the "name" and "id" of each pair. Name being the name of the ailment, and id maps to the "code" of a disability. We can just return an array of json values for the frontend end to consume.

The research has brought to my attention that all data from the benefits reference endpoints can be cached. This isn't necessarily in the purview of this ticket but perhaps something to look at later.

Actions

• Update the BenefitsDataController or create a new or separate controller to handle this call
• Collab on how the frontend/ @NB28VT wants the data to be structured. Briefly looking at the frontend React components being used it appears that sending the name of the disability and it's contention 'id' aka 'code' is all that's needed
• Make sure this doesn't clash with other work being done referencing the BenefitsDataController and the BenefitsData services attached to making the Lighthouse API call.
  • If the service (what acts as the data fetcher) isn't being updated by other teams, we can just use a separate controller.
  • OR we can skip using the service to decouple from future changes
    Backend areas to touch
  • Create a request test spec. Test needs to be cognizant of the request being cached. Using VCR to test this doesn't encompass what is needed as VCR cassettes are basically just cached api responses, so we'll need to figure out what to do in this instance
• Looking into the config files, it appears that redis cache is statically set to expire every 30 minutes but the amount of time can be customized per usage. I don't see why we would need to change this since the list hasn't changed in over 3.5 years

[NB28VT]

Quick Update, just got a great high level overview from Christine on what docs I need to read to map out the front end for this fix:

Current Goals

• Understand patterns for retrieving API data in the front end
• Understand how to work with the Redux store
• Understand how I would write a unit test for this
• Understand how if at all I would tweak the 526 form e2e cypress tests for this
• Understand how our form library works
• Map out what I would change where when we actually implement this new endpoint

TODO:

• Refresher on Redux, which I haven't used in a few years and even then, it was set up in an unconventional way
• Review the VA Forms Library documentation
• Review our front end unit testing setup docs

[NB28VT]

Nathan: note to self move this ticket to the "done" column once you've unblocked work on the ticket this blocks

[austinjprice]

@NB28VT @micahaspyr @tblackwe @RakshindaAslam @lydiahooper moving to icebox as this is blocked based on feedback from TRex and Shannon Ford. Meeting with team 1, 3pm est and we can determine next steps to unbock or if this needs to go back to backlog