- Published on
Release: Terraform, CDN, Frontend Permissions
- Authors
- Name
- Dave Coates
This release contains changes up until release/2020-07-20
.
To upgrade any existing projects it's recommended to pull in the relevant commits from upstream.
git remote add upstream git@gitlab.internal.alliancesoftware.com.au:alliance/template-django.git
git cherry-pick XXX1 XXX2
In cases where you are significantly behind it may be easier to pull the whole app (eg. common_audit
) in but you'll
need to review the relevant branch.
In this release
It's been a while between posts mainly due to client load and not heaps happening on internal development. Going forward I expect these to happen fortnightly to keep the number of changes smaller to make upgrading easier.
- Terraform / CDN Setup
- Cache Busting
- Filterable PrimaryKeyRelatedField
- Frontend permission checking
- Presto
- Upcoming
Terraform / CDN Setup
A base terraform config is now included. It handles setting up S3 and Cloudfront. Our webpack setup and django settings have been updated to support a CDN. This is generally compatible with any CDN but out of the box can be used with the Cloudfront configuration specified in the terraform config.
See the project checklist
for instructions on setting it up (covered under the Do you need AWS?
and Deploying to Heroku?
steps).
Upgrading to this setup is somewhat involved and easiest option is to fully replace the project webpack config. Please see Dave if you need to do this.
Cache busting
The frontend build now has proper cache busting for all javascript files not just entry points. Previously any split bundles would not have a hash in it's filename and so would be susceptible to long term caching.
With this change and CDN support the nginx config has support for far expiring headers for static assets.
Filterable PrimaryKeyRelatedField support
The default PrimaryKeyRelatedField
used in serializers now supports a get_relationship
kwarg for use when
many=True
. This allows you to customise the queryset used when selecting the data that can be returned. The default
queryset
option only allows you to customise the possible choices that are accepted but is not used when serializing
values.
In this example a customers addresses are returned excluding any with is_archived=True
.
class CustomerSerializer(Serializer):
class Meta:
model = CustomerSerializer
fields = [
"name",
"addresses",
]
extra_kwargs = {
"addresses": {
"get_relationship": lambda addresses: addresses.exclude(is_archived=True)
}
}
To upgrade pull in commit 7eef29d1
Frontend permission checking
You can now do permission checks on the frontend. See the documentation for full details.
This works similar to djrad but never exposes permission names to the frontend and has build time validation (including strict type checking) for bad permission usage. This works using babel macros and is somewhat experimental so please give me feedback as to how you find it. If it works well we'll extend it to things like resolving named django URLs from the frontend.
Permission checks for global permissions are done on initial load unless you opt out (eg. if there are expensive permissions you may wish to defer them until they are needed). Permission checks for object level permissions are done on demand as required.
Basic usage is:
import checkPerm from '../auth/checkPerm'
import p from '../auth/perm.macro'
// Check a global permission
const hasPerm = await checkPerm(p('demo_app.user_create'))
// Check an object level permission.
const hasPerm = await checkPerm(p('demo_app.user_detail', 5))
Usage within a component is easiest with useAsync:
function MyComponent() {
const { isLoading, response: hasPerm } = useAsync(checkPerm, {
args: [[p('demo_app.brand_create'), p('demo_app.brand_detail', 1)], { any: true }],
trigger: 'DEEP',
});
if (isLoading) {
return null;
}
if (!hasPerm) {
return <PermissionDenied />
}
return ...
}
Please see this commit for the required changes.
Presto
Since the last announcement versions 0.0.16 and 0.0.17 have been released. See the CHANGELOG for full details.
Of note all the field Formatters have a consistent API for things like specifying blankLabel
and all have examples in
the documentation.
batchMiddleware was added along with some extensions to middleware necessary to make it possible.
To upgrade please read the changelog first. See this commit for some required changes due to some renamed files.
Upcoming
Next major change will be support for django 3 which should drop sometime this week or next.