I have seen various questions here and answers on the web, but still I can't get an understanding of what's the best way to use react and nodejs/express together, where I use node to serve json content and in general to do tasks such as managing access to services for which i am Oauth-ed. I realize I am probably not grasping something very basic.
I tried (starting from create-react-app) and ended up with two different applications, server and client served on different ports and that's not what I want: besides all CORS issues, it does seem to make sense to share code.
what's the best way to do this? is it to have one or two different applications (on different ports), or how to have a single application serving sometimes json and sometimes react web pages?
Related
I am relatively new to node js servers.
I have an Nginx server with multiple node js scripts running (Reverse Proxy).
Since all the scripts are very different currently I am running multiple node js scripts.
eg
https://page.com/stuff1 -> stuff1.js (node js server running on port 81)
https://page.com/stuff2 -> stuff2.js (node js server running on port 80)
I like how the code in each file is simpler and how if I wanted to I can turn off one page without affecting the other.
My question is if it is better to concentrate all the node js scripts into one or if I should stick to what I am doing now.
I have done some research and the questions I come across seem to be about jquery and plug-ins and not the server itself. They also seem to focus on sending the files to the client.
Thank you for reading.
Your question is valid, and this scenario may serve in some situations :)
About this part:
My question is if it is better to concentrate all the node js scripts
into one or if I should stick to what I am doing now.
Might be more complex to answer, as it really depends on your use case, and where and how you want to use your applications.
In some cases, it's just better to write a clean, and maintainable code using some design and architectural patterns like the "clean architecture", or the "hexagonal architecture". And with this, you may have your application running behind one Node.js server, in one code base but it can scale and serve multiple users while keeping the code easy to maintain and debug. And if you want to turn off a page, you can just "unregister" the routes from your Node application.
In other cases, your approach might be better, so you would split your application into smaller applications and put them behind a reverse proxy, this allows you to maintain them separately which might be beneficial, especially if you would work in a bigger team. Also, now you may have the applications running on the same server, it's much easier to move them to different servers, for more scalability and better fault tolerance, and you only do the necessary changes on your Nginx configuration and possibly your server's firewall configs.
And of course, both approaches have cons: You may not want to handle a big code base if the application is too complex, and you don't want to scale a whole application just to serve more traffic on coming to an isolated module of your application.
On the other hand, you may not want to deal with the issues that come with making your application distributed. You would have (in this case) two applications sharing resources on the same server which may cause challenges when you scale.
Edit:
You may want to have a look at pm2's process management as it should help you manage multiple Node.js processes.
I've been learning Node.js for a couple of weeks. These days I was looking for advice on best practices and came across the concept of "Separation of concerns". I understood (tell me if I'm wrong) that it consists on split the backend and the frontend into two different servers. I've been using template engines such as ejs and pug so far, but I always have these files in the same directory as the rest of the Express server (in a "views" folder). I think there are many ways to separate the frontend and backend, maybe having 2 folders, 1 for the frontend with just simple HTML, CSS, and js files and make AJAX requests to the API, that will be in the other folder, the backend's one.
I'm pretty new in the backend so I hope this question makes sense haha. I'm a bit confused about how backend and frontend connections should work and how I can make a frontend that is independent of the technology used in the backend, so if you know books or resources in general about this, tell me.
welcome to stack
Best practices are different from developer to another and they are tend to be evolving.. so that is what i’m doing :
1 - Separate Directory for fronted and backendusing node proxy .
2- src Folder that contains ( for backend ) views , routes and controllers … etc .
Separation of concerns is the idea that each module or layer in an application should only be responsible for one thing and should not contain code that deals with other things.
Separating concerns reduces code complexity by breaking a large application down into many smaller units of encapsulated functionality.
I have done a website in Nodejs and Expressjs and a question struck me. My front-end and back-end are integrated together, meaning I needed to use routes and such to direct users and show the web page. However, if I want to make a mobile app and would like to access the same server and same database, how would I do it because my knowledge right now is limited to back-end and front-end much be developed together since I can't really separate out the front-end HTML stuffs from my Nodejs set-up.
I think it is an easy question but a confusing one to a newbie like me
The most common way to do this in my experience is to build a REST API, which you can still do using Express if you're comfortable with that. You would probably mount a separate Express app on some other url (https://api.example.com/ or https://example.com/api), for example. Ideally, you would have done this first, and then had your web site hit that API as well, but since you didn't not a big deal. If your code is appropriately modularized, then all you should really have to rewrite is a thin layer of controller code (for example to res.send() rather than res.render()).
Intro
I'm trying out Node.js right now ( coming from PHP background).
I'm already catching the vibe of the workflow with it (events, promises, inheritance..haven't figured out streams yet).
I've chosen a graphic portfolio web app as my first nodejs project. I know node.js might not fit best for this use case but I it's a good playground and I need to do this anyway.
The concept:
The visitors will only browse through pretty pictures in albums, no
logging in or subscirptions, nothing.
The administrators will add,modify, reorder.. CRUD the photo
albums. So I need there Auth, ACL, Validation, imagemagick... a lot
more than just on the frontend.
Currently I'm running one instance of Node.js, so both admin and visitor code is in one shared codebase and shared node memory runtime, which to me looks unnecessary performance-wise.
Question
For both performance and usability:
Should I continue running one instance of node for both admin and visitor areas of the web app or should I run them as 2 separate instances? (or subtasks? - honestly i haven't worked with subtasks/child processes)
Ideas floating around
Use nginx as proxy if splitting into 2 applications
Look into https://stackoverflow.com/a/5683938/339872. There's some interesting
mentions of tools to help manage processes.
I would setup admin.mysite.com and have that hosted on another server...or use nginx to proxy requests from that domain to your admin.js node app.
Are there any examples or conventions out there of how to use node.js to host multiple web apps?
I'm already aware that node itself can be used to build a server, but I'm curious as to whether there have been implementations where you aren't necessarily running it all the time. Strictly for the reason that perhaps there are multiple sites being hosted, each with their own copy of a framework, static files and custom functionality.
Or maybe you do run one instance of node and code a multiple site architecture to ensure one bad site doesn't take the server downin some way?
Virtual hosts, ensuring that one site can't crash others...these are all things that have been considered with other platforms, but I have had some difficulties finding for node! :)
I am already aware of connect, express and other middleware, however it doesn't cover what I'm asking here.
If you're worried about runtime isolation, each "site" should run it's own node process. Then use a proxy like node-http-proxy that will do host header based routing. Another great node based option is bouncy, but you don't necessarily need to use node to do the host based routing. You could just as well use haproxy, nginx, etc.
The baseline RAM overhead of each node process is very small (~10mb - 15mb). Also, if you do HTTP based routing you can spread your sites easily across machines, user home directories, etc.
If you want to handle the site/host registration programmatically, I would use seaport and then communicate the hostname and host + port details back to the proxy so that the routing table can by dynamic. This would also make it fairly easy to scale a site across multiple node processes.
Good luck!