Decide on technical approach for interim state content management

[patrickvinograd]

The scope of the "health apartment" work is to migrate the user-facing health features of MHV to VA.gov, by re-implementing frontend applications and migrating content into the VA.gov React stack and CMS, respectively.

(Health features such as prescription refill, secure messaging, health records) (Currently, MHV uses a Liferay Portal as both an application server and a CMS)

This poses two challenges for content management:

Problem 1 - Dual State Health features will be migrated over time and may be subject to a phased roll-out. This means that there will be an interval where health content is appearing on both VA.gov and MHV. Ideally, MHV's content managers would be able to manage the content in one place and have it appear on both sites, and given that the end state is to use VA.gov's CMS, it would be nice to shift to managing the content there.

Key Question: Can MHV access content from the VA.gov CMS, presumably via a content API?

Acknowledging that this is a temporary problem, and if the answer is "no" or "yes but with a lot of work", then it may be acceptable to manage content in two places for this interval.

Problem 2 - Content in Dynamic Apps The MHV team tries to avoid having developers involved in updating content. But, content still needs to appear embedded within dynamic applications. So it seems like that team has implemented an approach where they can pull in CMS-managed content snippets into an application.

As discussed in this thread: https://dsva.slack.com/archives/C5HP4GN3F/p1645576983446129 VA.gov's CMS/frontend architecture doesn't yet allow for this. CMS content is rendered as full pages via the content build; React applications render themselves; and there is no API for a React application to fetch content dynamically, so a content change within a React app requires a vets-website pull request (typically by a developer).

Key Questions:

• Is it feasible to expose a content API that React applications could easily consume to pull in content dynamically?
• What is the extent of the use case - how much does MHV rely on this pattern, and how many of the migrated health apartment feature designs require this level of dynamicism?

[mchelen-gov]

Yup this is pretty much the long standing issue with VA.gov frontend and content management. Pages are usually static, built using data from CMS and rendered to HTML through Metalsmith and Liquid templates. Or they are React apps and their content is hardcoded into the JS. Widgets do allow embedding of React apps within static pages, though data cannot easily be passed between them.

Here is a the discovery done into how current content build system works.

CMS data is accessible through a GraphQL API, however it is not publicly exposed.

[patrickvinograd]

Discovery about public content API: https://vfs.atlassian.net/wiki/spaces/PCMS/pages/2064416886/CAPI+AWS+API+Gateway+POC+Finding

[patrickvinograd]

Summary from that above-linked Slack thread:

• Drupal has a content api, but it has too many endpoints to easily surface via any available API gateway, so it's only available internally.
• CMS team is considering filtering down the number of endpoints exposed publicly to meet specific use cases, but that work is not on their immediate priority list.
• API gateway is desirable to do API gateway-type things like access control/rate limiting/etc.
• Perhaps the bigger-picture concern is that right now, the CMS is not a runtime dependency of VA.gov - if CMS goes down it prevents builds from happening, but the currently-published site still functions. As soon as content is being pulled dynamically from a content API, the CMS does need to be always-available, with resulting changes to team staffing, on call, monitoring, etc. that goes with that.

So while we could consider doing a short-term fix for the MHV health apartment work (e.g. something like proxying selected content API endpoints through vets-api), we'd still be introducing that runtime dependency so it's not something we can just go do without the CMS team's assent.

One other note, the MHV team does have expertise and resources with AWS API gateways and offered there support if that is ever a limiting factor.