How to make a user wait with Laravel

Question

I'm using Laravel 5.3 and I've built an application of which we can think of as sort of like an e-commerce app. I essentially want to allow the user to leave a review for their order, inside the application (not by email), but have them wait X amount of days after their purchase. Like eBay almost...

But what is the usual convention for creating a waiting period before a user can perform an action like this? I've been thinking whether I should set up cron jobs to send the user a request after X amount of days or perhaps by logging this in the database somehow, though I imagine that to be database heavy when having lots of users.

Any thoughts would be appreciated.

Update: The idea is to force a wait time upon the user. They can't leave a review until after the waiting period.

Answer 1

first you should create service for have commenting logic (for example just allow user comment his order after n day) ...

after it you can use queue for handle this action by this way :

after submit order you add a job to queue for N day later. it that job u can email user and say to him that he can leave comment for his order...

adding job to queue can be an Event or can be an listener on order model ...

for more information :

https://laravel.com/docs/5.4/providers

https://laravel.com/docs/5.4/queues

Answer 2

As I understand your use case, you need a persistent storage method to remember how many days have passed since the purchase of the item. There are, in general, 4 methods of persistent storage:

1. Cookies:

• Storage: Client Side (but secure since Laravel encrypts and signs all cookies)
• Specific: Unique to user machine and domain
• Persistence Time: Can last forever unless the user specifically deletes the cookie
• Common Use Cases: Saved preferences

2. Session

• Storage: Server Side (depends on driver)
• Specific: Specific to user (but depends on driver)
• Persistence Time: Usually expires in a couple of hours, but can be extended
• Common Use Cases: Persistence layer from one request to another (like shopping cart, popup notifications after action triggers)

3. Caching

• Storage: Server Side
• Specific: Generally application specific (but can be user specific)
• Persistence Time: Generally an hour to a couple of days
• Common Use Cases: Application specific storage use cases (e.g. total number of hits, most popular pages, database query caching, view caching)

4. Database

• Storage: Server Side
• Specific: Can be user or app specific
• Persistence Time: Forever until deleted
• Common Use Cases: Longer term data persistence layer (e.g. user details)

Now, if you want to send an automated reminder to the users after a couple of days of the purchase, the persistence layer has to be server side. That rules out cookies and also caching would not be a good method (since caching is best used for app specific data, not user specific data). But if you're looking for the review to be triggered by a user, I would suggest using cookies.

Needless to say, automated reminders need to be triggered by cron jobs.

In Summary:

• If you want automated reminders: use database + cron jobs
• If you don't want automated reminders: use cookies

Answer 3

I'd suggest a different design. You cannot know, really, when they've received their order, when they've opened it, used it, or enjoyed it. Maybe it was delivered next day and they used it immediately. Maybe it was delivered 7 days later and not touched for a week. You really need to accept both ends of this spectrum as legitimate. But I get that you don't want people reviewing orders they've not legitimately used. So here is my alternate suggestion.

Allow the user to submit a review at any time after purchase. They might submit a review 5 days, 5 hours, or even 5 minutes after ordering. What you limit, instead, is when the review becomes visible on your site. So you set a policy that says reviews are accepted at any time, but only visible 72 hours after package delivery. (Or any number of hours; you might even scale the number. Trusted users can see their review in 24 hours, but new users require 72.)

This approach simplifies the code you have to write: all you need to track is review submission date time, and limit the display of reviews based on said submission date time.