There are several ways and popular packages to generate unique identifiers, and one of them is the “uuid” package, which has millions of downloads every day. It proposes different types of approaches for generating identifiers, ranked by version:

• v1 — creates a version 1 (timestamp) UUID.
• v3 — creates a version 3 (namespace w/ MD5) UUID.
• v4 — creates a version 4 (random) UUID.
• v5 — creates a version 5 (namespace w/ SHA-1) UUID.

From my experience, v4 is the most commonly used UUID version when you just need a random value. Previously, to generate UUIDs in Node.js, I had to install this external package and potentially add typings, as the repository is written in pure JavaScript. However, I recently discovered an interesting update in the Node.js builds. Several releases ago, the new method crypto.randomUUID was added, which is now being used in the implementation of the “uuid” package itself. Below is a digest from the repository:

// https://github.com/uuidjs/uuid/blob/main/src/native.js

import crypto from 'crypto';

export default { randomUUID: crypto.randomUUID };

// https://github.com/uuidjs/uuid/blob/main/src/v4.js

import native from './native.js';
import rng from './rng.js';
import { unsafeStringify } from './stringify.js';

function v4(options, buf, offset) {
  if (native.randomUUID && !buf && !options) {
    return native.randomUUID();
  }

  options = options || {};

  const rnds = options.random || (options.rng || rng)();

  // Per 4.4, set bits for version and `clock_seq_hi_and_reserved`
  rnds[6] = (rnds[6] & 0x0f) | 0x40;
  rnds[8] = (rnds[8] & 0x3f) | 0x80;

  // Copy bytes to buffer, if provided
  if (buf) {
    offset = offset || 0;

    for (let i = 0; i < 16; ++i) {
      buf[offset + i] = rnds[i];
    }

    return buf;
  }

  return unsafeStringify(rnds);
}

export default v4;

So, if your code runs on the server side and your Node.js distribution is version 15.6.0 or higher, you may no longer need this additional dependency and can simply use the hidden gem from the crypto module.

If you found this article helpful, please consider leaving claps or comments to encourage me to continue writing. I also welcome any feedback you may have. Thank you, and see you in the next article!

Note: The security tips and best practices mentioned in this article are applicable to programmatically created Zapier applications. However, it’s important to note that they may not be applicable to applications created using Zapier Visual Builder, due to the limitations of this approach.

In this article, I will be sharing tips on enhancing the security of Zapier triggers. Protecting your workflow data from potential security risks is crucial in today’s automation-driven world. I’ll provide practical ways to improve the security of your Zapier triggers and safeguard your data’s confidentiality and integrity.

Before we discuss securing Zapier triggers, let’s first define what triggers are in the context of Zapier. Triggers serve as the initial events or actions that initiate automated workflows in Zapier. They act as a connection between different apps, allowing users to automate tasks based on specific events or conditions.

There are two types of triggers in Zapier: polling triggers and instant triggers.

• Polling triggers involve Zapier periodically asking applications if data is ready to be consumed. The polling frequency depends on the Zapier plan.
• On the other hand, instant triggers are essentially webhooks registered on Zapier’s side, which are triggered by the system that produces data once a new piece of data is ready. The exact type and shape of the data depending on the application’s business logic.

Understanding the differences between these two types of triggers is important for implementing effective applications. It’s evident that using instant triggers, whenever feasible, is advantageous in terms of user experience and system load.

Using the Zapier documentation, it’s relatively straightforward to implement functional triggers and actions that align with business needs. However, one crucial aspect often overlooked is the overall security of the solution.

In summary, to ensure a fully secure solution, it’s essential to follow these best practices:

• Perform calls only via secure connections using HTTPS for all communication made from the Zapier application.
• Implement appropriate authentication techniques, as outlined in the Zapier documentation.

Although it may seem obvious and relatively easy to follow these recommendations, even after implementing them correctly, there could still be a potential vulnerability when using an instant trigger. Specifically, on the Zapier side, all content received via webhook is accepted WITHOUT verifying the sender’s identity, which leaves a potential vector of attack to start a workflow on behalf of the user.

So to address this issue, there are several options available:

