Open hbcondo opened 4 years ago
Plain Java is not a good fit for serverless. Takes long to start and consumes a bit more memory. You can run it in serverless via GraalVM and native image compilation. However I don't know if openhtmltopdf has been tested on top of GraalVM with native image. GraalVM native compilation has some restrictions regarding reflection.
If you do some work in this area - openhtmltopdf to native using GraapVM please share your results.
Hi @hbcondo,
I have just launched my fledgling website and the backend uses Azure Functions. I chose Azure compared to Amazon Lambda because Azure has a 100MB upload limit for HTTP requests vs about 6MB for Lambda, which could be useful for image and other upload.
On the plus side, it is effectively free for low level usage and I didn't have to take special steps to get things working (except for file upload). I used the VS Code Quickstart on my Windows machine and it was mostly plain sailing.
On the bad side, you can have a look at the price list creator, which uses Apache POI (Excel reading), Thymeleaf (HTML template) and this library, and you'll notice that as @ieugen alluded to, cold start up time is very very slow. I measured about twenty seconds vs a couple of seconds when it is warm. It should be noted that Azure offers a couple of other pricing models for Functions, both of which eliminate cold starts albeit for extra money.
My take is that Azure Functions with Java may be usable for free offerings (or background queue processing) but not paid offerings where the customer expects a quick response. In this case, you need to upgrade the Functions pricing plan or move to a conventional server approach.
Native image poc:
https://github.com/danfickle/openhtmltopdf-native
Anyway, for those interested in native-image continue discussion in #691.
Is anyone running openhtmltopdf in a serverless environment, such as on AWS Lambda or Azure Functions? If so, could you provide some guidance on the steps you took to accomplish this? Thank you.