And while working on that, I've found that stub.ex has a lot of gun specific code and that should live inside the adapter.
This doesn't contains drastic code changes, I'm simply moving a small piece of code around to keep on working on adapter code.
My Idea here is to create an layer of abstraction, where each adapter implements it's own version of receiving data. For gun we have the mechanics of receive the headers first and then the payload.
When working with Mint that's not the case. See stream/2 docs
TL;DR: The message we receive in the process might contain headers and parts of the payload (in the same message). So having a function that receives the headers and the body doesn't make to much sense.
I'm working on this issue: https://github.com/elixir-grpc/grpc/issues/242
And while working on that, I've found that
stub.ex
has a lot ofgun
specific code and that should live inside the adapter.This doesn't contains drastic code changes, I'm simply moving a small piece of code around to keep on working on adapter code.
My Idea here is to create an layer of abstraction, where each adapter implements it's own version of receiving data. For
gun
we have the mechanics of receive the headers first and then the payload.When working with Mint that's not the case. See
stream/2
docs TL;DR: The message we receive in the process might contain headers and parts of the payload (in the same message). So having a function that receives the headers and the body doesn't make to much sense.