[DOCS / LINTING ISSUE] Provide clear steps if port 3000 is in use

[corinthian13]

https://v3.docs.apostrophecms.org/guide/setting-up.html#creating-a-project

Why in the hell did you choose port 3000 for the ApostropheCMS server ?

If you work with Node.js you will know that most web app back ends use port 3000 (http) and 3001 (https) for their user-event servers.

But you just went ahead and created a conflict between the app backend and the app's CMS servers over access to port 3000 . . .

Thanks, Ernie & Bert.

[boutell]

Hi, Bert & Ernie,

Port 3000 is the default port for most Express applications. Apostrophe is, in fact, a web app back end. So I'm a little puzzled by your question.

But you can set the PORT environment variable, or the port option of the @apostrophecms/express module, to anything you like. This is covered in the documentation of the module.

So if port 3000 isn't convenient for you, you can choose whatever meets your needs.

Closing because there is no bug or missing documentation here, but I am interested to understand better what backend Apostrophe is in conflict with in your particular environment, so feel free to follow up with more on that if you wish.

[corinthian13]

Consider a small business website.
It has its own back end for things like online ordering of services/products and user reviews of the business. This back end runs from ports 3000 (http) & 3001 (https).
It also has a Node.js based CMS, e.g. Apostrophe, which also run from ports 3000 and 3001.
On the web server machine, both of these servers would be started up when the app is launched, one of them inevitably before the other.

Now, my experience in running a Node.js app locally tells me that any time I try to start a Node user-event server on say port 5000 when another Node service is already running on that same port 5000, then the attempt to launch the former server will crash owing to port 5000 being already engaged. (This can happen when the terminal window used to launch the first Node service was not closed - despite the app being exited - and the service is seen to persist when I review the System Monitor processes.)
An error message to that effect is logged onto my console.

I would expect at least the same thing to occur if two Node services were running simultaneously on a web app.

But even if the two services could coexist on the same port, surely it would be better to put them on separate ports if one wanted each type of request, CMS update or user action, to be accorded equal priority at times of high demand. Node can be configured to put different types of request into separate threads so that CPU intensive requests (e.g. business logic processing) do not wall out for long periods simpler requests, e.g. authorization.

That concern apart, I still do not see why an app with 2 (or more) services on Node should have them on the same port.
What would be the gain from doing this ?

PS: Ernie and Bert are Sesame Street characters. Ernie always did things in an unintended way, Bert tried in vain to make him do things the orthodox way.

[boutell]

I'm familiar. I always called them "Bert and Ernie" growing up for some reason, never the other way around. Clearly one of us is wrong, but we'll never know which. I just tried launching two copies of Apostrophe, and the second copy reported a reasonable error message on the console, which is what you seem to be asking for: Error: listen EADDRINUSE: address already in use :::3000 ... And it shut down. Also as I mentioned you can configure the port. In our experience, Apostrophe is usually the first Node app in the shop, so changing our default port would probably be more confusing than helpful, but you can set it to whatever you like so... I still don't really see the issue. But possibly we could improve the error message to mention what your options are if you don't want Apostrophe to listen on port 3000. Another possibility is that you're testing on another OS (I tried this in MacOS) and you don't get a clean error message. Let me try this on Linux... nope, same result. Let me know though if you're seeing something different. I'm using up to date Apostrophe 3.x, the boilerplate project the CLI would give you.

…

On Thu, May 19, 2022 at 5:33 PM corinthian13 ***@***.***> wrote: Consider a small business website. It has its own back end for things like online ordering of services/products and user reviews of the business. This back end runs from ports 3000 (http) & 3001 (https). It also has a Node.js based CMS, e.g. Apostrophe, which also run from ports 3000 and 3001. On the web server machine, both of these servers would be started up when the app is launched, one of them inevitably before the other. Now, my experience in running a Node.js app locally tells me that any time I try to start a Node user-event server on say port 5000 when another Node service is already running on that same port 5000, then the attempt to launch the former server will crash owing to port 5000 being already engaged. (This can happen when the terminal window used to launch the first Node service was not closed - despite the app being exited - and the service is seen to persist when I review the System Monitor processes.) An error message to that effect is logged onto my console. I would expect at least the same thing to occur if two Node services were running simultaneously on a web app. But even if the two services could coexist on the same port, surely it would be better to put them on separate ports if one wanted each type of request, CMS update or user action, to be accorded equal priority at times of high demand. Node can be configured to put different types of request into separate threads so that CPU intensive requests (e.g. business logic processing) do not wall out for long periods simpler requests, e.g. authorization. That concern apart, I still do not see why an app with 2 (or more) services on Node should have them on the same port. What would be the gain from doing this ? PS: Ernie and Bert are Sesame Street characters. Ernie always did things in an unintended way, Bert tried in vain to make him do things the orthodox way. — Reply to this email directly, view it on GitHub <#209 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAH27J67I4AC56BN2FG34DVK2XRNANCNFSM5WM7V3RA> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

-- THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER APOSTROPHECMS | apostrophecms.com | he/him/his

[corinthian13]

I'm using Apostrophe CLI v3.1.1 on an Intel i5-7XXX CPU on Ubuntu 20.04.2 LTS.

You suggest that most of your users would have their CMS running before getting their back end going ?
I wonder about this.
If it's run as a headless CMS they will populate their web pages with some plausible text and images/videos.
Otherwise how will they know from the off whether rendering problems are down to the CSS or the CMS ?
In any case they'd surely like to see how things actually look (as opposed to any wireframes they used for mock-ups) before connecting the CMS into it all.

Maybe your intended clientele is the large enterprise sector.
My own clientele is the small business sector.
In this arena all site owners really want is some convenient and intuitive way to change essential content on the site - prices, products/services, images, blurbs, etc - without calling a web designer and paying them at the professional rate for time spent on trivia. The Apostrophe in-context editor readily allows this. That's why I went for your CMS over Strapi and other Node.js based ones.
But maybe this is not a sector that your company wishes to engage with.

[boutell]

Do you have a functional issue with the resolution that I suggested?

On Sat, May 21, 2022 at 2:48 PM corinthian13 ***@***.***> wrote: I'm using Apostrophe CLI v3.1.1 on an Intel i5-7XXX CPU on Ubuntu 20.04.2 LTS. You suggest that most of your users would have their CMS running before getting their back end going ? I wonder about this. If it's run as a headless CMS they will populate their web pages with some plausible text and images/videos. Otherwise how will they know from the off whether rendering problems are down to the CSS or the CMS ? In any case they'd surely like to see how things actually look (as opposed to any wireframes they used for mock-ups) before connecting the CMS into it all. Maybe your intended clientele is the large enterprise sector. My own clientele is the small business sector. In this arena all site owners really want is some convenient and intuitive way to change essential content on the site - prices, products/services, images, blurbs, etc - without calling a web designer and paying them at the professional rate for time spent on trivia. The Apostrophe in-context editor readily allows this. That's why I went for your CMS over Strapi and other Node.js based ones. But maybe this is not a sector that your company wishes to engage with. — Reply to this email directly, view it on GitHub <#209 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAH27K2FTSKGTJU3CV6B73VLEVWRANCNFSM5WM7V3RA> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

-- THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER APOSTROPHECMS | apostrophecms.com | he/him/his

[corinthian13]

Of course I do.

It's extra work that should not be imposed on any existing site owners by the company whose package they are good enough to try out. It is hardly fair of your company to add to their complications - especially when your company could (and should) well have set the CMS on some other non-popular port numbers at no extra inconvenience to themselves.

i doubt if you won the commercial hand of clients like Michelin by forcing their back end out of 3000/3001.

What is your functional issue with the resolution that I propose, i.e porting ApostropheCMS to say 5000/5001, 6000/6001 or 7000/7001 ?

[boutell]

Changing the default port would be a backwards incompatible change and inconvenience all of the existing users who rely on that. A new default port could conflict with something else. It doesn’t solve the problem. What we can do is improve our documentation around this issue so that the information is readily available when you’re first trying the application, i.e. included in the error message so you know exactly what to do right away. Most of our users are either running apostrophe as the first node application they are bringing into an environment, or running it in a container so that the local port isn’t really a conflict. This is the first report we’ve had of this being a major issue for a user - which doesn’t mean we can’t improve the documentation. That being said, we are not here to be yelled at. Please review our contributor guide and code of conduct. https://v3.docs.apostrophecms.org/guide/contribution.html#how-you-can-help

On Sun, May 22, 2022 at 3:04 PM corinthian13 ***@***.***> wrote: Of course I do. It's extra work that should not be imposed on any existing site owners by the company whose package they are good enough to try out. It is hardly fair of your company to add to their complications - especially when your company could (and should) well have set the CMS on some other non-popular port numbers at no extra inconvenience to themselves. i doubt if you won the commercial hand of clients like Michelin by forcing their back end out of 3000/3001. What is *your* functional issue with the resolution that I propose, i.e porting ApostropheCMS to say 5000/5001, 6000/6001 or 7000/7001 ? — Reply to this email directly, view it on GitHub <#209 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAH27OUYCG7IMA3TVAJ7K3VLKAM3ANCNFSM5WM7V3RA> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

-- THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER APOSTROPHECMS | apostrophecms.com | he/him/his

[corinthian13]

I am sorry - I hadn't thought of the existing users.
If a substantial number of those are using port 3000/3001 for Apos CMS then it's another hassle.
Some of your existing clientele are large sites with millions of users so changeover is asking for trouble.

I have no suggestion beyond what you have said above, customer alerting to the port allocation.

[boutell]

Reopening the ticket with the possible resolution being to document how to address the port number issue closer to the "getting started" steps where it might be first encountered, and to include a hint about it in the error message.