Database Reference
In-Depth Information
You can encounter the same issue of passing data through the App Engine
application when building the dashboard component discussed next.
Reading data can also bypass the web application if the access token is
shipped to a JavaScript client running in the browser. Locking down the
capabilities for this type of access can be quite challenging and is often not
justified because the resources required are not that much greater than what
is required to serve the dashboard itself.
Dashboard
The goal of the dashboard page is to provide a summary of the data collected
by the application so that viewers can quickly identify the main trends. Most
of the effort in putting together a useful dashboard goes toward finding the
right queries and selecting the appropriate visualizations. However, there
are aspects of using BigQuery that require special attention when it is used
to drive a dashboard or reporting application. Chapter 11 covers these
patterns in detail. This section highlights where they appear in the sample
application so that you can see them in action.
Data Caching
Because a dashboard page is often viewed frequently, requires multiple
queries to construct, and users expect it to appear with little delay, it is not
a good idea to issue new queries for every dashboard page request. Queries
that involve large tables are especially problematic because the costs for
these will be substantial and the latency high enough that it will stall the
rendering of the page. Instead, you can cache the data that needs to be
rendered periodically so that the resources used to compute the data can
be shared across multiple views of the dashboard. In App Engine it is easy
to coordinate this caching using its task-scheduling feature. The application
defines a
cron.yaml
file containing a list of tasks and their scheduling
information.
cron:
- description: create daily tables
url: /dashboard/create
schedule: every day 01:00
- description: 10m dashboard refresh
url: /dashboard/trigger/10m
