node.js app endpoints behind apache wordpress website - node.js

Question

I have a WordPress website (mywebsite.com) running on a shared hosting server. Alongside, I made a node.js app running in the backend on port 3000, which has been programmed to have different API endpoints.
I would like to have the endpoints to be in the same domain as the website in specific URLs.
The main endpoint, which has been declared in the node.js selector environment, works just fine. Let's call it mywebsite.com/myapp.
The other endpoints (which have been declared in the express routes) work correctly outside the website environment but are instead caught by apache/wordpress if I try to access them on the same domain even as sub-uri.
For example, if I try to access mywebsite.com/secondendpoint or mywebsite.com/myapp/thirdendpoint, the request gets caught by Wordpress which loads the 404 page.
Now, I understand that I have to instruct the apache server to redirect the requests to the above mentioned URL to the node.js app.
As long as I don't have access to the apache server, the only choice I have to tweak the .htaccess files.
When I created the node.js app, the virtual environment has been automatically set through a .htaccess file in its own subfolder in my website public folder, where my whole website is: /public_html/myapp . It uses Phusion Passenger to handle the virtual environment the app is running in.
# DO NOT REMOVE. CLOUDLINUX PASSENGER CONFIGURATION BEGIN
PassengerAppRoot "/home/user/apps/myapp"
PassengerBaseURI "/myapp"
PassengerNodejs "/home/user/nodevenv/apps/myapp/12/bin/node"
PassengerAppType node
PassengerStartupFile app.js
PassengerAppLogFile "/home/user/logs/myapp.log"
# DO NOT REMOVE. CLOUDLINUX PASSENGER CONFIGURATION END
The above code works just fine. I tried to add an Alias as suggested in some tutorial:
# DO NOT REMOVE OR MODIFY. CLOUDLINUX ENV VARS CONFIGURATION BEGIN
<IfModule Litespeed>
SetEnv Alias /secondendpoint /apps/secondendpoint
</IfModule>
# DO NOT REMOVE OR MODIFY. CLOUDLINUX ENV VARS CONFIGURATION END
In the root of /public_html/ I have the following .htaccess file
# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^/secondendpoint/(.*)?$ http://127.0.0.1:3000/secondendpoint/$1 [P,L]
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
No matter what I try, when I try to access mywebsite.com/secondendpoint, I always get the Wordpress 404 message.
What am I doing wrong?
I even tried to create a subfolder in /public_html/secondendpoint which actually does proxy the traffic, but I feel like this is not the right way to do it.

Answer 1

So, after a week of attempts, I found out that the syntax of the RewriteRule was indeed wrong for what I was trying to achieve.
RewriteRule ^/secondendpoint/(.*)?$ http://127.0.0.1:3000/secondendpoint/$1 [P,L]
The correct syntax is
RewriteRule ^secondendpoint(.*)$ http://127.0.0.1:3000/secondendpoint/$1 [P,L]
As shown in the comment of the .htaccess file "should only be modified via WordPress filters".
In fact is does automatically overwrites the rules I wrote every time it updates.
The right way to do it would be tweaking the internal WordPress WP_Rewrite
which I'm still trying to understand.
My best attempt has been adding to functions.php of my theme these lines:
function wpd_wtf_rewrite_rule() {
add_rewrite_rule(
'secondendpoint(.*)$',
'http://127.0.0.1:3000/secondendpoint$1',
'top'
);
}
add_action( 'init', 'wpd_wtf_rewrite_rule' );
These lines are being translated in
RewriteRule ^secondendpoint(.*)$ /http://127.0.0.1:3000/secondendpoint$1 [QSA,L]
and updated into the .htaccess file.
The slash in front of the target is an issue I don't know how to fix.
However, the generated .htaccess string does not proxy the requests resulting in errors from the API.