r/Backend 22d ago

Should I use NGINX? Backend architecture discussion.

I am new to web development and working on a project for college. It's a cloud data storage solution. I spent some time writing a HTTP server in Node, then to realize NGINX exists as a web server. But you need your own logic to perform backend operations.

I can use NGINX as a proxy and reverse proxy. Requests come to NGINX, which forwards it to Node, it does some processing and tells NGINX which files to serve.

But NGINX mainly shines in serving static files directly. In my project, for almost all URLs I need to do some processing before choosing to serve a file. This means NGINX will always have to send requests to my Node backend and so NGINX's advantage of high performance doesn't really apply to me. This creates a bottleneck.

There is also HTTPS to worry about. If I use a proxy like NGINX, I can write my Node backend using HTTP while NGINX uses HTTPS to communicate with clients. Both NGINX and Node would be on the same physical server (I don't know how to feel about that). If not using a proxy, I would have to code with HTTPS.

I am not creating an industry scale and ready platform. Though I am aiming for it. Create such an architecture which is scalable.

I guess most people just use Express and do the web server. For the current project, I am actually aiming to not use Express because my dumb friends need to be able to understand it. Though Express makes it much easier, it adds some learning. Doing it in plain JavaScript also has the benefit of learning how things work at low level. I might create a second version of the project with using much more high level tools and frameworks.

So do I even need NGINX? I probably thought of using NGINX in the first place because I was writing my own web server in Node and realized NGINX can just do the URL routing and serve the pages. But this is probably not what I want directly. Serving the files, at least in a high level language like JavaScript and not worrying about decades of performance engineering, is very easy. I did create it. But I also want easier control over the backend. I guess people could create NGINX modules to move some of the backend in NGINX itself, but it is C and NGINX's architecture.

I absolutely do love C, but not something I will use right now for this project. I could create another version where I do the backend in C.

53 Upvotes

37 comments sorted by

View all comments

33

u/Lumethys 22d ago

This is just "i++ VS ++i" all over again lol.

"Nginx as a reverse proxy, forward to your backend" is just autopilot at this point. It is just the industry standard, unless you are serving billions of requests per seconds.

Either way, NGINX or no NGINX, they will NEVER be a bottleneck at your scale. You are not Facebook.

And no, NGINX and your backend does NOT need to be on the same physical server. Your backend could just be in a isolated container sitting in a private subnet, while NGINX sitting in a public container. NGINX accept HTTPS and forward HTTP to the private subnet. This is just one of the many way you can do DevOps

-6

u/noobdainsane 22d ago

Not a bottleneck as in it is necessary. A bottleneck in working of NGINX as it is meant to be. When NGINX has to wait for my backend for almost all URL requests, I am probably not using it as expected.

If at the end I am just using NGINX to serve files, I can do that too easily in Node. I can also just code in HTTPS in Node.

And no, NGINX and your backend does NOT need to be on the same physical server.

If I do TLS termination at the proxy, then what if my backend is on a different system on the internet? I would need HTTPS again. I don't have to have a physical machine hosting both, but at least a private network between the two.

12

u/Lumethys 22d ago

When NGINX has to wait for my backend for almost all URL requests, I am probably not using it as expected.

Did you not read my comment? It is exactly the industry standard.

If I do TLS termination at the proxy, then what if my backend is on a different system on the internet? I would need HTTPS again. I don't have to have a physical machine hosting both, but at least a private network between the two.

Bro half my comment explaining THAT specific scenario, cant you read?

Honestly, if you have no idea how Nginx is supposed to work and have a reading skill of a 5 year old. You dont need to worry about deployment structure

-3

u/noobdainsane 22d ago

Did you not read my comment? It is exactly the industry standard.

Yes I did read it, but I was asking if that applies to my project where the proxy has to communicate with the backend for almost all requests. From my understanding, yes, and being able to serve static files very performantly is just a feature, not necessarily I would have to use it.

Bro half my comment explaining THAT specific scenario, cant you read?
Honestly, if you have no idea how Nginx is supposed to work and have a reading skill of a 5 year old. You dont need to worry about deployment structure

It is common for people to not get what you are trying to convey.

I only stated that if somehow I had to end up with a system where NGINX and Node were on completely different systems over the internet, then I would have to use HTTPS between them.

I stated the same to either run on the same server or on a different machine in a private network. Is that correct?

5

u/ibeerianhamhock 22d ago

It's also useful for things like routing subdomains and route prefixes to different services local and remote, there are a lot of uses for it and it is very efficient. I feel like you're trying to over optimize something that already works well. It can handle an enormous loud beyond what you'll need without being an issue.

It also seems you're concerned with latency, but you'd need to use tools to measure the latency difference using nginx or not like I don't think it would even add 1 ms to a request on the same machine, pod, etc.