Why Generating PDF in Backend is a bad idea!
Generating PDF for balance sheets is a common thing, but it becomes painful for developers to generate a pdf with a proper unicode support even if libraries have proper unicode support. A lot of problem pops up out of nowhere during development.
I was building an account management system where client gets all kinds of information in pdf which the client can then print and work with.
I used a python version of wkhtmltopdf but that failed miserably to generate a pdf with bangla characters, so I started to generate using shell commands of wkhtmltopdf using an node.js’ command executor library.
It was working fine on my development server and laptop until moved the whole codebase into the production server instead of showing bangla fonts production server started to show joke. Pretty little cubes were printed instead of words. It felt like rain and sunshine hitting my lovely shaved head at the same time.
Then it dawned on me that the browser have a functionality called “print to pdf”, which you can just invoke by a “window.print();”. Browsers like Google Chrome, Mozilla Firefox and others have a pretty awesome pdf generation engine which generates pdfs like a champ.
So let’s finish up with a scenario how much will cost to generate a lot of pdf files from html.
- 450,000 HTML files
- 95% of the files were one page in length
- generally containing 2 images (relative path, local system)
- tabular data (sometimes contained nested tables)
- simple markup elsewhere (strong, italic, underline, etc)
- 8GB RAM
- 2.4GHz Dual Core Processor
- 7200RPM HD
It took 2.5 days to complete. My reaction was “Hahahahaha”, “LOL”, “huhhuhuhu”, “huehuehuehue”.
So the reason behind this writing is to tell developers who will be building a backend pdf generating system in the future where you can do with a single function call . Please don’t waste your CPU capacity where you don’t need to.