• One possible solution is to send an authentication token to the webhook endpoint that identifies the user in some way, adding an additional layer of authentication. However, implementing this approach can be challenging as it might require mapping roles and permissions from the system to the Zapier level, which can vary across different systems and depends on each particular case;
• Another option is to send a request with a minimal payload, such as an ID of a resource that should be called to retrieve the full data using auth strategy implemented by the Zapier application. This approach can be effective but may require additional implementation steps, such as allowing calls only to whitelisted resources and adding logic at the backend system to support this solution (such as temporary storage of prepared data);
• The third option is to allow accepting only requests with valid digital signatures. The verification key for the signature can be securely provided using Zapier environmental variables. On the backend side, we would need to add logic to sign all incoming requests, which adds an additional layer of authentication. This approach can be effective in ensuring that only requests with valid signatures are accepted, providing an added layer of security to the system.

In my experience, the third approach seems to offer the best trade-offs in terms of security and implementation effort. It can be implemented using just a few lines of code, particularly in languages like JavaScript where the crypto module can be used by both parties: Zapier application and your backend. This approach can provide robust security guarantees and can be delivered to production within a relatively short timeframe, making it a practical option for improving the security of Zapier triggers.

If you found this article helpful, please consider leaving claps or comments to encourage me to continue writing. I also welcome any feedback you may have. Thank you, and see you in the next article!

When implementing a subscription system in your project, it’s crucial to ensure a smooth and reliable payment process. To achieve this, many developers choose to use existing API services to process payments. However, it’s essential to verify the validity of a user’s credit card before accepting payment. This is to ensure that the card is not stolen and that it is authorized for payments.

Stripe is one such payment processing provider that offers built-in checks, such as CVC or postal code verification, to help verify credit cards. However, sometimes these checks are not sufficient. For example, if your website offers a trial period, users may need to provide their credit card information upfront, even if they haven’t yet been charged. Similarly, if a user wants to change their payment method, it’s important to verify that the new card is valid before making the switch.

To verify credit card validity, one approach is to initiate a test charge for a small amount, usually around $1, and then refund it. However, upon closer examination, this approach has several downsides, including:

• If the test charge takes money out of the user’s account, it’s super important to give it back right away. We need to make sure no one’s money gets stuck in our system, and that our customers don’t get mad at us. So, we gotta have a transactional flow to make sure everything runs smoothly!
• Stripe imposes a fee for this kind of operation. For every dollar charged and refunded, Stripe takes a 33-cent or 33% cut out of our pocket. While this may be fine for a single user, it can become a costly process for thousands of users.

We seem to have a problem here and to find a solution, we first need to understand how Stripe works. Let’s start with the second problem — the fees imposed by Stripe. Stripe charges fees for finalizing operations, which means fees are applied to money transfers from Bank A to Bank B. Perhaps there’s a way to reach our goal without actually transferring any money? The answer is yes, and it’s called the “Authorize and Capture” approach, which breaks down the money transfer into two stages:

• The authorization ensures the account has sufficient funds and is in good standing by holding funds as pending without charging the card.
• Capture is the process of transferring funds from the customer account to the merchant account, moving it from pending to complete.

It turns out that we only need to perform the authorization process to verify a user’s credit card, and then roll it back to release the funds. This way, we avoid the transaction fees associated with traditional charge-and-refund methods. If the credit card has any issues, such as insufficient funds or invalid details, Stripe will respond with an error message, allowing us to provide guidance to the users. If everything is good to go, then the credit card is ready to use as the primary payment source.

Now that we understand how we can avoid costly fees while verifying credit cards with Stripe, let’s take a look at how we can implement this approach using the Stripe SDK. Essentially, the algorithm can be broken down into three simple steps:

