Project-less headless sites

[xjensen]

First, some background.

In the coming months, we'll need to migrate drought.ca.gov into CDT's stewardship. However, CDT is weary of adopting our current architecture, where each site exists within its own git repo, and every site is configured a bit differently. They have elected to roll their own architecture for Drought within their overall CAWeb project.

If CDT would like to entertain the idea, there's an opportunity here to create a new static site build tool that addresses CDT's concerns. Here's how that might look.

General requirements

Here are the general requirements based on current understanding.

• The build tool must play nicely with Wordpress VIP.

  Wordpress VIP is CDT's new WP platform. It comes with its own unique features and constraints.

• The build tool must be centralized.

  In other words, no separate git repos for each site. We cannot rely on site-specific repositories that are pre-populated with each site's content and custom templates. Instead, we need the ability to build any WPVIP-hosted site via standardized templates and simple configurations.

• The build tool must support the Design System.

  All Design System components and layouts should be readily available for use. Site-specific options in the Design System, such as color systems and other tokens, should be configurable per-site.

• The build tool must accommodate special site features (such as Drought's data visualizations).

  With that said, per-site customization overall should be kept to a minimum. We should look for ways to support special features without tying them to a specific site configuration, if possible.

• We want to maintain and promote ODI's aggressive site performance metrics and standards.

  It's all for naught if we're not improving UX for all Californians.

Proposed workflow

1. User publishes updated content on WP VIP.

2. This publishing action triggers the proposed build tool. The current assumption is that this would be based on the 11ty static site generator. This could run within WP VIP's internal Node.js environments, or externally on AWS or Azure.

3. The build tool depends upon standard templates and styles, mostly from the Design System. Simple configurations are added for each site.

4. Based on configuration, the build tool fetches content and media from WP APIs for the correct site. Content will not be stored in a repo; it's fetched fresh for every build or development session.

5. After fetching the content, 11ty builds the site.

6. Upon building the site, the tool uploads files for hosting and delivery. These files could be hosted within a WP VIP Node.js environment for hosting static files, or externally for delivery via a CDN such as AWS Cloudfront.

[chachasikes]

@xjensen Confirm that media assets are supported on WPVIP (or, if not, how media can be accepted)

[xjensen]

@chachasikes Yes, media is supported. There are a few interfaces for pulling media (REST API, Photon API), and pushing media (VIP-CLI tool, VIP File System PHP library). We should be able to figure it out. It's just different.

One notable thing: JSON is not among the supported media file types. This may be preferred for security reasons, etc. And we could add support via plugin. Just something that might come up.

[chachasikes]

Thanks for the update @xjensen. I was able to extend media types (SVG, JSON & CSV) for content creators with file upload permissions - would be good to formalize that in the new system - especially for datasets that are updated once a year after much manual data gathering.

Slightly related for keeping those assets "findable" over the years: We can also find out what plugins are still supported for organizing the media assets as well. There is a plugin called "Media Categories". There are also some improved UI tools that are also supported - these become necessary as a site may have tons of PDFs mixed in with other assets - and the WordPress media UI is rudimentary.

[rkojik]

Thanks for the exploration ya'll! I didn't realize the site could be generated and stored in Node.js environments... I have a few questions/thoughts:

• I think I knew JavaScript on the back-end server was a thing... I'm just curious why?!? [It breaks my brain a little—the whole purpose of ECMAScript is interoperability across browsers (the DOM and client-side)... maybe because so many people are familiar with the syntax?]
• Is there any inherit benefit of AWS / Azure Blob / Node.js storage over the other?
• I'd have to ask if it's extra $$ on VIP to use the Node.js environment
• I already asked if we have our own storage available (either AWS or Blob)—I'll keep you posted. \
• I'd be curious how the CDN works, since VIP has their own... if we choose to go decoupled, are we responsible for putting back a CDN or can we still hook it up with VIP?

[chachasikes]

@rkojik

re: backend JS

One reason that's very applicable in a federated coding community: using same language for frontend browser AND the backend. As such a common language, it means that more web devs can create utility scripts because JavaScript is a common base language.

Our "functionless server scripts" are just nodeJS scripts, wrapped in an newer technical term that relates to how they are hosted. These scripts can perform work - such as writing to another server, pre-compiling data during a build process/CI (continuous integration) setting, and more.

[xjensen]

@rkojik My understanding of the WP-VIP CDN is that they're using a tool like Varnish to heavily cache all site pages. I believe it's still possible to use this cache if the Node.js app is hosted within WP-VIP. We would need to test it.

Otherwise, it's also possible to go with a fully external CDN like Cloudflare or Cloudfront. The main argument for this approach would probably be price. External CDNs are aggressively cheap. I'm guessing it's cheaper than WP-VIP's bandwidth costs, but I'm not sure by how much.

[zakiya]

I don't know much about WP-VIP (technical documentation on the web is lacking) but I do know Pantheon, which is a competitor.

On Pantheon, the CDN and Varnish are two separate features. The advantage of Varnish on a PHP site is that requests don't have to be processed by the server and/or query the database unless absolutely necessary. I'm not sure Varnish would make much of a difference on a static page where the css and js are all included.

Based on the advertising, the WPVIP CDN is similar to Pantheon's where it's not a setting or an option. It's just part of the product's infrastructure. If that's the case, the question is whether a static html file can be delivered at a root path of url. This is not possible on Pantheon as far as I know.

HTH

ETA: https://wpvip.com/2021/08/26/how-to-go-headless-on-wordpress-vip/ "Furthermore, it’s the same platform, run from the same data centers that host our CMS product, WordPress. By running on this platform, Node applications take advantage of all these core platform services, reducing the number of suppliers and services that can cause failures, and easing troubleshooting."

So looks like a headless front end can be hosted on WPVIP and would use their CDN but might be more costly like @xjensen said.

[xjensen]

Looks like we won't be working on this, closing.