4 ms·
I don’t get it. A lot of this post is describing how they translate HTTP requests into function calls, and deal with issues around the HTTP protocol. If you’re
by orf 3y ago
I don’t get it. A lot of this post is describing how they translate HTTP requests into function calls, and deal with issues around the HTTP protocol.
If you’re invoking a heavy-duty, long running function then you’re likely doing something bespoke. Why use HTTP at all? Wouldn’t GRPC be a better fit, because that seems to be what is being reinvented here.
The selling point of HTTP is that it’s ubiquitous and simple. But you’re coupling it with an offering that is specific and complex. Is using a GRPC library such a burden that makes this effort worthwhile?
- Everdred2dx 3y agoEasier for the web devs to work with I guess? Multiple mentions of web browsers in the post
- DinaCoder98 3y agogRPC is for long-lived services (and connections). Combining it with lambda doesn't make much sense.
- orf 3y agoIf only there was some kind of long-lived proxy you could put in front of things that would handle connection pooling and would forward requests onto a short-lived backend, scaling up instances as needed to serve those requests.
- DinaCoder98 3y agoOk, this would still obviate the use of gRPC on lambda
- orf 3y agoWhy?
- quadhome 3y agogRPC is layered on top of HTTP. https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2....
- orf 3y agoYes it is. Thanks?
- ekzhang 3y ago(Author) HTTP is the de facto protocol / "narrow waist" of the Internet. To prove the point further, as other commenters mention, gRPC is also HTTP.
- orf 3y agoIndeed, and it gives you a function call interface on top of HTTP with streaming built in, and a lot of the boring stuff handled for you. Which is exactly what you seem to want.