• The first step of this algorithm is to create a payment intent with a value of 1 dollar and set the capture_method to manual. To make the process faster and reduce the potential for points of failure, we can confirm the payment intent immediately. Depending on the circumstances, the payment intent may have a status of requires_capture if the operation is synchronous and does not require 3D security. If 3D security is required, the status will be requires_action. It’s also important to note that Stripe may respond with a business error, indicating that the payment method is not valid.
• Client app handling is the second step of the algorithm. If the payment method requires user action, such as 3D security, we need to notify the user and provide them with a Stripe payment intent ID and secret to finalize the intent creation. This step is optional and depends on the bank’s settings. If the payment intent has a status requires_action, the user will need to perform an action to authenticate the payment, such as entering a one-time password. Once the authentication is complete, the payment intent status will change to requires_capture, and we can move on to the next step.
• Stripe event handling via webhook is the final step of the algorithm. We need to set up a webhook to listen for two events: payment_intent.amount_capturable_updated and payment_intent.payment_failed. If the payment_intent.amount_capturable_updated event is triggered, and the intent has a status of requires_capture, then everything is okay, and we can cancel the intent and finalize the validation process. If the payment_intent.payment_failed event is triggered, then an error occurred, and we need to communicate it to the user.

const stripe = require('stripe')('sk_test_...');

async function verifyPaymentMethod() {
  try {
    const intent = await stripe.paymentIntents.create({
      amount: 100, // $1
      currency: 'usd',
      capture_method: 'manual',
      description: 'Verification of Payment Method',
      confirm: true,
      payment_method: 'pm_...',
      customer: 'cus_...',
    });

    if (intent.status === 'requires_capture') {
      // Payment method is verified
      return {
        intentId: intent.id,
        verified: true,
        requiresAsyncFlow: false,
      };
    }

    return {
      intentId: intent.id,
      verified: false,
      requiresAsyncFlow: true,
    };
  } catch (err) {
    return {
      intentId: null,
      verified: false,
      requiresAsyncFlow: false,
      errorMessage: err.message,
    };
  }
}

To properly implement this code, it is necessary to replace the credentials with the appropriate values for the Stripe account. However, the overall structure and purpose of the code are clear and effective in explaining the concept.

The second part of the process involves setting up an HTTP listener that can receive the relevant events from Stripe’s webhook. We can handle this by writing a simple function that can parse and process the event data sent by Stripe. This function can then be invoked whenever Stripe sends a webhook event, allowing us to handle the event and take appropriate action as needed.

const stripe = require('stripe')('sk_test_...');

async function handleEvent(event) {
  switch (event.data.object.status) {
    case 'payment_intent.amount_capturable_updated': {
      await stripe.paymentIntents.cancel(event.data.object.id);
      // notify the user about verification success
      break;
    }
    case 'payment_intent.payment_failed': {
      // notify the user about payment failure and possible issues with a credit card
      break;
    }
  }
}

This implementation covers the main steps of the algorithm and should work for most use cases, but depending on the specifics of your project, you may need to add some additional logic or functionality.

It’s worth noting that Stripe provides an automatic cancellation feature for payment intents that aren’t canceled by our application due to unforeseen reasons such as downtime or mistake in the codebase. If such a situation occurs, the payment intent will be automatically canceled by Stripe after 7 days, which eliminates the possibility of blocking the user’s money without unlocking it back. This feature acts as an additional safeguard against accidental charge capture and provides reassurance to the users that their funds are safe in case of any unexpected events.

To summarize, the credit card validation process can be achieved by using the “Authorize and Capture” approach with Stripe. The algorithm consists of three steps: payment intent creation, client handling, and Stripe event handling via webhook. By following these steps, we can validate credit cards without incurring the high fees associated with test charges, ensuring a smooth payment process for our users.

Thank you for reading!

These days, it seems like everyone is talking about AI and its potential threats and benefits. I don’t want to join this “choir”, but I’m also looking for ways to improve my processes and make life easier. After attending a meetup about the future of development in early January, I decided to try using some AI tools at work. I did a quick half-hour of research, considering factors like privacy, maturity, and other options. In the end, I decided to give TabNine a try.

Now, after using TabNine for a month, I’m ready to share my feedback and thoughts about it. To make things clearer, I’d like to split all of my code-related activities into four areas: business logic implementation, refactoring, testing, and writing documentation.

First, let’s talk about business logic implementation. At Indy, we use both pure JavaScript and TypeScript for our services. In my experience, TabNine’s suggestions for TypeScript are better. In fact, I’ve learned some tricks related to the TS-type system that I had never seen before. While the business logic has good code completion, there is still room for improvement in some cases.

