Body: <p>I am looking to queue my form submissions to be processed in the background.</p>
  
  <p>I want to be able to only keep user data in the system/database as long as required. This will mean keeping it to debug it if something goes wrong in the processing (SMTP error to send the email, store in database/google sheet, etc) </p>
  
  <p>As a bonus I figure queuing should mean faster success responses to users (rather than waiting for whatever processing is required), and can also throttle the processing if a form gets hit with lots of submissions in a short period (such as a competition).</p>
  
  <p>Looking for clarification if:<br>
  1. Using the Craft Job queues is best for this.<br>
  2. If should just use the default queue, or better to have a separate queue</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-05-21T12:51:08.770Z
Comments.Text: Keep in mind Jobs are only executed when someone enters the CP, as long as there is no valid CP user nothing will happen, that's why handling form submits in Jobs is not a good thing for fronend requests
Comments.UserDisplayName: Robin Schambach
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-05-21T13:13:31.443Z
Comments.Text: I was planning to setup a cronjob handle processing the queue more reliably.
Comments.UserDisplayName: sanscheese
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-05-21T13:17:45.807Z
Comments.Text: Then you can as well handle your requests via Cronjob from the beginning... I don't see any reason for a Craft Queue in that case. Queues are only "faster" because the function `App::maxPowerCaptain()` is executed before.. You can do that in your Cronjob as well
Comments.UserDisplayName: Robin Schambach
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-05-21T13:37:25.277Z
Comments.Text: Reason was thinking the queue to act a temporary storage. Being faster would be confirming the successful submission as soon as data received, compared to say after data is received, sent by email with SMTP and saved to a Google Sheet. So I could setup my own table to hold the data, and then process by a cron, but I was thinking it seemed to be following what a queue already does.
Comments.UserDisplayName: sanscheese
Tags: <form><queue>
Title: Is the Craft Queue suitable for processing form submissions?
ThreadText: # Is the Craft Queue suitable for processing form submissions?
  
  (Asked by: username_0 on 2018-05-21)
  
  I am looking to queue my form submissions to be processed in the background.
  
  I want to be able to only keep user data in the system/database as long as required. This will mean keeping it to debug it if something goes wrong in the processing (SMTP error to send the email, store in database/google sheet, etc)
  
  As a bonus I figure queuing should mean faster success responses to users (rather than waiting for whatever processing is required), and can also throttle the processing if a form gets hit with lots of submissions in a short period (such as a competition).
  
  Looking for clarification if:  
  1. Using the Craft Job queues is best for this.  
  2. If should just use the default queue, or better to have a separate queue
  
  **Tags:** form, queue
  
  > **Comments:**
  > **username_1**: Keep in mind Jobs are only executed when someone enters the CP, as long as there is no valid CP user nothing will happen, that's why handling form submits in Jobs is not a good thing for fronend requests  
  > **username_0**: I was planning to setup a cronjob handle processing the queue more reliably.  
  > **username_1**: Then you can as well handle your requests via Cronjob from the beginning... I don't see any reason for a Craft Queue in that case. Queues are only "faster" because the function `App::maxPowerCaptain()` is executed before.. You can do that in your Cronjob as well  
  > **username_0**: Reason was thinking the queue to act a temporary storage. Being faster would be confirming the successful submission as soon as data received, compared to say after data is received, sent by email with SMTP and saved to a Google Sheet. So I could setup my own table to hold the data, and then process by a cron, but I was thinking it seemed to be following what a queue already does.  
  
  ---
  
  ## 0 answers
  
  