DADI Web 6.0 Release

DADI Web is the templating layer within our web services stack and has just been treated to its sixth major release by its engineering team. Full details of what’s new can be found below, or if you want to dive straight in go here.

🔗New features

🔗Debug view

A new debug view has been added to allow developers to understand how a particular page has been generated. In previous versions of Web we’ve used a configuration setting allowJsonView which enabled the option of seeing the data context used to build a rendered page - this could be used on any page by appending json=true to the URL.

The new debug view in this version is far more powerful and provides greater insight into how your data is being used within Web.

To enable debug view, we’ve provided a new configuration setting allowDebugView. This replaces the existing allowJsonView setting, however it is backwards-compatible with the ?json=true parameter: this still works but is translated to?debug=json.

Documentation is available on the DADI Documentation website, but here are a few of the things the debug view can show:

• The DADI Web version and Node.js version

• The data Web used to the construct the page, such as the template name and attached datasources and events

• The rendered template next to the output with postProcessors applied

• The list of routes and the current page pathname

• The request and response headers

• The raw page data JSON

• Time to render output

• Size of raw data payload

• Which page route matched the current path

• Size of rendered output (before compression)

🔗Multiple API support

Version 6.0 removes Web’s 1:1 relationship with DADI API. Previously Web allowed for a single API connection via the main configuration file:

"api": { 
  "host": "127.0.0.1",
  "port": 3000
}
"auth": {
  "tokenUrl": "/token",
  "clientId": "your-client-id",
  "secret": "your-secret"
}

With this approach if you wanted to connect a datasource to a different DADI API then those details were required in the datasource specification, making the maintenance of configuration somewhat difficult with keys potentially spread throughout the app.

Version 6.0 allows adding multiple DADI API configurations which can be referenced from a datasource by API name:

Main configuration:

"api": { 
  "main": {
    "host": "api-one.somedomain.com",
    "port": 80,
    "auth": {
      "tokenUrl": "/token",
      "clientId": "your-client-id",
      "secret": "your-secret"
    }
  },
  "secondary":  {
    "host": "api-two.somedomain.com",
    "port": 80,
    "auth": {
      "tokenUrl": "/token",
      "clientId": "your-client-id",
      "secret": "your-secret"
    }
  }
}

Datasource configuration:

{
  "datasource": {
    "key": "articles",
    "source": {
      "api": "main",
      "endpoint": "1.0/cloud/articles"
    },
    "count": 12,
    "paginate": false
  }
}

🔗REST API provider

Version 6.0 removes the wordpress and twitter data providers, replacing them with a restapi provider. Details are available here: https://docs.dadi.cloud/web/#rest-api. The main difference between the existing remote provider and the new restapi provider is that restapi provider can be supplied with authentication configuration.

🔗What’s changed?

• #258: give globalEvents access to full page data, and run per request instead of only at startup

• #262: default workspace folders no longer created unnecessarily, even if the config pathsspecified different locations than the default

• #267: fix Markdown provider crash if data was malformed

• #336: middleware can now intercept public folder requests

• #350: add support for range header requests on static assets so a browser can specify which part of a file it wants to receieve and when.

• #370: add configuration options for @dadi/status

• Deprecated configuration setting for compression removed. headers.useGzipCompressionwas deprecated in Web 4.0 in favour of the more generic useCompression.

🔗Page whitespace configuration

Note: this is a breaking change

This configuration option has been moved within the page specification file to a block dedicated to the chosen template engine. Modify existing page.json files as follows:

Existing:

"settings": {
  "keepWhitespace": true
}

New:

"settings": {
  "engine": {
    "keepWhitespace": true
  }
}

Template engine developers can also use engine to pass any page specific setting to their engine.

🔗Dependency updates

• upgrade to Brotli 1.0 compression engine

• upgrade router to use version 2.0 of path-to-regexp