Let’s move on to refactoring. During the TabNine trial period, I had several tasks that involved refactoring or changing some parts of the system. One of the best things about the tool was how it understood which dependencies I wanted to import into the current file. For example, when I wrote const _ the tool automatically understood what I wanted to have const _ = require('lodash'); in the end. This happened with almost every dependency that I had to work with. Another benefit of using TabNine is that it can help you reduce the work with boilerplate code. Instead of searching for commonly used code snippets in your project or typing them out manually, you can simply start typing the beginning of the code, and TabNine will suggest the rest. This feature can save you time and effort when working on a project, as it makes writing code faster and more efficient.

Let’s talk about tests. This is one of the best features of TabNine, especially when you need to implement several tests that are similar but with subtle differences, such as in some parameters. Tests are, by nature, simpler compared to business logic and often contain a lot of repeating code. I found that TabNine was able to generate some of the test files automatically by up to 50%. This saved me a lot of time and made the testing process much more efficient.

Last but not least, let’s talk about documentation writing. TabNine is incredibly helpful in this regard. It provides a similar experience to what Google has in their Gmail application when you’re composing an email. In many cases, it suggests exactly what I want to write, which has saved me a lot of time and made the process much smoother.

Results

The TabNine tool comes with a simple dashboard that displays statistics on its usage.

Currently, according to TabNine’s statistics, 37% of my code was automatically generated, and based on my experience, I believe this to be an accurate number. Since using TabNine, I’ve noticed a 10–15% improvement in my speed and efficiency, mostly due to a reduction in routine tasks. Overall, I’m quite pleased with the results and the performance boost that TabNine has provided.

If you have the option to use an AI tool to simplify your work on a project, I highly recommend taking advantage of it. These tools, such as TabNine, can help streamline your workflow and save you time and effort when coding.

NOTE: The simplified version of the project is available by the link. All examples are taken from it.

Periodically we at Indy invest time in analyzing and updating dependencies to the latest versions as a part of the maintenance routine. So there is nothing special. One day during such an activity I’ve noticed that it was impossible to start the project after the simple upgrade.

The logs clearly spotted the culprit — the library got changed its module system from the CommonJS to the ECMAScript modules.

/Users/vitalizaneuski/.nvm/versions/node/v16.15.0/bin/node /Users/vitalizaneuski/projects/esm-test/broken-require.js
/Users/vitalizaneuski/projects/esm-test/broken-require.js:3
const got = require("got");
            ^

Error [ERR_REQUIRE_ESM]: require() of ES Module /Users/vitalizaneuski/projects/esm-test/node_modules/got/dist/source/index.js from /Users/vitalizaneuski/projects/esm-test/broken-require.js not supported.
Instead change the require of index.js in /Users/vitalizaneuski/projects/esm-test/broken-require.js to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (/Users/vitalizaneuski/projects/esm-test/broken-require.js:3:13) {
  code: 'ERR_REQUIRE_ESM'
}

The author of the library did a good job and posted documentation on how to start using the new version of the library, plus Node.js logs were also helpful. So it seems the solution was simple, just to replace the sync require by async dynamic import, and this situation should be sorted out. And it worked!

/Users/vitalizaneuski/.nvm/versions/node/v16.15.0/bin/node /Users/vitalizaneuski/projects/esm-test/dynamic-import.js
{
 "login": "mojombo",
 "id": 1,
 "node_id": "MDQ6VXNlcjE=",
 "avatar_url": "https://avatars.githubusercontent.com/u/1?v=4",
 "gravatar_id": "",
 "url": "https://api.github.com/users/mojombo",
 "html_url": "https://github.com/mojombo",
 "followers_url": "https://api.github.com/users/mojombo/followers",
 "following_url": "https://api.github.com/users/mojombo/following{/other_user}",
 "gists_url": "https://api.github.com/users/mojombo/gists{/gist_id}",
 "starred_url": "https://api.github.com/users/mojombo/starred{/owner}{/repo}",
 "subscriptions_url": "https://api.github.com/users/mojombo/subscriptions",
 "organizations_url": "https://api.github.com/users/mojombo/orgs",
 "repos_url": "https://api.github.com/users/mojombo/repos",
 "events_url": "https://api.github.com/users/mojombo/events{/privacy}",
 "received_events_url": "https://api.github.com/users/mojombo/received_events",
 "type": "User",
 "site_admin": false
}

