It seems that the headless Chrome version of the book renderer will take longer to render a book than OCG did.

This is not necessarily true (it maybe true, but we haven't checked that). We didn't compare headless Chromium to the current OCG backend. What we did was measure if it was possible to render books with thousands of pages and the answer was a "YES" (as opposed to a "NO" from Electron). This task is here because the proposed headless Chromium backend will have to lift the load of both ElectronPdfService and OCG, thus increasing the load on servers, which is why we think the render processes maybe slow. For example, if someone is rendering a 1000 page book, and another person initiates a one-article PDF render, then the second person may have to wait because the server is busy with rendering the book. We also suppose that the current Electron backend fails so much because jobs are not queued (needs verification from someone who knows the Electron backend well).

As for your workflow, it is JavaScript friendly, it won't work for non-JS users. I suggest once the user clicks on the download button, we take the user to a page where we show a message saying that the book is being rendered and a link will show up here. We then process to poll the backend every, say, 5 seconds and show the download link when it's ready. We'll also have a message for non-JS users to refresh the page to see an updated status message or the download link if it's ready.

In T176466#3627154, @bmansurov wrote:

It seems that the headless Chrome version of the book renderer will take longer to render a book than OCG did.

This is not necessarily true (it maybe true, but we haven't checked that). We didn't compare headless Chromium to the current OCG backend. What we did was measure if it was possible to render books with thousands of pages and the answer was a "YES" (as opposed to a "NO" from Electron). This task is here because the proposed headless Chromium backend will have to lift the load of both ElectronPdfService and OCG, thus increasing the load on servers, which is why we think the render processes maybe slow. For example, if someone is rendering a 1000 page book, and another person initiates a one-article PDF render, then the second person may have to wait because the server is busy with rendering the book. We also suppose that the current Electron backend fails so much because jobs are not queued (needs verification from someone who knows the Electron backend well).

Makes sense. I can make a correction in the description. I'm curious - do we know if this was one of the original issues with OCG? As in, was OCG failing while rendering single-page and books (prior to our deployment of Electron)?

As for your workflow, it is JavaScript friendly, it won't work for non-JS users. I suggest once the user clicks on the download button, we take the user to a page where we show a message saying that the book is being rendered and a link will show up here. We then process to poll the backend every, say, 5 seconds and show the download link when it's ready. We'll also have a message for non-JS users to refresh the page to see an updated status message or the download link if it's ready.

@Nirzar thoughts on this ^

Makes sense. I can make a correction in the description. I'm curious - do we know if this was one of the original issues with OCG? As in, was OCG failing while rendering single-page and books (prior to our deployment of Electron)?

Not sure. As you know we inherited these projects and I'm not too familiar with their histories.

Few ideas

Book is ready from user perspective

User taps Download

still creating

finished creating, browser download triggers

conditional extra messaging, if the number of pages is >30

same can be used with old UI

@bmansurov - do we have a way of estimating page numbers?

We won't know the exact numbers, but we can try and guess based on the HTML size. That won't be accurate though.

hmm...@Nirzar, @bmansurov - maybe the best thing to do then is to establish some sort of threshold for "large" and skip showing an estimate altogether to the user

That's what we agreed on. See the mocks from the description. Yeah, and if a book has more than 20 articles, or some number, then we can consider it large.

oh, nm, I was looking at the old mocks. ignore me.