access token to be generated daily with cron

Hi there, I need some help.

I have two questions, actually. I found this guide Crontab with Supercronic · Fly Docs
And the community posts that talk about it, but one question was actually asked in one of the posts, but never answered.

1 - I’m on the hobby plan. If I use this service, will there be additional charges just for the use of it?

Other thing is that the guide shows me how to run this job, but I am using an app that needs to access an api for which I have a client id and client secret, and need to use them to generate at maximum five access tokens to the api per day. I am not being able to find another way to make it so that the script runs only once per day, so I wanted to know,

2 - Is there any way to use the cron to run this GET request and store the access token somewhere that the rest of the app can use it? I thought of storing it in an env, but I’m not sure if setting a value through a script would make it a persistent value.

I thank in advance for any help

1 - I’m on the hobby plan. If I use this service, will there be additional charges just for the use of it?

The guide you reference is just an explanation of how to run cron in a container on Fly. It’s not a separate service. Therefore, you will be charged for compute. For a full idea of what charges might be incurred, see our pricing page. Ultimately, the additional cost depends on what resources are used (CPU & RAM). Referring to the guide, it suggests running a single VM for the cron process. So you will be charged for usage of this VM, according to our pricing.

2 - Is there any way to use the cron to run this GET request and store the access token somewhere that the rest of the app can use it? I thought of storing it in an env, but I’m not sure if setting a value through a script would make it a persistent value.

Is the access token long-lived? If so, it might be best to create it outside of your app and then do fly secrets set ACCESS_TOKEN=your_access_token. If it’s short-lived and you need to have your app generate it on the go but you want all of your VMs to use the same token, then you’re probably going to have to deal with a number of problems discussed here. The simplest thing to do is probably to use something like Redis.

Hi there, thanks for the response!
So, the workflow I need is like this:
There is a website in which this app I’m hosting (it’s a Shopify app) is installed. In this app, the customer can select properties of a product, then, a request is sent to a page of the app that is hosted, and, using the properties chosen, the app needs to use them and an access token to get the actual price from other api.
The access tokens last for a day and I can create up to 5. I tried setting an utils js file apart to store the token, but it doesn’t work, since when the machines stop as use stops, when they get on again, they reset the file, and lose the updated value.
How can Redis help exactly? How does it integrate with Fly Io? I only got in touch with it working with Magento, I don’t know much about it

I tried setting an utils js file apart to store the token, but it doesn’t work, since when the machines stop as use stops, when they get on again, they reset the file, and lose the updated value.

Yes, unless you use Fly Volumes, storage is ephemeral and you won’t be able to retain data between machine starts. If you only ever intend to have a single VM, then using a volume might be the simplest approach - you can save your token somewhere in the volume and it will be durable to machine restarts.

But if you want to scale your app beyond a single machine, you need a way to share the token amongst all the machines, and volumes aren’t the most suitable.

How can Redis help exactly?

Redis can act as a shared store. So you would generate an access token, store it in Redis and then all your worker machines query Redis when they need the token. Again, this suffers from the problems mentioned in the post I linked above.

How does it integrate with Fly Io?

We offer Upstash for Redis as an easy way to get going. You could also try running your own if you’re so inclined.

Thanks a lot!
I believe that the issues mentioned in the post don’t affect me as much, since it’s a small app, it won’t need much scalability. As I’ve seen, upstash as a free option for simple apps, right? I will go with that option. Thanks for the run through, really

Unfortunately it didn’t work :confused:
I tried using upstash instructions themselves

const redis = require("redis");
              
var client = redis.createClient ({
  url : 'my-url.upstash.io',
  port : '6379',
  password: '********'
});

client.on("error", function(err) {
  throw err;
});

client.set('foo','bar');

but everytime I try to do it, I just get this error in the deploy logs

WARNING The app is not listening on the expected address and will not be reachable by fly-proxy.
You can fix this by configuring your app to listen on the following addresses:
  - 0.0.0.0:3000 for job

(3000 is the port that my docker and fly.toml are set. I tried changing to 6379, which is apparently the port that uptsash is, but then the log changed, but the error continued, in the logs from the monitoring from dashboard saying that there is an invalid url somewhere)

At this point, since it’s a simple app and with not that many requests, but in which I really need the data to persist daily, I believe I will need to resort to just leave the machines always on, and hope for the best

Okay obvious question first just in case: is your server listening on 0.0.0.0:3000?

This isn’t a problem with Redis. I don’t think there’s a problem with your fly.toml - you’re getting this warning so it’s expecting something to be listening on that address, but it isn’t finding anything.

As I said before, 3000 is the port that my docker and fly.toml were set. Or is this server port something that I need to set somewhere else? I’ve tried looking at some settings, but I couldn’t find a way to change the port of the redis, so, I tried changing the docker and fly.toml port to the redis one, got this error above with the redis port, and changed it back, and then got this error with the 3000 port

Your fly.toml determines what ports are exposed to the outside world. But your server application still needs to actually be listening on the relevant port and hostname. A common misconfiguration is to be listening on localhost instead of 0.0.0.0.

An example with Node:

const hostname = "0.0.0.0";
const port = process.env.port || 3000;

app.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});

My guess is you don’t have your application configured to listen on the correct port. flyctl is telling you that it’s expecting something to be listening on port 3000 - because you told it there would be something listening on that port in fly.toml - but it can’t find anything.

Have you had a looks at the docs about this? They might be useful: Listening Ports · Fly Docs.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.