Process finished with exit code 0

Yeah, the output above was the same as it was expected, but IDE was still complaining because of the ESLint.

> esm-node-js-test@1.0.0 lint
> eslint .


/Users/vitalizaneuski/projects/esm-test/broken-require.js
  3:21  error  Unable to resolve path to module 'got'  import/no-unresolved

/Users/vitalizaneuski/projects/esm-test/dynamic-import.js
  4:28  error  Unable to resolve path to module 'got'  import/no-unresolved

✖ 2 problems (2 errors, 0 warnings)

Many production-ready projects are using some kind of a linter and we at Indy are not an exception to the rule. One of the plugins that we’re using is an ESLint import plugin. The error in the snippet was caused by the violation of the import/no-unresolved rule that checks whether the dependency is installed and can be resolved in production or not.

This error is a bit tricky to fix because we need to understand why it happens and how ESLint works and resolves packages. By default, eslint-import-plugin uses a node resolver plugin that is looking for the package.json in the project and trying to resolve the project entry point defined by the main property in the package.json . But the trick here is that new packages that are using ECMAScript modules are shipped with exports property instead of main. And it makes ESLint check to fail.

Realizing the issue is easy to fix it — we just need to use another resolver plugin from the list of available ones. After a quick search in the npm, the following one was found — the exports resolver plugin that adds missing functionality. The final ESLint configuration is below.

"use strict";

module.exports = {
  env: {
    node: true,
    es2020: true,
  },
  plugins: ["import"],
  settings: {
    "import/resolver": {
      node: {
        extensions: [".js"],
      },
      exports: {},
    },
  },
  rules: {
    "import/no-unresolved": ["error", { commonjs: true }],
  },
};

That is it, the situation is resolved and the project now using packages baked by ECMAScript modules.

NOTE: The refactoring can be intricate and I just described the case from my work. If you need to have some sync code that depends on the package, you need to rework the logic flow entirely, cause Node.js in CommonJS does not support root level await while import('package-name') only works asynchronously.

Intro

One of the common problems that I have been solving as a Software Engineer in several projects is how to generate PDFs and how to choose the proper approach. At Indy, we have tried some approaches such as Jasper, Puppeteer & PDFMake. In this article, I would like to compare two of them.

TLTR

Both puppeteer and PDFMake are good libraries to solve a PDF generation problem. PDFMake requires bigger involvement in maintenance due to the unique syntax, but at the same time shows greater performance in PDF generation (if we exclude context preparation: downloading of data from business services and image processing) for relatively small files. But PDFMake suffers when it comes to PDFs of big sizes (> 5MB) with large numbers of images, while Chrome & puppeteer pair process it way faster.

Puppeteer allows downloading PDFs from any page without knowing the details of page implementation, while for the PDFMake it’s required to know in advance what should be generated. Also, it’s up to the engineer to handle image download at the backend side, while Chrome does this routine for you.

PDFMake gives more granular control over the resulting document, such as header & footer elements.

PDFMake supports stream API that theoretically allows handling bigger files compared to the Chrome engine, but at the same time for the PDFMake library you need to provide the whole document definition prior to the generation, so the benefits of streaming might be neglected.

It’s always up to the engineer to properly define the problem and choose the solution that works better in a particular case.

Puppeteer

Puppeteer is a Node.js library which provides a high-level API to control Chrome/Chromium over the DevTools Protocol. Puppeteer runs in headless mode by default, but can be configured to run in full (non-headless) Chrome/Chromium.

As mentioned in the official documentation Puppeteer is a library that allows us to communicate with a running Chrome/Chromium instance. This fact can be leveraged to generate PDFs using standard Chrome functionality (aka CTRL+P). All we need to do is to set up a connection to Chrome, open the page with content and generate PDF. The full code can be found by the link.

const browser = await puppeteer.launch({headless: true});

const page = await browser.newPage();

