PDF at scale without managing your own microservice.
Microservices are a pain for multiple reasons. You should avoid them at all cost as long as your product, the size of your team or whatever reason still match the need for a clean monolith.
Afters 10 years of creating web platforms and products, we ran into a quite basic problem that repeat itself; you have to create PDF files, yes always. Because of exports, because of invoices, to attach data in emails, you name it.
I am specifically talking about web applications here, and so in a way or another your app is already providing web pages made with HTML.
Yes thats what we are talking here, PDF at scale with HTML as source AKA HTML to PDF.
There is just no library who stands out that is able to do that any good; I know it because we tried them all.
Lets look at the situation of the libs that convert HTML to PDF :
- Libs that rely on uncommon binary installed on your server
— More specifically libs that rely on a not maintained anymore binary (indeed wkhtmltopdf is not maintained anymore 🤭) - Libs that use a weird template system
— It’s OK if you like ugly documents and are willing to learn a weird templating system (not standard) - Libs that only works on the browser
— Creates a PDF with only a big picture, like a screenshot 🤢 - Libs that only know a subset of HTML, a subset of CSS and can’t execute JS
— If at first thought you don’t care much, now think about your React or Vue.js app as source for your PDF 😋 - Something like puppeteer, that works with (Headless) Chrome ♥️
— The only sane choice
So far, so good, we have a beginning of a solution. And if you are using Node.js it is quite easy, you can use Puppeteer with few lines of code. If you are not using Node.js, well there is probably wrappers for your langage that starts headless chrome and connect to the devtool API (what Puppeteer does), but Puppeteer is very well maintained and always kept in sync with new Chrome versions (ie. the best choice)
But remember, life is hard.
OK, now you must ask yourself what if 10 (or more, a lot more) users are asking to generate a PDF at almost the same time ?
It’s simple: It will try to start 10 Chrome instances and bloat your server to death. Game over.
You now have a huge task ahead of you to make it work at scale. The way is paved with queues, microservices, fancy technologies and everything in between. And all that jazz is now under your responsibility.
Remember your first problem ? You wanted a PDF from an HTML source, the task looked quite simple.
We felt that pain too, thats why we wanted to help you with something simple, that just works.
🥁 And so we baked for you https://doppio.sh, an API service that can convert HTML to PDF with a generous free tier. 🥁
With Doppio, you have an API that can scale to infinity to render PDF documents or screenshots, from HTML (source or url we fetch).
We also have some fancy sides, like asynchronous renders or file upload in your own object storage.
To make it simple our API parameters mimic the puppeteer documentation https://pptr.dev/api/
Beside performance and simplicity, it is also a way to make your CI/CD faster by removing the need to install that Chrome binary and its dependencies in your System/Dockerfile/Buildpack…
It is even more painful, when you have to quit something default to customize your environment to install it! 🙀
If you have any question about https://doppio.sh, you can hit us on support chat or check our documentation on https://doc.doppio.sh/
