Thank you for this as this is exactly how its implemented in a recent project of mine.
I didn't want to put unneeded information in the first post but here i have some space ;)
What I ended up doing was:
- two sqs queues, one for processing one for failures after 3 tries
- the go backend reads from its queue and the message contains a json object with all the information needed for pdf generation
- the backend posts the file back to the "internal api" of the application, which saves it in s3 and also sets processing to true which means the user can go and download it.
This results in:
- my pdf generated the way i want it (sorry i dont actually make stardust)
- the queues are only reachable through the assosiated iam roles
- if a job failes it will be added to the failed queue, which sends me an email
- if i recieve an email by the failed queue, 90% of the time i have found another edge case
- since the message already contains everything that i need to build the pdf, my edge case has just defined itself
- for the postback i supply an api token that is only valid for that one file
All this means my client has total flexibility in deployment.
I didn't want to put unneeded information in the first post but here i have some space ;)
What I ended up doing was:
This results in: All this means my client has total flexibility in deployment.