// set up pdf content somehow

const dataBuffer = await page.pdf({format: 'a4'}); // Buffer with generated PDF data

fs.writeFileSync('foo.pdf', recordSet);

Four simple lines of code and you have your generated PDF file. The only missing piece here is how to set up the proper page or content for PDF. Puppeteer API has two useful methods for this perspective: page.goto with provided url and page.setContent with specified HTML content.

const browser = await puppeteer.launch({headless: true});

const page = await browser.newPage();

const html = `<html><body>Hello world!</body></html>`

await page.setContent(html, {waitUntil: ['networkidle0']});

const dataBuffer = await page.pdf({format: 'a4'}); // Buffer with generated PDF data

fs.writeFileSync('foo.pdf', recordSet);

That’s all, a simple PDF has been created.

PDFMake

pdfmake

Client/server side PDF printing in pure JavaScript

In-browser

Print PDFs directly in the browser or delegate it to your NodeJS backend. Use the same document definition in both cases.

Fully declarative

Forget about manual x, y calculations. Declare document structure and let pdfmake do the rest.

Powerful layout engine

Use paragraphs, columns, lists, tables, canvas, etc… Declare your own styles, use custom fonts, build a DSL and extend the framework.

The PDFMake library can be used both on the client & server sides. The library has its own document syntax to create a PDF document definition that is a bit similar (but not equal) to the HTML. To convert HTML to its language we can use some libraries from the npm, e.g. html-to-pdfmake.

Here is a short example. The full code can be found by the link.

const fonts = {
  Courier: {
    normal: 'Courier',
    bold: 'Courier-Bold',
    italics: 'Courier-Oblique',
    bolditalics: 'Courier-BoldOblique',
  },
  Helvetica: {
    normal: 'Helvetica',
    bold: 'Helvetica-Bold',
    italics: 'Helvetica-Oblique',
    bolditalics: 'Helvetica-BoldOblique',
  },
  Times: {
    normal: 'Times-Roman',
    bold: 'Times-Bold',
    italics: 'Times-Italic',
    bolditalics: 'Times-BoldItalic',
  },
  Symbol: {
    normal: 'Symbol',
  },
  ZapfDingbats: {
    normal: 'ZapfDingbats',
  },
};

const printer = new PdfPrinter(fonts);

const pdfStream = printer.createPdfKitDocument({
  defaultStyle: {
    font: 'Helvetica',
  },
  content: [{text: 'Hello world'}],
});

pdfStream.end();

const chunks: Buffer[] = [];

for await (const chunk of pdfStream) {
  chunks.push(chunk as Buffer);
}

const dataBuffer = Buffer.concat(chunks);

The PdfPrinter constructor accepts a list of supported fonts, while the printer instance can generate a stream of pdf chunks that should be collected to produce a final PDF buffer. This buffer can be used the same way as in the puppeteer’s example to record the file to the disk (for example).

Real-life usage

Everything is easy when you start reading examples, but how does it work in real life? As a Software Engineer, you should consider different aspects of the implementations. Let’s focus on some of them for now:

• Ability to fit business needs;
• Maintenance;
• Performance.

Ability to fit business needs

Nobody needs a solution if it does nothing from the business perspective. Both approaches provide pretty good functionality to generate PDFs by provided templates and can work for major cases, in our case at Indy, for example, we have found out that PDFmake provides a bit more extended possibilities to work with documents, e.g. more granular configurations for headers and footers. Also, it has plenty of interesting features such as PDF encryption out of the box.

But anyway both of the solutions are mature and can be used in production based on use cases. If you need to create a PDF from the existing web page, puppeteer might be a better solution, especially when a web page has tons of async content or doesn’t belong to your organization directly.

Maintenance

When it comes to the maintenance of PDF generators it comes to the ways how you’re working with templates. The Puppeteer library supports two modes:

• Navigate to a page and when the page is loaded — create the PDF.
• Propopulate the HTML with all needed content (e.g. images and business properties) and render a page by chrome/chromium using it. After that — create PDF out of it.

The first approach can be solely handled on the client side by the Frontend or Full Stack Engineers using popular frameworks & libraries, such as React. All that backend needs to do — just open the proper link to make it work.

