Currently the backend saves a requested book's assets as files and then re-reads them to generate the final output pdf. The pdf is again stored on the backend as a file and passes the file's location to the front end for download. This creates a few problems:
-
The server can only generate one book at a time (two people entering the website will cause issues)
-
Adds unnecessary complexity to the backend.
Proposed solution: keep image data in memory without saving the png files to the server. And add unique identifiers for each request that will be used in the pdf output's name. This way multiple pdfs can be generated at the same time, returned to the end-user correctly and removed safely at the end of the transaction without conflicting with other requests.
Currently the backend saves a requested book's assets as files and then re-reads them to generate the final output pdf. The pdf is again stored on the backend as a file and passes the file's location to the front end for download. This creates a few problems:
The server can only generate one book at a time (two people entering the website will cause issues)
Adds unnecessary complexity to the backend.
Proposed solution: keep image data in memory without saving the png files to the server. And add unique identifiers for each request that will be used in the pdf output's name. This way multiple pdfs can be generated at the same time, returned to the end-user correctly and removed safely at the end of the transaction without conflicting with other requests.