https://notion-ga.ohwhos.now.sh/collect?tid=UA-65620077-1&host=gajd.uk&page=/templator/how

<aside> 📢 To my surprise, this was one of the most common questions I received. This was not explained in more detail before, because I felt that it is too technical to be interesting.

</aside>

Templator uses the same engine that Chrome uses when you select Save As PDF in the print dialog. This engine converts an HTML/CSS to a PDF.

Unfortunately, due to platform dependencies, it is not possible to run this engine on the same machine that your Mendix app is running on in the Mendix cloud. Therefore, Templator is separated into two components: a service running the chrome PDF engine and a Mendix module that communicates with this service.

When you install Templator you do so by adding the Mendix module to your app. At its core, this module acts as client and simply forwards requests to the service which does all the heavy lifting.

This is best summarized by the following chart:

How Templator generates a PDF: behind the scenes

How Templator generates a PDF: behind the scenes

Security

As stated in the docs, Templator uses an external service to generate the PDF. It is important to keep in mind that the service is only given limited access to the app both in terms of access rights and duration. This access is facilitated by an special token. This token and all other sensitive data are sent encrypted using 2048bitRSA encryption. No data, except what is needed for administering rate limits, is stored outside of the Mendix App, not even temporarily. For administering rate limits the following information is stored: timestamp, URL, app id, number of pages in the PDF, and whether the request was successful or not.

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/47fd2da2-33cf-44c6-97f4-069e651cf2ec/Untitled.png

Why is the module source code packaged?

To properly maintain and test the module the easiest way was to package it as a single jar dependency. This enables me to:

  1. Keep tests outside of the module and run them without a Mendix instance
  2. Easily port the module to later/earlier Mendix versions since the Mendix part of the implementation is kept to a minimum and most of the logic is in a single jar file
  3. Package other java dependencies in the same jar, thus avoiding jar version conflicts
  4. Making it easy to update dependencies without asking you to manually delete old jar files from userlib like is the case for many Mendix modules

The goal here was not to keep the implementation secret, since the code is not obfuscated and can easily be recovered with a simple decompiler.