Of course. Not to mention anything else, 1. Static resources css, js, img require nginx 2. nginx has many mature plug-ins, such as filtering IP, such as redirection, for example. For example, it doesn’t come out. Anyway, there are many Of course, if you don’t want to use it, you can just open a go web service.
If I say I need to use it, I will be stepped on. Then should I answer, it’s better to use it if you want to use it, and don’t use it if you don’t want to use it? Everyone expresses his own opinion.
It mainly depends on whether the golang web service you develop needs to use Nginx function points.
For example, use Nginx to bind domain names, forward requests, use Nginx upstream to do load balancing at the application layer, do url hash to forward requests, etc.
If your web service is an internal service, you don’t need Nginx in many cases.
Look at the scenario. For example, I developed a web service A using golang, which does not support https. At this time, I can configure https through nginx and use reverse proxy to access A without modifying the code.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Of course.
Not to mention anything else,
1. Static resources css, js, img require nginx
2. nginx has many mature plug-ins, such as filtering IP, such as redirection, for example. For example, it doesn’t come out. Anyway, there are many
Of course, if you don’t want to use it, you can just open a go web service.
If I say I need to use it, I will be stepped on.
Then should I answer, it’s better to use it if you want to use it, and don’t use it if you don’t want to use it?
Everyone expresses his own opinion.
It mainly depends on whether the golang web service you develop needs to use Nginx function points.
For example, use Nginx to bind domain names, forward requests, use Nginx upstream to do load balancing at the application layer, do url hash to forward requests, etc.
If your web service is an internal service, you don’t need Nginx in many cases.
Look at the scenario. For example, I developed a web service A using golang, which does not support https. At this time, I can configure https through nginx and use reverse proxy to access A without modifying the code.
When you find that you don’t need to use it, don’t use it.
When you really need some nginx functions, it is very simple to switch.
If caddy has the required functions, you can use caddy.
No need to rush. . . It’s no trouble to add more when needed