Skip to content

Architectural Decision Log

Jump to bottom
Brandon Bouchard edited this page Nov 22, 2022 · 3 revisions

Template

Using Puppeteer for PDF creation

  • Status: Accepted
  • Proposers: Kushal Arora
  • Deciders (Meeting attendees): Adam Kroon, Will Sonnex, Bing Gao, Brandon Bouchard, Kushal Arora
  • Date of Proposal: 2022-10-24

Technical Story: UTOPIA-273

Context and Problem Statement

When the user submits a PPQ form, the app should provide an ability to export the filled information and the result to the pdf format. Check the above story for more information.

Considered Options

  • PDFKit -> Have built in methods to create PDF documents and works well for static pdf builders, however it does not support ability to render html or markdowns
  • jsPDF -> Did not work for rendering HTML content on Node
  • html2canvas -> Frontend library
  • wkhtmltopdf -> Application failure when trying to run
  • PhantomJS -> Deprecated
  • PDFjs -> Primarily a frontend library
  • Puppeteer -> Headless chrome implementation - ideal for automated testing and pdf generation

Decision Outcome

Chosen option: Puppeteer, because it suffices the need of creating PDF while taking into account the dynamic inputs from user forms as markdown. In addition to it, below are other considerations:

  • It supports html as input
  • It support markdowns
  • Not deprecated
  • No audit vulnerabilities
  • Can be used with pug, a template engine - to keep pdf template highly extendable
  • Can be used with marked, a Markdown parser - to support parsing of our stored markdown data

Considering all the parameters, even though with a little overhead of setting it up on Docker, Puppeteer comes out to be our best solution.

Positive Consequences

  • Extendable solution - Template-ized for usage in other parts of the application as well
  • We can continue to define PDF content using HTML, which the development team is comfortable writing

Negative Consequences

  • One time setup overhead combined with Docker user permissions complications
  • Overhead of running additional packages in every docker API deployment containers scaled horizontally

Solution to Negative Consequences

The puppeteer pdf generation code should be moved away as it's own microservice and limiting the scaling as only needed by the download functionality(ies).

Links

Template

# [short title of solved problem and solution]

* Status: [proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)] <!-- optional -->
* Deciders: [list everyone involved in the decision] <!-- optional -->
* Date: [YYYY-MM-DD when the decision was last updated] <!-- optional -->

Technical Story: [description | ticket/issue URL] <!-- optional -->

## Context and Problem Statement

[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]

## Decision Drivers <!-- optional -->

* [driver 1, e.g., a force, facing concern, …]
* [driver 2, e.g., a force, facing concern, …]
* … <!-- numbers of drivers can vary -->

## Considered Options

* [option 1]
* [option 2]
* [option 3]
* … <!-- numbers of options can vary -->

## Decision Outcome

Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].

### Positive Consequences <!-- optional -->

* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …]
* …

### Negative Consequences <!-- optional -->

* [e.g., compromising quality attribute, follow-up decisions required, …]
* …

## Pros and Cons of the Options <!-- optional -->

### [option 1]

[example | description | pointer to more information | …] <!-- optional -->

* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* … <!-- numbers of pros and cons can vary -->

### [option 2]

[example | description | pointer to more information | …] <!-- optional -->

* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* … <!-- numbers of pros and cons can vary -->

### [option 3]

[example | description | pointer to more information | …] <!-- optional -->

* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* … <!-- numbers of pros and cons can vary -->

## Links <!-- optional -->

* [Link type] [Link to ADR] <!-- example: Refined by [ADR-0005](0005-example.md) -->
* … <!-- numbers of links can vary -->

This the wiki footer for BC Government's DPIA product.

Clone this wiki locally