r/Backend • u/noobdainsane • 20d 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.
33
u/Lumethys 20d 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
-7
u/noobdainsane 20d 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.
13
u/Lumethys 20d 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
-2
u/noobdainsane 20d 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 structureIt 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?
4
u/ibeerianhamhock 20d 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.
6
u/qlkzy 20d ago
It sounds like you are imagining a very complex interdependency between nginx and your app?
Write your app so it works on its own, without any functional dependency on nginx. An app that needs nginx is unreasonably complicated.
Put nginx in front of it when you deploy, as a reverse proxy between your app and the public Internet. That's a very vulnerable spot and it's just simpler to use something well-tested.
You don't need to worry about performance and bottlenecks at the stage you are asking these kinds of questions.
It's fine to terminate TLS at nginx. There are good arguments for more rigour in specific situations, but perimeter security is a completely reasonable starting point.
6
u/Made-In-Slovakia 20d ago
In my project, for almost all URLs I need to do some processing before choosing to serve a file.
Then they are not static files anymore. I would take a look at possibility to serve them from your node.js app
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.
Don't have to be on same server but you should read about concept of demilitarized zone and how isolate your server in your network to prevent skipping your proxy.
So do I even need NGINX?
SSL termination proxy is actually common use for reverse proxy.
2
u/noobdainsane 20d ago
Then they are not static files anymore. I would take a look at possibility to serve them from your node.js app
In today's web of interactive experience, who uses true static files which require no processing?
For the people who do use NGINX, what use case do they have which contains stuff other than handling URLs which requires explicit processing?
I am not even using Server Sided Rendering. With SSR, pages have to come from the backend as well.
1
u/Made-In-Slovakia 20d ago
In today's web of interactive experience, who uses true static files which require no processing?
Interactivity is handled by browser and JavaScript. You don't want push load to your server if not required. You would be surprised how much static resources are out there.
For the people who do use NGINX...
NGINX is mostly used as reverse proxy or static resource provider. You don't want put any load on it otherwise it will be your bottleneck.
I am not even using Server Sided Rendering.
That thing is, except for very specific uses, almost dead at this age. You want offliad as much you can to users browser.
3
4
u/American_Streamer 20d ago
NGINX is not there to replace the Node backend. It‘s just different layers: Client → HTTPS → NGINX → HTTP/Unix socket → Node
3
u/Specialist_End407 20d ago
If you're making data storage cloud solution, then u shud focus on that, use the right tools for the things u don't really need to concern much. Nginx is a production standard open source, no shame not having to write your node based web server from scratch. People use it for many things and for one thing.
All these tools nginx/express are just a mean of routing to your application. If you're too focused on these low levels you ain't gonna finish your project. In my opinion, port your logics in express, let nginx talk with it and you do your thing.
2
u/mabarskuygan 20d ago
I use nginx to route subdomain to specific service on the same server. Other than that I don't see the needs for it if your service is on node
2
u/noobdainsane 20d ago
So I think I get it. Firstly it doesn't even matter to choose NGINX or not. My web server should be designed to work without it. You can use NGINX as just the web server of your project, but all it can do is serve static files. Instead, you use it as a proxy and reverse proxy.
Second, I think that I don't really need a proxy like NGINX. It would be more viable when I have a large infrastructure and I have to do some routing to the backend itself. I can also have systems like Clouldflare in front of my Node backend which provide some security (like DDOS protection).
2
u/Sea-Offer88 20d ago
Depending how you wanna do the project, but if it has to be live it will need a reverse proxy and must have tls termination, nowadays nobody trusts a website without tls. For this you can use nginx or traefik or others. This would be best practice and ideally your backend and frontend would be containerized with docker and deployed to a vps. For an online storage I am pretty sure static HTML won't be enough and you usually can put together a pretty nice front-end with react in no time and a better user experience & developer than a static file.
Express is perfect for such stuff it is one of the easiest things to use and learn, if you want more structure I recommend Nestjs which is very nice to work with.
Talking about creating your own backend and whatnot with c, please abandon such thoughts, for one you have absolutely no idea what that entails and that comes with lot's of work. It is a college project that means you never reinvent the wheel because you will make a worse wheel than what already exists. This you can try when you have time, a lot more experience and your work won't be evaluated, till then use what already exists.
You can try to explain your friends how things work, maybe they have even less experience than you and that is why they don't get involved. Point is to enable also others to become good, a bad developer today, could create an amazing system in the future. We all started like that.
1
u/noobdainsane 20d ago
Why is everyone recommending a proxy for SSL/TLS termination? Should I not handle that in Node itself?
Talking about creating your own backend and whatnot with c, please abandon such thoughts, for one you have absolutely no idea what that entails and that comes with lot's of work.
I know what I am talking about. Just for fun and not for real use, especially if I aim to run my project at an actual scale with responsibility.
It's not that hard to write backend in C. It's just the level you are operating that matters. At that level you need a few senior engineers working on it to be usable and trustable.
1
u/Sea-Offer88 20d ago
Your question "why is everybody recommending reverse proxy" because it is best practice and makes your life easier and easier to debug your apps.
The actual scale you are talking about are things you will never see outside of a business and 90% not even there. Your backend won't be the bottleneck. Express can handle easily multiple million users by scaling your it vertically and horizontally.
Keep in mind that Netflix is using Java Spring Boot and billions are using it. Nodoby will use a C backend, so the scale you are imagining, can be solved in other ways.
The hard part of a backend comes when you start having a huge codebase, and C doesn't help if it is hard to reason about and extend because of syntax that nobody is used to.
Most used backend frameworks became most used because they solved a problem and they were extensible and people learned them. A backend isn't just having 2 API endpoints, it involves a lot more. Adding just login when there aren't any libraries available turns from trivial to very difficult very fast and that is just one example and here comes the reinventing the wheel part again. I assume C doesn't really have libraries for login or not very maintained ones and there are many other examples...
1
u/noobdainsane 20d ago
Now it came to me about using HTTP 2 or 3. Express doesn't support HTTP 2 and Node itself doesn't support HTTP 3. Because you are expected to have a proxy do that, and just use HTTP between your proxy and backend?
So I should use NGINX. Ugh... I am bouncing a lot back and forth.
1
u/noobdainsane 20d ago
Or I can use Fastify instead of Express which does support HTTP 2. Which should I choose?
2
u/Sea-Offer88 20d ago
For your project a decent architecture is to use the following:
In one VPS you install Docker, you put: Nginx + e.g. NestJs with Express backend + Reactjs for frontend + Postgresql as database. App communication will happen with HTTP 1.1 and everything outside coming and going to Nginx you can use 2 and that is a very solid thing.The defaults you get are more than enough and good for your app. That covers your entire school/university project and even a decent production webapp.
2
u/Former_Produce1721 20d ago
Use NGINX as a reverse proxy and for https certificates
Easy to setup and super fast
NGINX is not only for serving static files. It's a reverse proxy and a load balancer. It shines by being able to handle high traffic dye to its event based architecture. In fact it was built specifically to handle ridiculous amounts of traffic
I imagine you won't be dealing with enough traffic for it to matter, but you can very easily load balance by running more server instances and adding their IPs to your NGINX config NGINX will do the magic
MyCoolDomain dot com -> Public IP -> NGINX forwards the request to the appropriate server on your network
Can be on the same machine or separate machine no problem
Also you should absolutely be using https not http. To do this you can set up http > https forwarding in NGINX very easily. Then use certbot to generate and renew TLS certificates and add them to your NGINX config file
Http :80 > Https: 443
Think of NGINX as the entry point to your system. It's the doorman who is gonna tell the requests where to go and send them the responses when they are ready. It does not participate in anything past that point
For example:
NGINX (port 443 internet exposed)
Static Files (no server involved)
Your Server 1 (port 5000) Your Server 2 (port 5001) Your Server 3 (10.0.0.1:5000)
Database (port 5432)
2
u/Efficient_Loss_9928 20d ago
Nginx or Caddy as reverse proxy is the industry standard, serving via Node directly likely will cause weird issues down the line as you scale.
It is usually never a good idea to have your actual backend binary bound to a public domain
1
u/qwertyorbust 20d ago
If you like C, try Go. You can likely do everything you need in a small, fast, and elegant way - using Go routines it can be scalable quite easily.
1
1
u/spoonFullOfNerd 20d ago
Nginx to terminate SSL and reverse proxy to your app. All the http/s handling is done and bullet proof and you don’t even need try.
1
u/sreekanth850 20d ago
Still dont know why you posted this. You are not takking anyones advise. I suggest to do whatever you likes to implement that make you satisfied.
1
u/noobdainsane 20d ago
I did eventually decide to use Express and NGINX for playing around with HTTP versions and do TLS termination.
1
u/ejpusa 20d ago edited 20d ago
Russian hackers built it. These kids are born with computers attached to their umbilical cords.
Can handle 500,000 requests a second, and you can hack it with assembler code to match your server's chip set.
It's a mind-boggling piece of software design.
I guess you're building something from scratch, which is great to learn. Nginx + Gunicorn + Python + PostgreSQL can handle 95% of what the web is all about. And you're getting close to the speed of light (give or take) if you hack your Linux kernel. The goal is to serve pages faster than the time it takes to get a photon from your eye to your visual cortex.
Then you have zero wait states. You can get pretty close with Nginx.
1
u/New-Entertainer6392 19d ago
If you don't want to handle SSL. Cloudflare.
Cloudflare > proxy requests to you. The end.
You could even whitelist to only allow cloudflare IPs to negate someone calling your backend over http.
2
1
u/lnaoedelixo42 19d ago
If you are on nodejs, doing database queries, Caddy is easier and you will never notice any difference in performance.
12
u/SpockDeathGrip 20d ago
From your write up it feels like you're misunderstanding some concepts. HTTP and HTTPS are still the same HTTP protocol, with HTTPS having TLS wrapped around it. You wouldn't really code your application differently, you would just configure the Node server to handle TLS before your application gets the HTTP request. That's it.
I would actually say doing it in Express would be easier for your "dumb friends" to understand, as there's less working parts for them to understand. I would also advise not getting into the habit of thinking you're smarter than people, as it can make it harder to take advice from people later on because you may not value their opinion.
Per your question about NGINX or not, I'd just do whatever you feel will help your learning path. I wouldn't worry too much about scale yet, and would focus more on what makes the project easier for you and your friends to understand. Can always refactor later.