It's tempting to consider using an http server in your program. But also consider wrapping your c/c++ programs in fastcgi loop and have nginx run behind it.
It removes a lot of complexity from your code.
It removes a lot of complexity from your code.
There are good intentions with that advice but I think it's misleading. It doesn't take into account how http libraries like this one (and similar ones for C++ such as Proxygen[1] and Silicon[2]) are supposed to be used.
The intended use case is to add an embedded webserver to your executable that's communicating with friendly and internal systems. That would be things like microservices and dashboards.
You don't use those libraries to create external public-facing websites that would be under attack from hostile agents. You're correct: Do not re-invent NGINX by using the C http library.
As an example proper use case, let's say you write an internal C program to process terabytes of image files. You think it might be nice to have a visual status of its progress/errors/throughput/etc. Instead of adding a GTK GUI to the code, you use the http library to expose a "web dashboard". You can then point an employee browser on the internal network at it to see its progress. For this use case, avoiding the http library and adding NGINX into the stack makes it more complicated.
Another use case without HTML gui is exposing http endpoints for microservices. Again, it's internal communication between friendly agents.
tldr: http libraries that are compiled into executables vs NGINX are for different use cases.
Facebook is a non-trivial size company that has lots of internal private-facing programs with embedded http connectivity. From that experience, they open sourced Proxygen http library which is one of the links I mentioned in the previous comment.
Also, see the comment from VikingCoder which in turn links to reddit thread mentioning another big company like Google doing similar use cases with http libraries: https://news.ycombinator.com/item?id=15671936
Maybe these libs are well-vetted, after all. My mistake. Thanks for the info.
You could use a very stripped-down and thus potentially very efficient HTTP parser given that most of the work will be offloaded to nginx.
Also, last time I checked, nginx didn't support request multiplexing/pipelining over FastCGI (as it does over HTTP). Instead, each HTTP request received by nginx would result in a new (FastCGI) connection to your application which is obviously suboptimal.
I have these same feelings every time I see uWSGI being used.
Not to mention, Nginx implements quite a lot of features that are probably missing in LibHTTP, or implements them in a more performant way.
Having it inbuilt is useful for testing.
Also not sure whether doing a fastcgi loop and requiring another http server to frontend it really is simpler!
In fact in some cases it may only accept one client at a time.