Runtime redis configs

[Aracturat]

Now redis configs are fixed during build.

https://github.com/aidanhibbard/nuxt-processor/blob/main/src/module.ts#L52-L54

I want to have option to pass REDIS_URL in runtime.

[aidanhibbard]

Hi @Aracturat I think this is going to be a nuxt particular, because I'm just hooking the nitro build here.

When nuxt builds it bakes in the env vars, and we're just making use of the env vars provided from that build.

I don't think this is feasible, but I can look at it.

try NUXT_REDIS_URL?

[aidanhibbard]

Closing as this is controlled by Nuxt, we simply hook, and use the build so we can get access to application code. I don't really want to introduce a separate ENV reader.

[AzSiAz]

I know I am commenting on a closed issue but it's inlining redis connection code by using JSON.stringify and even NUXT_REDIS_URL can't override it at runtime anymore since it doesn't exist

I don't have enough of a nuxtjs background to be certain, but at last this what it look like when worker and server code is build and I search for NUXT_REDIS_URL in .output

[aidanhibbard]

@AzSiAz I'm re-opening just to discuss, sorry I missed this since it was a closed issue.

Can you describe the issue a little more for my understanding?

When nuxt builds, and we get the final bundle, those env vars are set.

Is the issue that the vars aren't reading from the process after build?

Do you want to be able to build in a CI that doesn't have those vars, then access the vars at runtime when the workers are deployed?

[AzSiAz]

Yes, exactly this scenario. If I build using those env var (or the default value) then they can't be overriden on runtime as of right now

I need to build a docker image without those env var as they could change in dev/staging/prod and building one image per env is not a good idea. Same thing for open source self hostable project where you just have no idea of what the actual redis url could be

[aidanhibbard]

@AzSiAz Thanks for the explanation, feel free to open a PR if you need it sooner, otherwise this is something I'll tackle this weekend.

[AzSiAz]

Unfortunately no time this weekend but I did make a fork with the change to use env var and another one to be able to only start specific worker you might be interested in

[aidanhibbard]

@AzSiAz Thanks, I'll take a look.

If you look at the latest release I implemented a flag --workers=worker1,worker2 that should allow you to start specific workers as needed. I didn't implement the "all except" like you did, I think just targeting specific workers is fine for now.

Let me know if it's the DX you were expecting, I'm very open to feedback here.

[AzSiAz]

Good enough for DX I think.

The reason I implemented the "all except" is because I have more than 10 workers, and I could split one or two of them outside the global "pool" as they are CPU heavy without having to list them all. All except also allow to not have to worry about updating config if I add more worker later on

But it's not a necessity and can be added later on if really necessary