Is this the frontend URL you are referring to? https://wapaganda.subjective.agency/

Because this works well on my end.

What do you see in the Network tab? This is what I see:

A client's browser can not make requests to the private domain, it would not be a very private network if you could do that.

You need to use the public domain in this case.

For more information, please read these sections -

https://docs.railway.app/guides/private-networking#private-network-context

https://docs.railway.app/guides/private-networking#faq

Just to be clear, I imagined this as a kind of iceberg with a small part visible above water but most of the stuff goining below. That there is a public website that is just frontend and pretty much nothing more, and it can connect to a backend via a private network when a user is making requests. For example, the user clicks a button "show baloon", <private networking starts>the frontend makes request to backend, the backend runs script "show_balloon.py", sends results to the frontend<private networking ends>, which then displays it to the user.

In Private network context it says A web application that makes client-side requests cannot communicate to another service over the private network.

Now I don't think I understand what a usecase for Railway private networking might be.

sorry for double post, no idea how that happened

Now I don't think I understand what a usecase for Railway private networking might be.

Service-to-service communication on the backend, service-to-database communications.

You have a client side rendered site, meaning any requests the website makes is done via the user's browser, the user's browser only has access to public domains, the private domains are only available to code that runs within the context of the private network, not in the context of a user's computer / web browser.

Your website needs to use the public domain for any requests it makes.

Service-to-service communication on the backend, service-to-database communications

Ok, different sevices can communicate with each other on the backend, but then neither of them can be accessed from outside that private network... Right? So what's the point of such setup?

I'm sorry but I never said they can't be accessed publicly.

How did we get to that conclusion? it's simply not true.

Well, I think I assumed that because we have just talked about a frontend service that cannot access a backend service via private network while being publicly accessible at the same time. What am I missing here?

As previously discussed, a user's browser can not access the private domain, it would not be a private network if anyone's web browser could call the private domains.

Again, your client side rendered site needs to call the public domain.

Please take a moment to read over my messages again as I've explained this to the best of my abilities already.

Ok, just to make sure that I successfully deciphered your clues: a service can be accessed via both private and public domains, unless it's a web browser, because security. Is that correct?

Not because of security, but because of basic networking fundamentals, for example, can you open your friend's localhost in your web browser? (You can't)

And it's not limited to web browsers who can't access the private domains, anything that doesn't live within the context of a given private network can not access any resources over the private network.

I'm confused. On the one hand, you sayanything that doesn't live within the context of a given private network can not access any resources over the private network , on the other, younever said they can't be accessed publicly.

Is it, or is it not possible to access a service via a private network (by some other service) and via public domain (by something else) at the same time?

You can not access a service via the private domain publicly. Keywords: Private domain.

If you need to access a service publicly you need to use the public domain.

Thank you. Finally, it's all clear.

Except, of course, for why would I want to use railway private networking feature.

But, anyway, using https indeed works fine.

For service-to-service communication, or service-to-database communication, since it's going to be faster and not charge you for bandwidth.

Wow @brody. Congratulations on your patience...

I'm going to weigh in on this discussion, since it is public and can be of help to other users landing on this discussion, because my question is related.

I have configured my frontend nextjs app with 2 env vars for accessing my backend api:

API_URL=http://${{backend.private_domain}}
NEXT_PUBLIC_API_URL=https://${{backend.public_domain}}

This is because the frontend can access the backend api both on the client as on the server, and I wanted to make use of the private domain server side.

My first question:

Is it correct to configure the private domain access of the backend service using http protocol? (since I dont need encrypted requests on this private network). Moreover, is https just not available on the private network?

My second question:

When using the private network access to the backend service from the nextjs server, I get conection refused errors. When using the publick_domain using https, it just works fine.

I presume this is because of CORS settings on the backend service. I dont see any incoming http requests on the backend when trying to access it using the private domain.

For testing purposes, I have set the CORS configuration on the backend service as open as possible, without any luck:

...
.use(
  cors({
    origin: '*'
  })
)
...

What am I missing? Why are my connections to the private domain being refused?

Thanks for your help!

You didnt think brody was patient with you then?

I think brody failed to demonstrate how the feature is supposed to be useful. Your pathetic insult is completely uncalled for.

Sorry, if I hurt your feelings. I wasn't trying to insult you. I was trying to congratulate someone, who I think was doing a great job. I try to be positive in my communication. Sorry if you felt it differently.

I think I covered that topic pretty well, it's so a service can connect to the database privately without having to go across the public network, this allows faster communications, and saves on egress fees.

> Is it correct to configure the private domain access of the backend service using http protocol? (since I dont need encrypted requests on this private network). Moreover, is https just not available on the private network?

Correct, HTTP only, it's a local network so no SSL is involved on our side, and there's no need to, the private network is an encrypted wire guard tunnel.

> When using the private network access to the backend service from the nextjs server, I get conection refused errors. When using the publick_domain using https, it just works fine.

This is likely because the backend service is not listening on IPv6, that's an issue since the private network is IPv6 only, please see our docs on this topic, examples included! -

https://docs.railway.com/guides/private-networking#communicating-over-the-private-network

> I presume this is because of CORS settings on the backend service. I dont see any incoming http requests on the backend when trying to access it using the private domain.

CORS is specific to the browser and does not apply to backend services.

> What am I missing? Why are my connections to the private domain being refused?

Listening on IPv6 most likely, but you also need to specify the port in the URL.

----

If you have any more questions, please open your own thread.

It tells me nothing about how it should be used with Railway, therefore it is useless. You laid down a basic description of the technology, and that's it.

I think I mentioned it a few times, apologies if I didn't, but the private network is used to connect a service to a database privately, or connect services to each other privately.

I'm not sure what else I can say at this point, sorry.

Jesus, man. Do you not know the difference between "what" and "how"? Anyway, if you believe that you provided sufficient assistance in this case, keep believing.