Bring Links up to par with what package:graphql has

[gql-dart]

Bring Links up to par with what package:graphql has

[micimize]

• http_link should have something like the useGETForQueries option as well
• persisted queries were recently contributed

[micimize]

@Ram231 it isn't a WIP exactly, but at the least porting the existing graphql implementation will be necessary for graphql/client.dart v4, which I'm actively working on.

@klavs do you think it's possible to decouple HttpLink and FileUpload link, or will we have to just have two different links?

Also, should I go ahead and PR my NetworkException code into gql_http_link's exceptions / exception handling?

[DoctorJohn]

I wrote an auth link that works with the gql http link. It's similar to the one in the graphql_flutter package has. I may contribute mine, but where to put it? It's just 21 lines...

[klavs]

Hey @DoctorJohn, welcome!

A new link should go to a new package at the root of this directory.

To kickstart your PR you can start by adding it to the example directory of gql_httpl_link so that we can discuss the design.

[smkhalsa]

Here's the basic implementation of an ErrorLink that I'm using in case it's helpful:

import 'dart:async';
import 'package:ferry/ferry.dart';
import 'package:gql_link/gql_link.dart';
import 'package:gql_exec/gql_exec.dart';

typedef void OnError({
  LinkException linkException,
  List<GraphQLError> graphQLErrors,
});

class ErrorLink extends Link {
  final OnError onError;

  ErrorLink(this.onError);

  @override
  Stream<Response> request(Request request, [forward]) =>
      forward(request).transform(
        StreamTransformer.fromHandlers(
          handleError: (error, stacktrace, sink) {
            if (error is LinkException) {
              onError(linkException: error);
            }
            sink.addError(error);
          },
          handleData: (data, sink) {
            if (data.errors != null && data.errors.isNotEmpty) {
              onError(graphQLErrors: data.errors);
            }
            sink.add(data);
          },
        ),
      );
}

[klavs]

I think useGETForQueries wasn't doing anything. Am I wrong?

[micimize]

yeah I mean it tells the link to use GET for queries

if (operation.isQuery && config.http.useGETForQueries) {
  config.options['method'] = 'GET';
}

[vinceramcesoliveros]

Is the File Upload Work in Progress? This was my first time using graphql for vue(web) and flutter(mobile). How is it going to be implemented in a way that can be used via http package?

[vinceramcesoliveros]

I'd like to propose that single file and multipart upload in a separate way that there are no type checking and it should be strongly typed. Thanks for the hard work. I hope it'll get to be flutter favorites.

[klavs]

How is it going to be implemented in a way that can be used via http package?

Well that is THE question. From GraphQL's perspective a file can be a scalar type. But it should be a well-known scalar type, in the sense that links must know about it to support it.

do you think it's possible to decouple HttpLink and FileUpload link, or will we have to just have two different links?

Probably we'll end up implementing file upload within HttpLink.

Also, should I go ahead and PR my NetworkException code into gql_http_link's exceptions / exception handling?

Your NetworkException is a specialized version of the ServerException. (My appologies for the bad documentation comment.) In a more abstract sense, there is no network, there's only server you are trying to communicate to. This generalization will make more sense when we have a client-side resolver (client-side server) support.

[micimize]

@klavs ServerException has a @required Response parsedResponse, which doesn't make sense when the error involves a failure on the network itself. NetworkException would be part of gql_http_link regardless.
Maybe the taxonomy should be

TerminatingLinkException
 ├── ServerException
 └── NetworkException /// in `gql_http_link`

[micimize]

@klavs Everything but persisted queries has been merged, and I think it's fine if APQ lives in graphql flutter or 3rd party module for now.

So, I'd say once gql_http_link: 0.3.0 is published (and maybe other recent changes) we can close this?