Forums

Hi All, I know that webapps can not use threads or something such as celery. As well I know sending the emails from the request is an option, though not a good one if many emails need to be sent. I have a solution below that I was planning to implement for my app (Flask App), and was wondering if anybody would be willing comment to on it, good or bad idea, alternative options, etc.

Technicians, when going to buildings enter their time and work performed in that building, and customers can log in and see the work being done in there buildings. I am wanting to implement a feature that emails the new work logs to the customer either daily or weekly. My Solution for this was:

• add a boolean field named approved to the work_log model
• add an email table to the db
• have a flask command (so i have app context ,db, etc) scheduled to run daily that collects all logs that are not approved.
• send an email with logs that need approving, and signed/timed (token) link that also contains the ids of the logs to administrator if any logs need editing ,they can be edited from admin panel before clicking the link
• the route that corresponds to token/link would mark off all the logs approved and populate the email table based off the approved logs
• a separate daily task would send emails from the email table then either delete them or mark them as sent

Thanks in advanced for any suggestions or ideas!

what are the fields in your email table?

Hi Conrad, I haven't implemented that yet, but my thoughts were to include the customer email, and then the message body consisting of html (to display the logs in a table). As well possibly a boolean indicating sent, if I decided not the delete the email from the table after it is sent.

Hi Conrad, I haven't implemented that yet, but my thoughts were to include the customer email, and then the message body consisting of html (to display the logs in a table). As well possibly a boolean indicating sent, if I decided not the delete the email from the table after it is sent.

ok- the daily tasks plan sounds reasonable- can't poke any holes in it.

The only hole I can see is that if a lot of logs are being approved at one time, there would be alot of database access during the request. This would be fine for the administrator who clicked on the link to approve then, but would that tie up the app from responding to other requests?

It could do. When a request comes in for a page on your web app, it's put on a queue. At the other end of the queue are your worker processes; when they're available, they take a request off the queue, process it, then go back to looking at the queue. It's basically the same model as many banks often use in the real world, where you have a single queue and multiple cashiers.

So if one of your workers is handling a request that takes a long time, if the other workers are handling normal requests that can be handled quickly, everything should be OK -- there might be a bit of a slowdown, but not much. In the bank metaphor, this is when one customer comes in with a time-consuming transaction, but the others are just doing normal short transactions. But if all of your workers are handling long-running requests, then there can be problems. Maybe this second case maps reasonably well to a situation in a bank where local businesses that operate in cash all close for the day and all send people to the bank to deposit the day's takings at the same time, so the queue gets long. The best solution to that is to increase the number of workers.

You can see how many workers your web app has on the "Account" tab if you click the "Customize your plan" button.

Thanks for response and explanation Giles, this should work for us.