DADI Web 6.0 release
Milestone release adds multiple API support and debug view
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.
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
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
- The list of routes and the current page
- 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:
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:
REST API provider
Version 6.0 removes the
restapi provider. Details are available here: https://docs.dadi.tech/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.
- #258: give
globalEventsaccess 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
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:
Template engine developers can also use
engine to pass any page specific setting to their engine.
- upgrade to Brotli 1.0 compression engine
- upgrade router to use version 2.0 of path-to-regexp
Written by David Longworth. David is the Design Director at DADI.