The second approach is similar to the first one but allows you to construct content solely on the server side, using any templating library or syntax that can be converted to HTML.

Both approaches are good since a team with any knowledge & stack can find the best way for them.

PDFMake provides only one way to define the pdf document — generate proper object definition by the provided business entities. This approach is a bit similar to the 2nd for the puppeteer with subtle differences: e.g. to use images by the PDFMake on the server side you need to download it to the memory, while the puppeteer does this job by itself.

To use PDFMake properly the team needs to learn new syntax or use libraries that transform commonly known languages, such as HTML to document definition. At Indy, we prefer using bare document definition to use the full power of the library.

Performance

The very last aspect that we focus on in the article — is the performance of the solution. Backend systems are tending to process requests from a large number of users and it’s essential to know what number of users the solution can sustain and what is expected amount of time to process a single request. Also, systems under load can experience different effects and show bottlenecks in the implementations.

To test the performance of puppeteer & PDFMake libraries a simple project has been developed. Let’s define three types of loads:

• Small — a simple PDF for 1–2 pages with 1 image;
• Medium — a medium-sized PDF for 10–15 pages with 10 images;
• Large — a large-sized PDF for 60–70 pages with 50 images.

To compare different implementations I’ve decided to run a script that will repeat the concurrent PDF generation for a given size and concurrency level. At the end of it, the average data can be collected. To have a similar environment & resources the Docker container can be used.

Preconditions:

• Tests are run under the Docker with 2 CPUs (2,4 GHz 8-Core Intel Core i9) & 2 GB memory;
• All images are served by the Nginx;
• The cache for downloading images in Chrome is disabled to make the comparison a fair one;
• Node.js process is allowed to make only 150 concurrent requests to the Nginx image service to not crush the application due to the high concurrency;
• To gather average values for the final charts all loads were run 20 times.

In the charts there are four lines:

• The “Chrome pdf generation” line represents the average time in milliseconds (Y axis) to generate concurrently X PDFs using the puppeteer library;
• The “PDFMake pdf generation” line represents the average time in milliseconds (Y axis) to generate concurrently X PDFs using the PDFMake library;
• The “PDFMake image download” line represents the average time in milliseconds (Y axis) to download images into the memory;
• The “PDFMake pdf creation” line represents the average time in milliseconds (Y axis) to actually generate PDFs using PDFMake by provided data.

After a couple of hours of waiting & calculating results, I noticed some interesting facts.

The first fact is that PDFMake is extremely fast for small & medium loads if we exclude image downloading time. The library can handle 50 concurrent requests under 300 ms or roughly 150 requests per second. But at the same time image preparation (download of 500 images) took almost 7 seconds for a medium load.

The second interesting fact is neither PDFMake nor puppeteer can deal with “large” loads efficiently. The chrome-based approach became unstable and start crashing or receiving timeouts for 11 concurrent requests. PDFMake was a bit better, but also crashed soon for 21 requests.

The third fact about PDFMake is that this library suffers when it comes to big PDFs. It took 5 seconds to generate a PDF of 8MB. Chrome rendered the same PDF 2.5 times faster.

Conclusions

Both puppeteer and PDFMake are good libraries to solve a PDF generation problem. PDFMake requires bigger involvement in maintenance due to the unique syntax, but at the same time shows greater performance in PDF generation (if we exclude context preparation: downloading of data from business services and image processing) for relatively small files. But PDFMake suffers when it comes to PDFs of big sizes (> 5MB) with large numbers of images, while Chrome & puppeteer pair process it way faster.

Puppeteer allows downloading PDFs from any page without knowing the details of page implementation, while for the PDFMake it’s required to know in advance what should be generated. Also, it’s up to the engineer to handle image download at the backend side, while Chrome does this routine for you.

PDFMake gives more granular control over the resulting document, such as header & footer elements.

PDFMake supports stream API that theoretically allows handling bigger files compare to the Chrome engine, but at the same time for the PDFMake library you need to provide the whole document definition prior to the generation, so the benefits of streaming might be neglected.

It’s always up to the engineer to properly define the problem and choose the solution that works better in a particular case.