What does HackerNews think of proxygen?

A collection of C++ HTTP libraries including an easy to use HTTP server.

Language: C++

This doesn't really replace something like haproxy. In the diagrams, the "real" servers that they are load balancing to are L7 load balancers like HAProxy (using https://github.com/facebook/proxygen most likely)

The problem this solves is is when you are using haproxy but need redundancy or a single server is no longer capable of handling the load and you need to scale out to 2+ servers.

You could run 4 haproxy servers and use round robin DNS to load balance between them, but as they say, this has the problem of:

> compared to DNS it doesn't need to wait for TTL to redirect traffic from failed L7 lb.

Many people likely use anycast/ECMP for this case, but that has the other issue they mention:

> compared to anycast-based solution, L4 lbs are more resilient to the networking related issues (which triggers mass ECMP reshuffle)/ enable better handling of adding/removing of L7 lbs from the pool as well as provide better support for unequal load balancing.

>nginx run behind it. 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.

[1] https://github.com/facebook/proxygen

[2] http://siliconframework.org/

https://github.com/facebook/proxygen C++, used by Facebook in production. We have been using it in a high performance RTB application and has performed remarkably well.
Not sure if the talk covered it, but the core Proxygen framework is opensource: https://github.com/facebook/proxygen
I'm curious- why C? Strings, scoped objects and C++11 move operators seems much safer and clearer from an API perspective.

The complaints about C++ seem to mostly be around the ability to abuse the language, not specific issues that C solves. Something like https://github.com/facebook/proxygen seems like a better API.

And I don't quite buy portability- if it's not a modern compiler with decent security checks then I'm note sure it should be building web-facing code.

Facebook's proxygen has HTTP/2 support "in progress": https://github.com/facebook/proxygen
If the author has seen Facebook proxygen[1] (another C++ http framework), a comparison to it would be helpful.

At first glance, it looks like the Silicon dependency microhttpd is somewhat analogous to proxygen. Is the Silicon value-added proposition the extra layers on top such as auto gen of client-side code, etc?

[1] https://github.com/facebook/proxygen