11–20 of 95 posts
Earlier quoted context omitted.
It's using headless chrome, and there is a serverless version of chrome headless (chromeless), so it should be pretty scalable.
A chrome is a chrome... headless chrome uses almost the same resources as a desktop chrome (same engine and all that)
Unfortunately, the "sensible defaults" don't seem to check input URLs correctly and allow file:// URLs. Just try ?url=file:///etc/passwd on the demo instance. That seems to be a quite common issue with services like this built on generic libraries.
Earlier quoted context omitted.
A chrome is a chrome... headless chrome uses almost the same resources as a desktop chrome (same engine and all that)
Yes, but that doesn't matter in regards to the question "Is it scalable?" which OP asked.
[1]: https://url-to-pdf-api.herokuapp.com/api/render?url=https://...
Earlier quoted context omitted.
Yes, but that doesn't matter in regards to the question "Is it scalable?" which OP asked.
But its no scalable, making it serverless just makes scalable at a huge cost.
It is scalable. It scales linearly (and for practical purposes indefinitely) with the amount of money you spend on AWS Lambda. It might not have a nice constant factor, but it is scalable.
Unfortunately, the "sensible defaults" don't seem to check input URLs correctly and allow file:// URLs. Just try ?url=file:///etc/passwd on the demo instance. That seems to be a quite common issue with services like this built on generic libraries.
I wonder how scalable the service is... At least with PhantomJS I felt like my system would begin to lockup if there were too many instances rendering at the same time (and it didn't appear to be an issue of too little memory). Nonetheless, this looks promising.
You need to fire a new chrome headless process every time you create a PDF, its not scalable but it works. I wonder if this part of chrome could be easily extracted as a C++ library.
The PDF-ization isn't the part that's hard to extract (there are libraries to create PDFs from scratch already available, and they're small/intelligible). Rather, it's the rendering of a webpage for display that's the hard part, and what most of the code in any web browser is concerned with. Whether that display is a monitor or a PDF doesn't change much.