Update Vets-API Facilities API to use Lighthouse v1 (Phase 1)

[xiongjaneg]

Description

The Facilities team is currently responsible for maintaining Vets API which is used by the Facility Locator and by other teams in the VA.gov ecosystem (such as VA Online Scheduling). To enable v1 in the Facility Locator and for us by other teams, we need to update Vets API.

This is Phase 1 of 3.

• Phase 2 will convert the Facility Locator to use Facility API v1 with existing functionality. (Facility Locator uses Lighthouse API v1 with existing functionality (Phase 2) #12907)
• Phase 3 will implement Lighthouse v1 to power the Facility Locator, making it possible to search using the full list of (VA health) services available in CMS (Update Facility Locator to allow plain language search for VA health services via Lighthouse V1 (Phase 3) #14993)

Background

Lighthouse Facilities V1 shipped August 24, 2023 and intends to sunset V0 effective June 1, 2024.

Any Facilities products that use Lighthouse Facilities API V0 will need to be updated to use the V1 API.
This involves:

• Assessment of each product for V0 usage
• Identifying V1 endpoints to be used instead, if not already done
• Ticketing each piece of effort separately, per product, including testing expectations.
• Testing V0 > V1 cutover per product.

Known impacts:

• Facility Locator front-end

V0 sunset

• As of Dec 2023: June 1, 2024 is now estimated V0 EOL date.
  https://trello.com/c/X7RMCnnf/30-facilites-v1-adoption-v0-retirement-timeline

Details in SPIKE: Become familiar with the facility locator data architecture #12990 may be helpful for reference.

V1 documentation

https://developer.va.gov/explore/api/va-facilities/docs?version=current
Release notes: https://developer.va.gov/explore/api/va-facilities/release-notes

Notes from spike ticket #15000

Jan. 6

Currently most apps version themselves via module in vets-api.
e.g. the check_in module has v0,v1,v2. The pieces themselves, such as serializers are in a directory for the module version and the class is defined within a two level module (CheckIn -> V2).

We currently have a v1 only but have not made 2 nested levels of module, we only have the module FacilitiesApi. We identify the class with a namespace of V1, but it's not so cleanly done.

Basically, what this means is we just made it less clear how the modules will be separated. Not a big deal.

We will, in all likelihood, have to make a V2 set of directories, V2 class prefixed components (since we started that way), and expand the routes.rb to differentiate the requests based on version. I say V2 because we already used V1 instead of starting from 0 and matching the lighthouse number.

The hardest thing will be getting the configuration right, since I believe the serializers and that models don't really change in the move to Lighthouse V1, but I'd need some confirmation on that.

We'll probably need to have settings updated if lighthouse v0 and v1 URLs are different, unless they are only different by a path. Not sure if there is a path in the config in production

Jan. 8

Current work in identifying logs with unique referrers:
Logs search in Datadog:
source:vets-api @payload.controller:"FacilitiesApi::V1::VAController" -status:(error OR warn) @http.status_code:200 [email protected]:staging
group by felds
Show count all logs
by Referrer

It looks like there's no Production-specific URL. lib/lighthouse/facilities/configuration.rb references the Lighthouse URL from the settings at config/settings.yml. That file also gets uploaded to Production, not with any environment-specific variables, so the URL would be the same across environments.

It also looks like the version differences are specified after the root of the URL (like in lib/lighthouse/facilities/client.rb:22), reinforcing that they're only different by the path.

Jan. 16

We have a pretty good understanding of the module structure of the API ruby and can update to v2 with v1 Lighthouse without too much difficulty other than the numbers. There's no real way to make a module change except to change the v1 to v2 considering the overall structure of other version changes in the project as a whole. As far as the referrer situation, I'm not sure JS respects the referrer when making direct requests to the API from script. Making a V2 will not impact the V1 users. We should make V2 as soon as possible so that 1010 can start testing with it so when EOL of v0 of lighthouse comes around we can remove access to vets-api v1.

ACs

• Affected teams are directly informed when the work begins.
• Facilities API (vets-api) is updated to integrate Lighthouse V1.
• V0 remains available to maintain services while teams implement V1.
• Create subset from directories and configuration because previous version didn't make it easy to extend upon. It's going to point to V1 of Lighthouse endpoints.
• Copy things over from what's using Lighthouse V0.
• Test the new endpoints.
• Set up monitoring for the new endpoints.
• Change is socialized in Team of Teams and other relevant revenues.
• Changes are fully documented and communicated directly to affected team(s) (1010 PM Heather Justice)

[xiongjaneg]

@xiongjaneg grab details from the Spike ticket, create subset from directories and configuration because previous version didn't make it easy to extend upon. It's going to point to V1 of Lighthouse endpoints. We're copying things over from what's using Lighthouse V0. We have to make sure we're testing and monitoring the new endpoints.

[xiongjaneg]

From Michelle: can we build to future proof for further changes?
From Eli: we may need to follow this same process in the future because duplication may need to be done each time. We can do this in a way that we can sunset V0.

[jilladams]

IIR completed this work under the following epic: https://github.com/department-of-veterans-affairs/va-iir/issues/540