4 ms·

It's making the correct argument that handling HTTP is costly, and you don't always need it. People use it because it's really easy to get something up and runn

It's making the correct argument that handling HTTP is costly, and you don't always need it. People use it because it's really easy to get something up and running with HTTP short term, but long term there are better ways of doing server-server communication.

hansonkd13 5y ago
Author here. EXACTLY. I’m showing that it is just as easy to use a different protocol than HTTP. Instead of reaching for an HTTP framework to do RPC, I’m showing that Redis can be just as easy.
- handrous 5y ago
  You're doing God's work. Anything reminding people that there's more to the Internet than the Web is a step in the right direction.
VWWHFSfQ 5y ago
> People use it because it's really easy to get something up and running with HTTP short term And because there are decades of best-practices and standard ways to do very common things like authentication, caching, signaling errors, load-balancing, logging. Maybe a homemade RPC doesn't need any of that, but I would bet that at some point it will need at least some of it. And now you have to implement it all yourself. This is cool though and kinda fun to think about!
- e12e 5y ago
  > decades of best-practices and standard ways to do (...) caching Essentially either you want RPC, or you might want caching. If you want to put a varnish cache in there, probably stick with http. If you know you're doing (very high thro / low latency) RPC - this might make a lot of sense.
  - VWWHFSfQ 5y ago
    What if I want to memoize my RPC function though? I would have to implement that myself I think
    - e12e 5y ago
      If your messaging lends itself to caching, it might very well fit with REST - which means http might be a good option. So it's not so much if you want to memorize (cache), but if you can* (and/or should). I'm afraid I'm repeating myself - but I really whish people would read all of Fielding's thesis - it's got all kinds of reasonable architectures in it - even if it argues hypermedia/hypertext applications are well served by REST. https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
travisgriggs 5y ago
Isn't the other reason that HTTP APIs are the defacto, is because you often don't get to control the other side of the equation, so we default to the "common lowest denominator" case?

hansonkd13 5y ago

Author here. EXACTLY. I’m showing that it is just as easy to use a different protocol than HTTP. Instead of reaching for an HTTP framework to do RPC, I’m showing that Redis can be just as easy.

handrous 5y ago
You're doing God's work. Anything reminding people that there's more to the Internet than the Web is a step in the right direction.

VWWHFSfQ 5y ago

> People use it because it's really easy to get something up and running with HTTP short term And because there are decades of best-practices and standard ways to do very common things like authentication, caching, signaling errors, load-balancing, logging. Maybe a homemade RPC doesn't need any of that, but I would bet that at some point it will need at least some of it. And now you have to implement it all yourself. This is cool though and kinda fun to think about!

e12e 5y ago
> decades of best-practices and standard ways to do (...) caching Essentially either you want RPC, or you might want caching. If you want to put a varnish cache in there, probably stick with http. If you know you're doing (very high thro / low latency) RPC - this might make a lot of sense.
- VWWHFSfQ 5y ago
  What if I want to memoize my RPC function though? I would have to implement that myself I think
  - e12e 5y ago
    If your messaging lends itself to caching, it might very well fit with REST - which means http might be a good option. So it's not so much if you want to memorize (cache), but if you can* (and/or should). I'm afraid I'm repeating myself - but I really whish people would read all of Fielding's thesis - it's got all kinds of reasonable architectures in it - even if it argues hypermedia/hypertext applications are well served by REST. https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

travisgriggs 5y ago

Isn't the other reason that HTTP APIs are the defacto, is because you often don't get to control the other side of the equation, so we default to the "common lowest denominator" case?