Render Disobeying Port, or Other Issue?

1

All right so I am trying to run both React and Rails on the same service using different ports. The runtime is ruby, per a tech support suggestion. I am getting an un-numbered invariant violation on the front end, and nothing is being fetched from the back end at all so i suspect that Rails isn’s even running. I is callling the react controller when it should only ever be hitting the GraphQL controller.

==> Docs on specifying a Node version: Setting Your Node.js Version | Render Docs

==> Running ‘bundle exec puma -t 5:5 -p ${PORT:-5000} -e ${RACK_ENV:-production}’

Puma starting in single mode…

  • Version 3.12.6 (ruby 3.2.2-p53), codename: Llamas in Pajamas

  • Min threads: 5, max threads: 5

  • Environment: production

==> Detected service running on port 10000

Your service is live ![:tada:](

[3db7527c-9721-4bbe-b6d7-ed2682add240] Started GET “/static/js/main.2063b05d.chunk.js” for 172.69.135.117 at 2024-02-23 19:15:55 +0000

[3db7527c-9721-4bbe-b6d7-ed2682add240] Processing by ReactController#index as JS

[3db7527c-9721-4bbe-b6d7-ed2682add240] Parameters: {“path”=>“static/js/main.2063b05d.chunk”}

[3db7527c-9721-4bbe-b6d7-ed2682add240] Rendering public/index.html

[3db7527c-9721-4bbe-b6d7-ed2682add240] Rendered public/index.html (Duration: 0.1ms | Allocations: 11)

[3db7527c-9721-4bbe-b6d7-ed2682add240] Completed 200 OK in 7ms (Views: 1.2ms | Allocations: 964)

[5fb9bb81-37dc-44e6-beea-b5ae0181457f] Started GET “/static/js/main.9dbd92c6.chunk.js.map” for 172.69.134.181 at 2024-02-23 19:16:13 +0000

[5fb9bb81-37dc-44e6-beea-b5ae0181457f] Processing by ReactController#index as

[5fb9bb81-37dc-44e6-beea-b5ae0181457f] Parameters: {“path”=>“static/js/main.9dbd92c6.chunk.js”}

[5fb9bb81-37dc-44e6-beea-b5ae0181457f] Rendering public/index.html

[5fb9bb81-37dc-44e6-beea-b5ae0181457f] Rendered public/index.html (Duration: 0.1ms | Allocations: 4)

[5fb9bb81-37dc-44e6-beea-b5ae0181457f] Completed 200 OK in 1ms (Views: 0.5ms | Allocations: 219)

  • Gracefully stopping, waiting for requests to finish

=== puma shutdown: 2024-02-23 19:16:40 +0000 ===

  • Goodbye!

Here is my repo: GitHub - genxhero/swyle: A site for blogging and snarking using GraphQL, Apollo, React, and Rails 6.0

2

The react controller shouldn’t be doing a damn thing, as React should be running on its own
[3da7019a-369d-4c47-a3a2-7c7245bf87c0] Started GET “/graphql” for 172.68.174.237 at 2024-02-23 21:11:14 +0000

Feb 23 01:11:14 PM[3da7019a-369d-4c47-a3a2-7c7245bf87c0] Processing by ReactController#index as HTML

Feb 23 01:11:14 PM[3da7019a-369d-4c47-a3a2-7c7245bf87c0] Parameters: {“path”=>“graphql”}

Feb 23 01:11:14 PM[3da7019a-369d-4c47-a3a2-7c7245bf87c0] Rendering public/index.html

Feb 23 01:11:14 PM[3da7019a-369d-4c47-a3a2-7c7245bf87c0] Rendered public/index.html (Duration: 0.1ms | Allocations: 11)

Feb 23 01:11:14 PM[3da7019a-369d-4c47-a3a2-7c7245bf87c0] Completed 200 OK in 6ms (Views: 1.2ms | Allocations: 971)

Feb 23 01:12:24 PM[f5a252c6-520e-4e90-8feb-6880b8104300] Started GET “/graphql” for 172.68.174.9 at 2024-02-23 21:12:24 +0000

Feb 23 01:12:24 PM[f5a252c6-520e-4e90-8feb-6880b8104300] Processing by ReactController#index as HTML

Feb 23 01:12:24 PM[f5a252c6-520e-4e90-8feb-6880b8104300] Parameters: {“path”=>“graphql”}

Feb 23 01:12:24 PM[f5a252c6-520e-4e90-8feb-6880b8104300] Rendering public/index.html

Feb 23 01:12:24 PM[f5a252c6-520e-4e90-8feb-6880b8104300] Rendered public/index.html (Duration: 0.1ms | Allocations: 5)

Feb 23 01:12:24 PM[f5a252c6-520e-4e90-8feb-6880b8104300] Completed 200 OK in 1ms (Views: 0.4ms | Allocations: 214)

Feb 23 01:12:26 PM[bc49dcc8-048f-4358-8058-63adf7975278] Started GET “/graphql” for 172.68.174.87 at 2024-02-23 21:12:26 +0000

Feb 23 01:12:26 PM[bc49dcc8-048f-4358-8058-63adf7975278] Processing by ReactController#index as HTML

Feb 23 01:12:26 PM[bc49dcc8-048f-4358-8058-63adf7975278] Parameters: {“path”=>“graphql”}

Feb 23 01:12:26 PM[bc49dcc8-048f-4358-8058-63adf7975278] Rendering public/index.html

Feb 23 01:12:26 PM[bc49dcc8-048f-4358-8058-63adf7975278] Rendered public/index.html (Duration: 0.1ms | Allocations: 5)

Feb 23 01:12:26 PM[bc49dcc8-048f-4358-8058-63adf7975278] Completed 200 OK in 1ms (Views: 0.5ms | Allocations: 214)

3

Tried a different approach still failing…tf am I doing wrong?
See how it’s giving me hell for having a service on port 5000 whenever the other service should be on 10000?

==> Running ‘rails s -p 5000 && npm run start --prefix client --port 10000’

Feb 23 01:50:43 PM=> Booting Puma

Feb 23 01:50:43 PM=> Rails 6.0.6.1 application starting in production

Feb 23 01:50:43 PM=> Run rails server --help for more startup options

Feb 23 01:50:50 PM==> Detected service running on port 5000

Feb 23 01:50:50 PM==> Docs on specifying a port: [redacted]

Feb 23 01:50:51 PMPuma starting in single mode…

Feb 23 01:50:51 PM* Version 3.12.6 (ruby 3.2.2-p53), codename: Llamas in Pajamas

Feb 23 01:50:51 PM* Min threads: 5, max threads: 5

Feb 23 01:50:51 PM* Environment: production

Feb 23 01:50:51 PM* Listening on tcp://0.0.0.0:5000

Feb 23 01:50:51 PMUse Ctrl-C to stop

Feb 23 01:51:29 PM==> Using Node version 20.11.0 via /opt/render/project/src/package.json

Feb 23 01:51:29 PM==> Docs on specifying a Node version: Setting Your Node.js Version | Render Docs

Feb 23 01:51:39 PM==> Running ‘rails s -p 5000 && npm run start --prefix client --port 10000’

Feb 23 01:51:50 PMDEPRECATION WARNING: Including LoggerSilence is deprecated and will be removed in Rails 6.1. Please use ActiveSupport::LoggerSilence instead (called from at /opt/render/project/src/config/application.rb:20)

Feb 23 01:51:51 PM- Gracefully stopping, waiting for requests to finish

Feb 23 01:51:53 PM=> Booting Puma

Feb 23 01:51:53 PM=> Rails 6.0.6.1 application starting in production

Feb 23 01:51:53 PM=> Run rails server --help for more startup options

Feb 23 01:51:54 PMextend GraphQL::Subscriptions::SubscriptionRoot is no longer required; you can remove it from your Subscription type (Types::SubscriptionType)

Feb 23 01:51:54 PMextend Subscriptions::SubscriptionRoot is no longer required; you may remove it from SwyleSchema’s subscription root type (Types::SubscriptionType).

Feb 23 01:52:02 PMPuma starting in single mode…

Feb 23 01:52:02 PM* Version 3.12.6 (ruby 3.2.2-p53), codename: Llamas in Pajamas

Feb 23 01:52:02 PM* Min threads: 5, max threads: 5

Feb 23 01:52:02 PM* Environment: production

Feb 23 01:52:02 PM* Listening on tcp://0.0.0.0:5000

Feb 23 01:52:02 PMUse Ctrl-C to stop

Feb 23 01:52:11 PMYour service is live :tada:

4

Hi Aaron,

Are you attempting to expose both ports to the internet from a single service? If so, that won’t work. We only expose a single port per service. I would suggest spinning these up as two separate services.

Regards,

Matt

5

You seriously expect me to pay for two separate services for a single full-stack project? (three if you include PostgreSQL)
Forget about it!!! If Heroku can concurrently run Rails on the backend and React on the front-end, why can’t Render? I do not want both ports “exposed to the internet” I want my front-end (react and apollo) to make requests to the Rails server’s GraphQL controller.

When I connect to swyler.onrender.com, I expect it to load my React app, with data from the Rails server. This worked on my home PC, and it worked back whenever my app was on Heroku. I had to migrate because they got rid of the student tier, and I was told Render would be cheaper. Paying for three separate services defeats the whole blasted purpose of migrating in the first place!!!

First I tried the migration tool which didn’t work, and then Keith from Render told me to do it in Ruby runtime instead because the migration tool doesn’t work if you had more than one buildpack.

6

Hi Aaron,

Could you try starting up your node server first?

That way our automatic port detection should find it before it detects the Ruby port.

Regards,

Matt

7

You mean swap the order of npm start and rails s? I’ll try that hold on.

Like so? npm run start --prefix client --port 10000 && rails s -p 5000

It says my service is live but now instead of the dark-blue div I am getting “Invalid Host header”

==> Detected service running on port 10000

Feb 23 02:35:27 PM==> Docs on specifying a port: Web Services | Render Docs

Feb 23 02:36:02 PM==> Using Node version 20.11.0 via /opt/render/project/src/package.json

Feb 23 02:36:05 PM==> Running ‘npm run start --prefix client --port 10000 && rails s -p 5000’

Feb 23 02:36:06 PM

Feb 23 02:36:06 PM> client@0.1.0 start

Feb 23 02:36:06 PM> react-scripts --openssl-legacy-provider start 10000

Feb 23 02:36:06 PM

Feb 23 02:36:11 PMStarting the development server…

Feb 23 02:36:11 PM

Feb 23 02:36:18 PMYour service is live :tada:

Nope, still not working. No idea what that invalid head thing is about either.

8

Still not solved.

9

Hi Aaron,

The trick here is that you need to depend on Render’s automatic port detection to pick up the service you want exposed to the internet and not accidentally detect your Ruby service first.

You could try adding some delay before starting the second service as a workaround.

Again, the most straightforward solution would be to run two separate services.

It’s important to keep in mind that while Heroku and Render are similar in many ways, there are plenty of differences between the two platforms. There are some use-cases where Render won’t be an exact “lift and shift” replacement for Heroku.

Regards,

Matt

10

Running two separate services is unacceptable. I absolutely refuse to pay twice for the same app - because I shouldn’t have to.

How do I add a delay to the command?

…if your platform isn’t an exact “lift and shift” why did your migration guide make it seem like it was? This is a clear case of false advertisement. What if I changed it to Docker, would it run both services at the same time?

Also do I really need to rebuild every time I change the Start Command, or is there a way around that?

11

command1 && command2 will never run command2 if command1 never exits, and npm run / rails s generally don’t exit successfully which is also a requirement. You wanted command1 & command2

A Frontend and a Backend are two apps.

1 Like
12

And yet I have seen them run on the same machine concurrently.

13

& vs &&

the difference is & backgrounds command1 immediately, does not wait and runs command 2, whereas && will wait for command1 to finish, which it wont

1 Like
14

That…literally fixed it. It’s running now, though I still can’t log in or register because of some ill-conceived refactors - but by golly I’m going to make it work! Thank you!

1 Like
15

i had many issues moving my code here because it runs different on much slower computers, i do not need the speed, but also, i am understanding my own asynchronous code much better, handling errors better, and generally enjoying plunking around with a cloud box, once i have all my bugs ironed out i am thinking about trying some blueprints, which i think will lead me to learning docker. i also just switched my desktop computer to nixos which is declarative, like the blueprint or docker configs, so, a lot of work could be saved in the future setting things up with these text based configs

16

you can also combine commands with || which means or. so, in some instances i use

some-command || true

which will change the outermost return code to success always :wink:

so i am going to try and work that into my smile and nod game, by agreeing with

or true

17

And Render support was trying to gaslight me into paying for two separate services!!! The nerve! The unadulturated, greed-based nerve!!!

18

In computers, there’s always a way to do things differently, to do more than a mechanism was designed to handle. Can you? Should you? It always depends.

You are using two apps, you are attempting to save money by running them both in a single container.

Is this possible? Yes.
Did we attempt to send you down the expected path of running two apps as two services? Yes.
Is this greed? No. Preceding with the completely reasonable expectation of 1 app per service is a reasonable assumption. Additionally, I literally told you to use & instead of && too.

Greed would be telling you you must upgrade to Starter or higher to accomplish this, and then providing you a “fix” to make it look like Starter fixed it, when the problem was just a syntax error on your part. That didn’t happen here.

Two services would have also fixed this issue because they would each run their one respective command, which is the expected path of configuration. There are additional considerations to do with frontend/backend communication and custom domains and other details you may still run into in the future, but we can’t solve problems that you don’t have yet, nor questions you haven’t asked.

This wasn’t greed.

1 Like
19

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