Hello support,
I’m trying to find a way to pass my custom keys to the process.env variable. Something similar like dotenv works in Node.js.
I noticed at the default ‘coderunner.json’ contains two required keys (id and apiKey):
Is it possible to extend the config to define “my-custom-key” will be available during the code execution of the Cloud Code service?
Any other alternative to achieve the same behaviour?
Thank you!
Is it possible to extend the config to define “my-custom-key” will be available during the code execution of the Cloud Code service?
Any other alternative to achieve the same behaviour?
Could you please clarify exactly what you mean by that?
Perhaps an example of how you plan to use this approach would also be helpful.
Please notice, I typed a pseudo code, I understand, that third party packages include in other way for Cloude Code. The general idea is simple. I need custom keys in runtime, in the service code execution context, I don’t wan’t to hardcode them, store in the repo or the DB.
I’m looking for the possibility to use GitHub - motdotla/dotenv: Loads environment variables from .env for nodejs projects. in Cloud Code services.
Does it make sense?
Thanks!
Unfortunately, JSON can’t get the values of the environment variables and I have no idea how to get around that yet.
As for the second question, I need more time to research.
Actually, my second question is related to the first one. As far as I understand, you pass at leas app-id and apiKey to process.env variable through the internal pipeline.
Are you sure Backednless can’t do the same thing for my custom env. variables? Otherwise, how do you solve such a common case?
The coderunner.json file just describes what and where you are going to publish, it means it’s just a reference between your local code and your Backendless app in the Cloud. We do not use the file in runtime that’s why you can not use any properties from the file in runtime.
According to the process.env:
you can have an env.json file and use it anywhere in your cloud code
Hi @vladimir-upirov,
Thank you for the reply. I understand, what you meant. But the general idea of .env files:
Values store in it are environment-dependent (staging/dev/prod/etc)
They aren’t committing to the source code control system (security reasons)
Usually, they don’t persist at the destination server
Values are available within the current process of node (I/O operation from the file versa heap reading)
Is there another way to write custom keys to process.env variable I should have access to, in any execution of Cloud Code function?
Alternativly, is there a way to define custom keys in the Web console (let’s say application settings), will be available in runtime like e.g. Azure has?
you can write a simple js script which can read the file necessary file and create a json file with for the required env, and then instead of running npm run deploy you can run your script first and then deploy the code
using .gitignore you can ignore any file including your env.json
agree, we’ve got a similar solution, see an example in the next comment
to read a small file once (and then use it from the memory) will not take too much time, but I agree with using env will be much faster. However, it will work only in case when you run a process once, in the case of our architecture each task runs in a new separated process and when it’s done the system kills the process to make room for a new task. The exception is Pro and Manage installation where you are able to enable workers cache to keep processes alive as much time as you need
Hi @vladimir-upirov!
Finally, I set up the service by the way you suggested.
Now, I stuck with timers. I didn’t find a way to pass a custom key or retrieve it from a service. Researching the documentation, I found the following example:
/**
* CoolTimer timer.
* It is executed according to the schedule
*/
Backendless.ServerCode.addTimer({
name: 'CoolTimer',
startDate: 1491929303000,
frequency: {
schedule: 'custom',
repeat: {'every':120}
},
/**
* @param {Object} req
* @param {String} req.context Application Version Id
*/
execute(req){
Backendless.Data.of("TimerLog").save( { timerContext: JSON.stringify(req) })
}
});
The first notice is req parameter. In my case it contains only an empty object: {"context":{"httpResponseHeaders":{}}}, but not like you said in the page: * @param {String} req.context Application Version Id
The question is, how to pass a custom context to a timer execution body?
Or is there a way to configure it settings like I did for a service?
Thank you!
you do not call the timer manually, the system call it. So you can not provide any args, but you may call DB or Backendless cache from time, so you will able to change the arguments for the timer
Hi @sergey.kuk!
Thank you for the reply. The main issue is that I need an API key of a third party service in the timer execution function. I set it to to the service configuration (because I need the key in the service as well).
So, is there a way to read that key (service config) from the timer context? Something like that: execute(req) { Backednless.Service.get('MyService').config.key }
Othewise, I’m not sure how reliably it would be save the key in memory DB, let’s say on service startup. What if the timer executes before the service was started?
I don’t want to store that key in the persistence storage because that is not the right place for such type of sensitive data.
Thank you!
Hi @vladimir-upirov,
I haven’t been following your updates closely, but noticed, that you were hard working on the platform development.
So, the question is anything has changed in the environment variables term since last year?
FYI: @mark-piller
Thanks!
No, there haven’t been any changes in the environment variables setup for timers and event handlers since last year. Unfortunately, there is still no way to configure items directly for timers and event handlers.
