I'm trying to access the nhost client from an external service (cloud run). I'm getting ECONNREFUSED and found some threads talking about different ways of innstantiating the client, either with backendUrl or subdomain/region. We are currently using backendUrl per this issue (https://github.com/nhost/nhost/issues/1055) but I'm not sure if that's changed. Do we need to switch to subdomain region to be able to access the client in production? The backendUrl has been working for local development.

if I understand correctly, you have some code running on cloud run that instantiates a nhost client to interact with your nhost cloud instance?

yes

i need things like ffmpeg, etc. so i can't use nhost serverless functions for everything until that is supported

so i'm trying to access the nhost client from cloud run. it's been working fine with both services running in docker and accessing the nhost instance with backendURL http://host.docker.internal:1337

but now that i'm trying to test live projects, the cloud run intsance gets a ECONNREFUSED from nhost when using backendURL: https://XXX.nhost.run

ok, yes, i just tried redeploying the cloud run instance using subdomain and region and it works now

is there any documentation about what i should use in what circumstances? backend url is a lot easier to use in many dev circumstances, esp when trying to use other docker services but it seems it's not supported in production?

backendUrl was suggested as a temporary solution because it works in all environments (web, cli, functions, etc), whereas subdomain and region introduced a bug when using the client in a function running on the cli. this has been fixed here https://github.com/nhost/nhost/pull/1051, we still haven't released, but we will soon

how would i be able to specify host.internal.docker using the subdomain?

since i have the nhost docker stack and i have separate docker services running, localhost won't work from the other docker services

what other services?

every other non-nhost service that makes up my app

similar to this issue https://github.com/nhost/nhost/issues/1088

for me i have typesense and this cloud run server that's in a docker container

probably pretty common for any reasonably complex app to have a number of other services that aren't part of nhost

you closed the issue and mentioned there are no plans to support anything within the cli, so i am just running a separate docker-compose for my other services. that works bc i am able to specify host.docker.internal as backendUrl when i need to access the nhost client from another service, but if i need to specify subdomain and region that would break

https://github.com/nhost/nhost/pull/1051 have a look at the hostedClient

const hostedClient = createClient({
  authUrl: 'auth.mydomain.io',
  storageUrl: 'storage.mydomain.io',
  graphqlUrl: 'graphql.mydomain.io',
  funtionsUrl: 'functions.mydomain.io',
})

is backendUrl going to be deprecated?

otherwise it seems easier to just try to detect if i am in a local docker setting and use the backendUrl instead of subdomain/region so i don't have to create each of these individual URLs as env vars

because i'm not self-hostnig

i'm just using nhost hosting

so in this example i would just pass authUrl: http://host.docker.internal:1337/v1/auth and so on for each param?

correct

I will make sure we update the docs here https://docs.nhost.io/platform/cli#subdomain-and-region when we release a new version

thanks, will try what you suggested

Had same issue with BackendURL being easier for local dev. And because we use a Staging project too, I ended up with other difference based on platform and finally just added MY_ENVIRONMENT env setting of "dev" | "staging" | "prod" to each for future proofing.

isLocalDev() || isStaging()
? { backendUrl: process.env.NHOST_BACKEND_URL } 
: { subdomain: process.env.REASON_SUBDOMAIN, // 'localhost:1337',
   region: process.env.REASON_REGION, // '' }

Wouldn't want platform detection to break one day.

agreed! sounds like backendUrl is going away sometime soon though

@Nuno Pato just to follow up on this, we're now getting consistent AxiosError: getaddrinfo EAI_AGAIN xxxx at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:107:26) errors on cloud run when trying to call storage.getPresignedUrl from the nhost client in cloud run

it does seem like there is some type of networking issue between external services and nhost. is there some configuration we're missing? the ECONNREFUSED issue was fixed by switching to subregion/domain, but this seems be new and consistent