Alternative banners: POC for a mechanism that does not rely on content-build

[jilladams]

Description

Implementation notes

Initial scope: target VAMC banners / situation updates. If this works, we can expand later.

Vets-api: Build a new model, new endpoint. We will pull banner content from Drupal via GraphQL (hopefully) Drupal: if GraphQL pull doesn't work, we may need to think about a means of pushing content out to vets-api. vets-website: Build a static widget that gets loaded on all VAMC pages, that will query the new vets-api endpoint to get the status of VAMC banner content

This is basically an end-run around content-build that allows Drupal content to make it to the Front-end via alternative means.

We want to do a very small prototype, to prove it will work. If it does, the endpoint will need to get operationalized properly, which may mean Collab Cycle, security review, and will definitely mean monitoring, etc etc.

If the POC works, we can figure out the FE pieces, as soon as we have a mock endpoint.

Acceptance criteria

• [x] Work out if a new vets-api endpoint will be able to grab Drupal data via graphQL
• [x] Identify next steps to further the concept if not

[jilladams]

Some notes / ideas that came up on scrum today:

• @dsasser isn't sure vets-api will be able to access GraphQL anymore
• The deploy sheild for the CMS may mean GraphQL isn't live during deploys
• If we end up needing a datastore, we did something like that for Income LImits, so there's an example we can reference. Daniel built that.
• @eselkin If vets-api can't pull, maybe we could add a Drupal migration-push sort of functionality that anytime a VAMC banner publishes, it pushes to a datastore somewhere. We do something like this today with VAMC Health Services where anytime they publish, they get pushed to Lighthouse. (@omahane is a SME for this sort of treatment.)

[dsasser]

• @dsasser isn't sure vets-api will be able to access GraphQL anymore

What I mean by this:

There is no paradigm, and potentially no network pathway, from client browser -> vets-api -> cms graphql (no live data querying of the CMS is currently possible, but AP is/was working on this for their live server setup, but I'm not sure where they ended up with that). What does work is having a vets-api Sidekiq job (cron-like script runner for. Rails) scheduled to pull data from graphql -> vets-api -> postgres. This is the same format used by the VA Forms application in vets-api.

This means we can decouple the process completely from content-bulid, and instead utilize a similar archtecture that many of the existing vets-api applications use.

[SnowboardTechie]

@dsasser I can't imagine any alternatives to working with this existing pattern that would play out better. Taking a peek at https://github.com/department-of-veterans-affairs/vets-api/blob/master/docs/setup/va_forms.md and having this template will definitely make things go smoother/faster.

[SnowboardTechie]

@jilladams given we have VA Forms to work with as a POC here I'm not sure there is much value in testing with a new endpoint as we have a live test for our flow working today. Is there any more details or tickets we can provide to help plan the implementation here?

[SnowboardTechie]

@Agile6MSkinner ^^^ for your 👀

[jilladams]

Amazing! @SnowboardTechie I think it would help if you wouldn't mind bulleting out the tasks, as you understand them, to get this done? That can serve as a high level story mapping for Michael to help queue up the work to refine / schedule into sprints.

[SnowboardTechie]

@Agile6MSkinner this should cover the high-level story mapping for this work. If you have any questions or need any more details for the stories LMK

1. Create FFF (Flipper Feature Flag) to build behind
2. Introduce the FE banner for FFF (with this being behind the flag, we can start with static content)
3. Create Sidekiq job to utilize cron cadences for syncing data from GraphQL to the vets-api PSQL DB (probably the most complex piece, however it can be accomplished independent to steps 1/2)
4. Create the vets-api endpoint to read data from the DB and provide that to the FE banner introduced in step 2 (this requires all other steps completed)

[jilladams]

@SnowboardTechie thank you! For the sake of rough cut planning, do you have a sense of the effort prob required for those steps?

re: Step 2: If we start with static content, rather than doing this step last, we'll need a 5th step to update the FE build to use the new API endpoint, yes? As far as effort: Banner build will mimic the style presentation of the existing banners, so we can maybe reuse some/most markup.

[SnowboardTechie]

After discussing with teammates we have an updated POC

1. Create FFF (Flipper Feature Flag) to build behind (Est: 1)
2. Build the VAMC Banner with Situation Updates behind the FE banner for FFF (with this being behind the flag, we can start with static content) (Est: 2) -- this is porting the existing implementation to live behind a flipper with a new backend.
3. Create App/Module for the banner interactions/checks including initial DB models for storing and retrieving necessary data from the pSQL DB (Est: 3)
4. Create script that will communicate with GraphQL to fetch the alert banner data and update the pSQL DB(Est: 3)
5. Create Sidekiq job to utilize cron cadences to run the script in step 4 every 10 minutes, include Datadog monitor that will alert slack when cron jobs don't complete as expected(Est: 5)
6. Create the vets-api endpoint to utilize the app/module from step 3 and read data from the DB providing that to the FE banner introduced in step 2 (this requires all other steps completed) (Est: 2)

1 needs to be done first, but 2-4 can be done in tandem, 5-6 need to be completed last but can be done in tandem as well.

@jilladams with doing the static content in step 2 we would be connecting the FE when creating the vets-api endpoint in step 6. I believe it works smoothly this way as step 6 turns into connecting the pieces created from all the previous steps. We could attempt combining step 2 with 6 at the end, but that leads to less we can do in parallel.

[jilladams]

Ok rad. Just noting for planning purposes that #6 is both a FE + Ruby task, and that means it's well suited to Daniel or Bryan, and I think Eli?, but Randi / Chris / Jerry may need some support to handle both, or would need the ticket split, tbd refining it.

[SnowboardTechie]

@jilladams great callout, though I will say the Ruby side of this should be light and could be a good chance to pair up and use this as a learning opportunity with Randi, Chris or Jerry if they take this. We would be writing a little bit of Rails in the controller and routes, but would get to walk through what was built and how it functions during the process leading to a full stack exp. Consider this me volunteering to lead a pairing session if desired when these are assigned.

[jilladams]

Reminder to myself cuz I keep forgetting, and anyone else who has been thinking about Full Width Banners: this POC is not for full-width banners first, but for VAMC banners with situation updates. They are similar, but different.

• Live VAMC banner with situation update: https://prod.cms.va.gov/va-north-floridasouth-georgia-health-care/vamc-banner-alert/2024-10-08/hurricane-milton-operational-status-update-for-nfsgvhs
• Example where it appears on the FE: https://www.va.gov/north-florida-health-care/ - by default, the situation update appears on any VAMC system page, for the System checked on the VAMCBwSU (?) node

These ride along with the header: