Technical overview

Claim tax benefits is not a stand-alone application, but rather requires a high level of integration with the CRA. The product retrieves individual data from the CRA database, and then displays this data to the tax-filer. The product communicates with the CRA database via an API (application programming interface). API technology allows one system to communicate with another.

Once the tax-filer authenticates themselves, the API communicates the individual’s data to the product. The product then asks the tax-filer to confirm that this information is correct. This product files tax returns through the NETFILE API — the same one used by vendor software.

As the CRA database uses legacy technology, this involves a degree of risk. This risk is mitigated by hosting the online product on cloud technology to separate it from the database. This separation allowed us to prototype different versions, without jeopardy to the CRA data. If the product had become a live service, this meant we could have continued to change the service based on user feedback.

Repository

For developers

Summary

The Claim tax benefits application is a server-side express application using Pug templating on the server and SCSS stylesheets. The application scaffolding comes from the express generator. It assumes the existence of a backend API (to receive user data) and a cloud database (for storing access codes), although both are stubbed out so the application can run in isolation for development purposes.

The application implements many recommended practices for a modern web service.

Use of third-party services

We use several third-party services for an improved development workflow and continuous security.

  • GitHub is a cloud-based service that stores our source code, tracks code changes and facilitates code reviews
  • GitHub Actions is a Continuous Integration and Deployment (CI/CD) service that allows us to test and deploy our code right from GitHub

    • CI/CD services abound, but we used GitHub Actions because it was easy to set up, and with its yml-based configuration it would be easy to move away from
  • Heroku is a fully-managed platform as a service. We use Heroku Review Apps to build disposable applications per pull request, facilitating code reviews.
  • Snyk is a software as a service product that scans through our dependencies for packages with known issues. It alerts us when a version of a package we’re using has a known exploit.
  • LGTM is a software as a service product for continuous security analysis. It analyzes each pull request for potential security vulnerabilities.
  • SonarQube is a software as a service product for code quality analysis. It analyzes each pull request for code smells, potential security holes, or bugs to ensure better coding practice.

Automated tests

All new pull requests have a suite of automated tests run against them.

  • Jest: Unit tests to verify correct internal logic for components
  • ESLint: JavaScript linter that ensures uniform JS throughout the app
  • Cypress: End-to-end behaviour-driven tests that run through desired user flows

    • cypress-axe: We run an accessibility scan per page (using axe) to check for violations in the markup
  • SonarQube does a quality analysis gate looking for code smells, diminished code coverage, or bugs.

Continuing development

A walkthrough on how to continue development on this project: whether your aim is to rebuild the service in a new technology or to develop and release this codebase specifically.

Build and run the application

Check out the README for more detailed instructions on building and deploying the application.