3 ms·

> Sure, you can use a different protocol between your load balancer and your application and it won't do too much harm. But you're adding an extra protocol that

> Sure, you can use a different protocol between your load balancer and your application and it won't do too much harm. But you're adding an extra protocol that you have to understand, for no real benefit. Well, that depends... At a certain scale (and arguably, not too many people will ever need to think about this), using UNIX sockets (instead of HTTP TCP) between the application and load balancer can be faster in some cases, as you don't go through the TCP stack... > Also, why do you even want a load balancer/reverse proxy, unless your application language sucks? Erm... failover... ability to do upgrades without any downtime... it's extra complexity yes, but it does have some benefits...

lmm 2y ago
> At a certain scale (and arguably, not too many people will ever need to think about this), using UNIX sockets (instead of HTTP TCP) between the application and load balancer can be faster in some cases, as you don't go through the TCP stack... Sure (although as far as I can see there's no reason you can't keep using HTTP for that). You can go even further and use shared memory (I work for a company that used Apache with Jk back in the day). But that's an argument for using a faster protocol because you're seeing a benefit from it, not an argument for using a slower protocol because you can't be bothered to implement the latest standard.
- tuukkah 2y ago
  > using a slower protocol because you can't be bothered to implement the latest standard. I thought we were discussing HTTP/2 but now you seem to be invoking HTTP/3? It's even faster indeed but brings a whole lot of baggage with it. Nice comparison point though: Do you want to add the complexity of HTTP/2 or HTTP/3 in your backend? (I don't.)
  - lmm 2y ago
    > I thought we were discussing HTTP/2 but now you seem to be invoking HTTP/3? The article talks about HTTP/2 but I suspect they're applying the same logic to HTTP/3. > Do you want to add the complexity of HTTP/2 or HTTP/3 in your backend? (I don't.) I'd like to use the same protocol all the way through. I wouldn't want to implement any HTTP standard by hand (I could, but I wouldn't for a normal application), but I'd expect an established language to have a solid library implementation available.

lmm 2y ago

> At a certain scale (and arguably, not too many people will ever need to think about this), using UNIX sockets (instead of HTTP TCP) between the application and load balancer can be faster in some cases, as you don't go through the TCP stack... Sure (although as far as I can see there's no reason you can't keep using HTTP for that). You can go even further and use shared memory (I work for a company that used Apache with Jk back in the day). But that's an argument for using a faster protocol because you're seeing a benefit from it, not an argument for using a slower protocol because you can't be bothered to implement the latest standard.

tuukkah 2y ago
> using a slower protocol because you can't be bothered to implement the latest standard. I thought we were discussing HTTP/2 but now you seem to be invoking HTTP/3? It's even faster indeed but brings a whole lot of baggage with it. Nice comparison point though: Do you want to add the complexity of HTTP/2 or HTTP/3 in your backend? (I don't.)
- lmm 2y ago
  > I thought we were discussing HTTP/2 but now you seem to be invoking HTTP/3? The article talks about HTTP/2 but I suspect they're applying the same logic to HTTP/3. > Do you want to add the complexity of HTTP/2 or HTTP/3 in your backend? (I don't.) I'd like to use the same protocol all the way through. I wouldn't want to implement any HTTP standard by hand (I could, but I wouldn't for a normal application), but I'd expect an established language to have a solid library implementation available.