flow-cli
flow-cli copied to clipboard
Allow using HTTP API client
Currently, the CLI uses gRPC as a way to communicate with the access node, since HTTP API was also implemented on the access node, and in the Go SDK we could easily support that as well if a user decides so. We should just detect based on the host users provides whether we should use the gRPC API or HTTP API.
query to ${HOST}/blocks?height=sealed
is one option to detect if it is HTTP API.
@sideninja I made a POC for this as below:
So Far:
- add
type
field to advanced network config;type
can beGRPC
orHTTP
( default can be GRPC for backward compatibility, or can be HTTP ) - create a
http
backend, like./pkg/flowkit/gateway/grpc.go
Below can be added:
- when you read the config, if
type
is not set, assume a default (let's say GRPC ) - if you have a failure on the client side ( connection, request failure, etc. ) retry with the alternative client. If it succeeds, update the config, and save the edited config. This way, we will not keep making requests to the wrong endpoint.
One thing in the config stands out is:
Currently, we have host
as IP: PORT
in the config; with an HTTP client, we have at least one more parameter, schema. So it is technically http[s]://IP:port
, there is a version part if we keep up with the protocol, http[s]://IP:post/v1
, so the host
parameter here becomes an URL.
I think for the sake of standardization, maybe we can use full URL everywhere ( use grpc://127.0.0.1:3569
for example )
what do you think ?
create a http backend, like ./pkg/flowkit/gateway/grpc.go
I would rather refactor that to not be protocol specific as it's already abstracted in the flow go SDK as seen here: https://github.com/onflow/flow-go-sdk/tree/master/access
So it would be better I think to just refactor that into an access
or something similar.
if you have a failure on the client side ( connection, request failure, etc. ) retry with the alternative client. If it succeeds, update the config, and save the edited config. This way, we will not keep making requests to the wrong endpoint.
I wouldn't do that magically. If a request fails there's something wrong with the HTTP/gRPC endpoint and that is anyhow serious, we shouldn't guard for those. It makes things more complex.
I think for the sake of standardization, maybe we can use full URL everywhere ( use grpc://127.0.0.1:3569 for example )
I agree. But it should keep working for a while with the host for backward compatibility.
access
is better choice and much cleaner.
For the magic part, I meant something like this: ( it was for a smarter way to detect protocol from host, instead of query each time )
- let's say I made a simple network config with host only: IP:PORT
- I tried with grpc ( I got an error ) , then I can try to run with IP:PORT as HTTP api ( if it succeeds it means endpoint is HTTP )
- if it succeed; then I know endpoint is not GRPC, so I can update the config ( upgrade to advanced and set type as
HTTP
) and save.
For the last part:
When config is 127.0.0.1:3569
we can parse it as grpc://127.0.0.1:3569
internally. But we will also support if people write grpc://127.0.0.1:3569
and update docs to grpc://127.0.0.1:3569
, so old code works, also new syntax works and documented as preferred.
For the magic part, I meant something like this: ( it was for a smarter way to detect protocol from host, instead of query each time )
I see, you mean for the case where they would still use host? I would say if they use host
then we default to grpc, if they user URL (a new property) we can figure out the protocol from the URL.
For the magic part, I meant something like this: ( it was for a smarter way to detect protocol from host, instead of query each time )
I see, you mean for the case where they would still use host? I would say if they use
host
then we default to grpc, if they user URL (a new property) we can figure out the protocol from the URL.
Also if they use host we warn them about deprecation.
also we can keep host
and detect if it is url with schema ( then use the schema as protocol ) if not we default to GRPC. deprecation seems a bit overkill, changing flow init
default would be even enough for adaptation.