RFC - Move tide requests to serverMiddleware

[dylankelly]

Background

Currently all requests for CMS data needed to render a page in a Ripple frontend are made by calling the Drupal resource directly from the frontend via a proxy request to /api endpoints. A typical request to render a landing page might include the following requests

• Request to sites taxonomy to fetch global site data and site menus
• Multiple requests to menu endpoint to fetch menu items
• Request to /route endpoint to fetch information about route resource
• Request to the route resource including which subresources required

Making these requests in the Nuxt rendering layer has several disadvantages

• Payload is overkill, Drupal entity has too much data in it, 80% of landing page JSON response data delivered to browser is not relevant to rendering page.
• Super long includes query string for relationships, currently dynamic page query has 4000+ characters, may run up against browser character limits for urls
• Hard to understand for developers without Drupal experience. Difficult to trace the data flow from BE to FE because it is written in non idiomatic way and requires intimate knowledge of our custom middleware implementation. New developers are hard to onboard because of this.
• Hard to version: upgrades to Tide need to have corresponding upgrades to the entire Nuxt rendering layer instead of just the data layer.

Nuxt has a concept of serverMiddleware https://nuxtjs.org/api/configuration-servermiddleware which allows you to create a custom connect instance to render specified routes. This ticket proposes moving the current requests from the Nuxt context to this layer.

Moving these requests to a dedicated serverMiddleware would allow us to wrap all the logic for massaging data from Drupal JSON API to a usable page data model. This would be accessed from Nuxt pages in SSR asyncData hook by a HTTP GET request to the custom API endpoint eg /api/routes/nameofpage or some agreed routing schema.

The advantages of using serverMiddleware are many :

• A single place to reason about data in the FE. Moving to serverMiddleware means we can use Express for API routes which has proven idiomatic ways of handling RESTful API routes
• Multiple requests to BE to build data model for a page could be replaced with a single cacheable GET request, massive redundant JSON API payloads could be replaced with just the data we need reducing data served. The work to massage data from Drupal JSON api to useable data for Ripple API would then only performed once instead of on each request, reducing server load.
• We would be able to offer this API to 3rd party non Ripple website consumers (As was implemented in the Legislation project) as it would be human readable and would abstract over the Drupal implementation details.
• If we did decide in the future that we wanted to move this to a dedicated instance (say we wanted to have a single API server for all sites, which should technically be achievable), we could just plop this into its own node / express app.
• Even if we decided to move this to the PHP side, we would have done the hard work of defining the business logic needed and it would be just a matter of translation, our Nuxt rendering side would not need any modification other than pointing to the new endpoint.
• Offering only the API module would allow for faster development on projects which want to use Tide without Ripple
• Requests to API would be able to be mocked which make test automation easier to implement and allow for faster development as we wouldnt have to wait for a working Drupal BE to create new features in the FE.

Proposal

WIP - further detail to come