Support for an Async Api

[drusellers]

Has there been any discussion around building out an Async version of the API. On my first pass through the using the tool, I'm trying to make HTTP calls inside of the IDocument to get image data for example. It would be nice if the IDocument methods were Task so I could do async calls inside them.

I simply pulled that code out and passed the realized data in to get past this.

None-the-less, I would be interested to understand what the plan is moving forward.

TY

[rverberne-carapax]

Running into this as well

[girlpunk]

As the PDF generation is almost entirely synchronous and CPU-bound, making the API async would give little gain (and likely a decrease in overall performance). As such, the recommended way to achieve what you're looking for is to fully populate your model (including all relevant HTTP calls, etc) before instantiating your IDocument implementation, calling GeneratePdf, etc.

[rverberne-carapax]

Prepopulating the model is the best way, i agree. But what about very large documents, with dynamic images? Now you are required to load and keep everything in memory at once.

But i may know why it's not possible, as the layout enginge re-renders multiple times the same content to fit everything, this would repeat the async calls and could have different results each time... (This is atleast true for dynamic components) But correct me if i am wrong.

[girlpunk]

Loading everything into memory would still be required, as QuestPDF makes at least two passes over the document in order to render it. The images, etc, would need to be in memory for both passes. In addition, differing content between the two passes could cause significant problems for both rendering the document, and troubleshooting any problems during the render process.