How i can call the function 24 hours after the first call in node.js?
Or 24 hours after the execution of a specific request to this node.js server?
And execute it with the same parameters
(function must sent email to user)
I think this is a much bigger question that might be dependent on the type of architecture you have. The simple answer is to investigate some sort of scheduler, or cron task, however the better solution might be to distribute these systems and setup some sort of messaging system live Rabbit MQ.
When the first function runs, you can send a message via rabbit to the system that handles emails and run this much later, thereby reducing the load on the original system, or protecting it if it goes down.
Related
This question already has answers here:
How would I get a function to run every 24 hours on a server?
(2 answers)
Closed 2 months ago.
What is the best way to handle a function that needs to run every 24 hours at a specific time?
let's say we have an application that pays people for a service that they provide during the day. we already stored the amount of work they did for the day and it's time to pay up.
we want the system to automatically pay (let's assume we toke care of this) them every day at 00:00.
what is the best way to do this?
I'm planning to ask the backend to calculate the remaining time to 00:00. then run our payment function after that time and that function runs itself every 24 hours
A: Is this a good way to handle things? & Is it scaleable?
B: What is the best way to do it in node.js? (I know how to work with the node built-in functions, but I'm not that great with algorithms I'm not sure if using setInterval is ok or not)
ps: other questions suggested using corn jobs that I'm already familiar with, I'm not looking to use any package I'm trying to do it by myself. in fact, I know how to do it myself, I'm just trying to know what is the best way to do it. this is not a project that I want to do for a client. this is a practice.
If you want to execute a function every X time or at a specific time, you should check cron jobs.
You have multiple ways to handle cron jobs. If you want to deploy a "quick" PoC, you can check websites (like easy cron) that permits you to call a URL (and by extension a function) with a cron expression (everyday, every month, etc...).
Or you can use some node packages, you will find on the npm index.
Check utilizing cron, cron is a job scheduler. You have many differents options about date,time etc.
I want to measure the time it takes for a user to complete a task (answer a quiz). I want to measure it accurately, without the network lag. Meaning, if I measure on the server side the time between 2 requests, it won't be the real time it took the user, because the network time is factored in.
But on the other hand, if I measure in javascript and post the timestamps to the server, the user will be able to see the code, and cheat by sending false timestamps, no?
How can I get the timestamps in javascript and make sure the user doesn't fake it?
Generally in client side code, any question that starts off with "How to securely..." is answered with "Not possible". Nothing, not even putting variables in a closure (because I, the evil cheating user could just change the code on my end and send it back to you).
This is the kind of validation that should be performed server side, even with the disadvantage of network latency.
The trick here would be to measure the time using JavaScript, but also keep track of it using server-side code. That way, you can rely on the timestamps received by the client as long as you enforce a maximum difference between calculated times. I'd say a few seconds should be good enough. However, by doing so, you are creating an additional vector for failure.
Edit: A user could potentially tweak his or her time in their favor by up to the maximum enforced difference if they are able to take advantage of the (lack of) network lag.
I faced same problem while designing an online examination portal for my project.
I went for a hybrid approach.
Get time from server as user loads the page, and starts timer based on javascript. Record the start time in your database.
Let the timer run on client side for some time, say 30 seconds.
Refresh timer by making a AJAX call to server for timer reset as per the time that has passed already.
NOTE: try to use external javascript and obfuscate the code of timer to make guessing difficult.
This way you may not prevent user completely from modifying timer, but you can limit max possible error to 30s.
Is it possible on Firebase or Parse to set up something kinda like a cron job?
Is there a way to set up some sort of timed operation that runs over the stored user data?
For example, I'm writing a program that allows people to RSVP for lunch everyday. If you have RSVPed by noon, then you get paired up with somebody else who has also RSVPed. Using JavaScript, the user can submit their RSVP in the browser.
The question is, can Firebase/Parse execute the code to match everyone at 12:00pm every day?
Yes, this can be done with Parse. You'll need to write your matching function as a background job in cloud code, and then you'll need to schedule the task in the dashboard. In terms of the flexibility in scheduling, it's not as flexible as cron but you can definitely run a task at the same time every day, or every x minutes/hours.
Tasks can take 15 mins max to execute before they're killed, so depending on the size of your database or the complexity of your task, you may need to break it up into different tasks or make it resumable.
Just to confirm about Firebase:
As #rickerbh said, it can be done with Parse, but currently there is no way for you to run your code on Firebase's server. There are 2 options for you 2 solve this:
You could use Firebase Queue and run your code in Node.js
You could use a different library such as Microsoft Azure (I still haven't tried this yet, I'm not sure if it provides Job Scheduling for Android)
However, Firebase is working on something called Firebase Trigger, which will solve our problem, however it is still not released with no confirmed release date.
I have just stepped into the world of Web Development, and I am developing a small browser game that simply allows connected users to take control of an object (a triangle currently!), and simply move around the screen area.
Currently, I store the clients co-ordinate position in a MySQL database, and update that position using AJAX, roughly 30 times per second.
Other clients positions are also polled roughly 30 times per second.
My problem however, is that this seems to be causing an hour long IP lockout for the client, which I assume is automatically occurring on my Host's end. Would this perhaps be a normal default precautionary action? I was under the impression that 30 AJAX polls in a second was not a particularly stressful amount, however as I mentioned this is a new field for me. I'm fearful I've created some miniscule DOS attack!
If so, I would be grateful if someone with experience in this matter could point me to a more efficient method of handling the kind of interactivity I have described. This is all leading up to a six-month project I will be working on alone for my final year University project, so I'm more than happy to put the extra hours in to learn a better solution.
What you should do is known as "hybrid-polling". Basically you have a long running method server side which is running an "infinite" loop which runs once every 33ms (30 times per second). This loop will shoot data out to a part of your front end if the data has changed. When the data gets to be too large in the buffer for the method to handle, the method exits. The whole time your client is polling to see if new data was written. If the method exits, the client must restart the method. This is a hybrid approach, where the client polling is only checking client side data, except when the method exits, in which case the client must poll again to restart the server method, which then runs once every 33ms and pushes data out to the client.
Look up Comet (compatible with older browsers but not as efficient as possible), BOSH, or Web Sockets (ideal but not compatible with older browsers) for other approaches.
It's a simple case of a javascript that continuously asks "are there yet?" Like a four year old on a car drive.. But, much like parents, if you do this too often or, with too many kids at once, the server will buckle under pressure..
How do you solve the issue of having a webpage that looks for new content in the order of every 5 seconds and that allows for a larger number of visitors?
stackoverflow does it some way, don't know how though.
The more standard way would indeed be the javascript that looks for new content every few seconds.
A more advanced way would use a push-like technique, by using Comet techniques (long-polling and such). There's a lot of interesting stuff under that link.
I'm still waiting for a good opportunity to use it myself...
Oh, and here's a link from stackoverflow about it:
Is there some way to PUSH data from web server to browser?
In Java I used Ajax library (DWR) using Comet technology - I think you should search for library in PHP using it.
The idea is that server is sending one very long Http response and when it has something to send to the client it ends it and send new response with updated data.
Using it client doens't have to ping server every x seconds to get new data - I think it could help you.
You could make the poll time variable depending on the number of clients. Using your metaphor, the kid asks "Are we there yet?" and the driver responds "No, but maybe in an hour". Thankfully, Javascript isn't a stubborn kid so you can be sure he won't bug you until then.
You could consider polling every 5 seconds to start with, but after a while start to increase the poll interval time - perhaps up to some upper limit (1 minute, 5 minute - whatever seems optimal for your usage). The increase doesn't have to be linear.
A more sophisticated spin (which could incorporate monzee's suggestion to vary by number of clients), would be to allow the server to dictate the interval before next poll. The server could then increase the intervale over time, and you can even change the algorithm on the fly, or in response to network load.
You could take a look at the 'Twisted' framework in python. It's event-driven network programming framework that might satisfy what you are looking for. It can be used to push messages from the server.
Perhaps you can send a query to a real simple script, that doesn't need to make a real db-query, but only uses a simple timestamp to tell if there is anything new.
And then, if the answer is true, you can do a real query, where the server has to do real work !-)
I would have a single instance calling the DB and if a newer timestamp exists, put that new timestamp in a application variable. Then let all sessions check against that application variable. Or something like that. That way only one innstance are calling the sql-server and the number of clients does'nt matter.
I havent tried this and its just the first idéa on the top of the head but I think that cashe the timestamp and let the clients check the cashe is a way to do it, and how to implement the cashe (sql-server-cashe, application variable and so on) I dont know whats best.
Regarding how SO does it, note that it doesn't check for new answers continuously, only when you're typing into the "Your Answer" box.
The key then, is to first do a computationally cheap operation to weed out common "no update needed" cases (e.g., entering a new answer or checking a timestamp) before initiating a more expensive process to actually retrieve any changes.
Alternately, depending on your application, you may be able to resolve this by optimizing your change-publishing mechanism. For example, perhaps it might be feasible for changes (or summaries of them) to be put onto an RSS feed and have clients watch the feed instead of the real application. We can assume that this would be fairly efficient, as it's exactly the sort of thing RSS is designed and optimized for, plus it would have the additional benefit of making your application much more interoperable with the rest of the world at little or no cost to you.
I believe the approach shd be based on a combination of server-side sockets and client-side ajax/comet. Like:
Assume a chat application with several logged on users, and that each of them is listening via a slow-load AJAX call to the server-side listener script.
Whatever browser gets the just-entered data submits it to the server with an ajax call to a writer script. That server updates the database (or storage system) and posts a sockets write to noted listener script. The latter then gets the fresh data and posts it back to the client browser.
Now I haven't yet written this, and right now I dunno whether/how the browser limit of two concurrent connections screws up the above logic.
Will appreciate hearing fm anyone with thoughts here.
AS