Allow using HTTP API client

[sideninja]

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.

[bluesign]

query to ${HOST}/blocks?height=sealed is one option to detect if it is HTTP API.

[bluesign]

@sideninja I made a POC for this as below:

So Far:

• add type field to advanced network config; type can be GRPC or HTTP ( 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 ?

[sideninja]

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.

[bluesign]

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.

[sideninja]

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.

[sideninja]

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.

[bluesign]

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.