4 ms·
As someone maintaining a pretty large networking industry proprietary app based entirely on net/http in terms of any kind of HTTP communication, I feel like I c
by simiones 4y ago
As someone maintaining a pretty large networking industry proprietary app based entirely on net/http in terms of any kind of HTTP communication, I feel like I can easily tell you are wildly exaggerating. Admin consoles and enterprise connectors are entirely irrelevant to many uses of an HTTP server. Hell, even Kubernetes' API server is built using net/http.
- pjmlp 4y agoYet many of those depend on having something like Apache, NGIX, HA Proxy, IIS,... taking care of the actual load.
- doctor_eval 4y agoThere is frequently a reverse proxy in front of all web services. It’s got nothing to do with the quality of the implementation behind the curtains. And “the actual load” is by definition managed by the endpoint not the router. I mean it would be trivial to implement that reverse proxy in Go. And I do mean trivial; Go also includes a reverse proxy utility, so you can implement something basic in about 5 LOC. At this point it’s hard to believe you’re being genuine.
- pjmlp 4y agoSo trivial that it isn't usually the case. A weekend project and going at scale isn't the same thing.
- deleted 4y ago[deleted]
- doctor_eval 4y agosigh
- simiones 4y agoKubernetes API server is not dependent on Apache, NGINX, HA Proxy, IIS, ... taking care of the actual load, since it's not getting any significant amount of traffic. In general API servers have much bigger scaling problems with actually executing the API calls rather than handling requests at scale. Having an NGINX or something similar to serve some static content and also reverse proxy to a Go server is sometimes nice if you're also serving a large UI app, but in that case NGINX is very much doing trivial work, and Go net/http is handling the real work.