Discussion: implement the platform-specific clients as a wrapper around surf?

[tomhoule]

It would need to be a wrapper - request and response configuration do not vary, and we want to link variables, queries and response shapes.

We would get:

• an independently maintained http client stack
• cross-platform support (web and native for now) out of the box

Cons:

• As far as I am aware of, surf is async-first. We might still want to provide a sync client for convenience

[h-michael]

@tomhoule Is the platform-specific client you are referring to now referring to the graphql_client_web?

[tomhoule]

So I think we could replace the web client we have now with something more robust and maintained by other people, and at the same time this would give us a native HTTP client. That way we only need to interface with a single library (surf).

[h-michael]

and at the same time this would give us a native HTTP client.

At present, users can send requests using their favorite client library, but does that mean that we will provide a feature build that includes clients?

[tomhoule]

Yes it should definitely be a feature (on by default or opt-in, I'm not sure). Users should definitely have access to the current API too in my opinion.

[h-michael]

I think that it is a good configuration that there is room for the current user to select the client library by himself. If you do not add a new function with the client, I think that the built-in client can be opt-in.