graphql-go/relay

A Go/Golang library to help construct a graphql-go server supporting react-relay.

graphql-relay-go

A Go/Golang library to help construct a graphql-go server supporting react-relay.

See a live demo here: http://bit.ly/try-graphql-go

Source code for demo can be found at https://github.com/graphql-go/playground

Notes:

This is based on alpha version of graphql-go and graphql-relay-go. Be sure to watch both repositories for latest changes.

Tutorial

Learn Golang + GraphQL + Relay Part 2: Your first Relay application

Test

$ go get github.com/graphql-go/relay
$ go build && go test ./...

TODO:

• Starwars example
• HTTP handler to easily create a Relay-compliant GraphQL server (Moved to: graphql-go-handler)
• In-code documentation (godocs)
• Usage guide / user documentation
• Tutorial
• End-to-end example (graphql-relay-go + react-relay)

relay's Issues

Feature Request - Push messaging

In a use case where you have a single app and many users using the same app instance, you want that when a user changes some data, all the other users see the change.

I was looking through the code and example to try and see how to do this. I am not sure if the code has this already in it.

i assume that we need a message pump and push based messaging to the client. So its web sockets or whatever, but a decent test could even just represent each users instance as a folder perhaps. This would also allow the test case to run on CI.

Any ideas ?

Context support

In graphql, Context is passed through ResolveParams. graphql-go/graphql@14c8c6d

This is not available in relay API. the resolve function for mutation has following signature.

type MutationFn func(inputMap map[string]interface{}, info graphql.ResolveInfo) map[string]interface{}

can we pass ResolveParams or Context directly?

thanks.

"starwars" example currently broken

I have a handler PR that's failing in Travis because of the starwars example. It looks like the signature of the type-resolver function (ResolveTypeFn) changed here.

The signature of ResolveTypeFn is now "(p ResolveTypeParams) *Object" but the function is currently defined as:

},
TypeResolve: func(value interface{}, info graphql.ResolveInfo) *graphql.Object {
    // based on the type of the value, return GraphQLObjectType
    switch value.(type) {
    case *Faction:

As a result, the test is currently showing:

$ $HOME/gopath/bin/goveralls -service=travis-ci
exit status 2: # github.com/graphql-go/relay/examples/starwars
../relay/examples/starwars/schema.go:129: cannot use func literal (type func(interface {}, graphql.ResolveInfo) *graphql.Object) as type graphql.ResolveTypeFn in field value
FAIL    github.com/graphql-go/handler [build failed]

I'm not in a place that I can currently fix it. I also risk destabilizing the example because I believe you can now get the content of the old value argument from the new p (ResolveTypeParams) argument but I am new to GraphQL and don't know that I can effectively test it before committing.

ConnectionDefinitions should accept a Interface

func ConnectionDefinitions only accepts a graphql.Object as its NodeType

I'm trying to migrate a graphql service I have written JS, and I have an interface as one of the connections.

I can't migrate it to graphql-go/relay because of this blocker.

https://relay.dev/graphql/connections.htm

An “Edge Type” must contain a field called node. This field must return either a Scalar, Enum, Object, Interface, Union, or a Non‐Null wrapper around one of those types. Notably, this field cannot return a list.

I've created a PR for this fix #43

MutationWithClientMutationID retain the mutation name

Can we retain the Name from MutationConfig on the outputted graphql.FieldConfig in MutationWithClientMutationID function. at

https://github.com/graphql-go/relay/blob/master/mutation.go#L61

so need Name: config.Name there.

thanks.

Relay Modern Support?

Hi,
Is this compatible with Relay Modern that came out this year?
Thanks in advance!

Bug: MutationFn error parameter

The MutationFn should return (map[string]interface{}, error) and when resolving the field in MutationWithClientMutationID we need to return that error right now your are returning nil so we still need to use panics.

IDFetcher and resolving fields to prevent over fetching

Let's say I have a type called User. User has a structure that looks like this:

{
  user {
    id
    firstName
    lastName
    birthday {
      month
      day
    }
  }
}

In the NodeDefinitions, I attempt to return a model to the IDFetcher:

IDFetcher: func(id string, info graphql.ResolveInfo) interface{} {

    resolvedID := relay.FromGlobalID(id)

    var resolved interface{}

    if resolvedID.Type == "user" {
        return model.GetUser(resolvedID.ID)
    }

    return resolved
},

When fetching the model using model.GetUser, how deep should I go and which fields should I return? There are many cases where information for a field is only a different system and require a network call, or a field that is a bit more expensive to retrieve.

While the graphql.ResolveInfo object contains the AST and other information, it seems a bit unintuitive to have to use the AST in userland code, especially when we have defined a schema where the fields have separate resolvers so that only the fields requests are resolved.

Has anyone else dealt with this problem? If so, what was your solution?

Is this project still active?

Is this project still active?

Variable "$id_0" of type "ID" used in position expecting type "ID!" after upgrading to relay 0.7.0.0

After upgrading to relay 0.7.0, it appears the queries it generates have changed slightly, resulting in the error in the issue's title.

Here's an example:

query Overview_ResourcesRelayQL($id_0:ID){
    node(id:$id_0){
        id,__typename,...F0
    }
}
fragment F0 on Resources{
    memory{
        total,
        used,
        when,
        id
    }
    id
}

The query should be:

query Overview_ResourcesRelayQL($id_0:ID!){
    node(id:$id_0){
        id,__typename,...F0
    }
}
fragment F0 on Resources{
    memory{
        total,
        used,
        when,
        id
    }
    id
}

I am not too sure why this happens. This is the definition for node in my schema.json which is generated using the graphql introspection query:

{
          "description": null,
          "enumValues": null,
          "fields": [
            {
              "args": [],
              "deprecationReason": null,
              "description": null,
              "isDeprecated": false,
              "name": "resources",
              "type": {
                "kind": "OBJECT",
                "name": "Resources",
                "ofType": null
              }
            },
            {
              "args": [
                {
                  "defaultValue": null,
                  "description": "The ID of an object",
                  "name": "id",
                  "type": {
                    "kind": "NON_NULL",
                    "name": null,
                    "ofType": {
                      "kind": "SCALAR",
                      "name": "ID",
                      "ofType": null
                    }
                  }
                }
              ],
              "deprecationReason": null,
              "description": "Fetches an object given its ID",
              "isDeprecated": false,
              "name": "node",
              "type": {
                "kind": "INTERFACE",
                "name": "Node",
                "ofType": null
              }
            },
            {
              "args": [],
              "deprecationReason": null,
              "description": null,
              "isDeprecated": false,
              "name": "version",
              "type": {
                "kind": "OBJECT",
                "name": "Version",
                "ofType": null
              }
            }
          ],
          "inputFields": null,
          "interfaces": [],
          "kind": "OBJECT",
          "name": "Query",
          "possibleTypes": null
        },

I think the name property for id should be ID! rather than ID.

Allow the use of database offsets when getting connections

Currently the relay.ConnectionFromArray(data, args) method only allows "software" offsets/cursor.

If the client asks for the first two elements, we potentially query 10000 documents from the database before throwing away the 9998 we don't want.

It would be a good feature to allow the use of database offset methods like LIMITand OFFSET in SQL.

Something like that:

func(p graphql.ResolveParams) (interface{}, error) {
    // convert args map[string]interface into ConnectionArguments
    args := relay.NewConnectionArguments(p.Args)
    offset, limit := relay.ComputeOffset(args)

    ships := []interface{}{}
    if faction, ok := p.Source.(*Faction); ok {
        // get ship objects from current faction
        ships = FindRelatedShips(faction.ID, offset, limit)
    }

    // let relay library figure out the result given the list of ships for this faction
    return relay.ConnectionFromArray(ships, args), nil
}

Project status

Dear @graphql-go peeps!

It seems this project is dormant and should be clearly labeled so in the README. Please add some information on whether or not this is actively maintained and follows the development of graphql and relay spec.

IDFetcher to return error

Currently, there is no way to return an error from idFetcher function. error return type of the resolve methos is not used https://github.com/graphql-go/relay/blob/master/node.go#L56

We should be changing the type from

type IDFetcherFn func(id string, info graphql.ResolveInfo) interface{}

to 

type IDFetcherFn func(id string, info graphql.ResolveInfo) (interface{}, error)

so we can return the error from IDFetcher by just returning

https://github.com/graphql-go/relay/blob/master/node.go#L64 could be just

return config.IDFetcher(id, p.Info)

Question: Use of ConnectionArguments

I am implementing queries using relay to let the possibility of filtering using first, last, after and before. It works and this is good, but there is a big problem.

Relay works as filter when a dataset is already retrieved from database. The only benefit is the size of the response, but server needs to retrieve all the records for the pagination increasing the API call time.

Relay Modern support

Is the library up to date with the new spec for Relay Modern?

FieldConfigArgument descriptions are not used in GraphiQL

Given the following configuration:

Args: relay.NewConnectionArgs(graphql.FieldConfigArgument{
    "fromDate": &graphql.ArgumentConfig{
        Description: "From date value with `YY-MM-DD` format",
        Type:        graphql.DateTime,
    },
    "toDate": &graphql.ArgumentConfig{
	Description: "To date value with `YY-MM-DD` format",
	Type:        graphql.DateTime,
    },
    "status": &graphql.ArgumentConfig{
        Description: "Current invoice status retrieved from transactions",
	Type:        invoiceTransactionStatusEnum,
    },
}),

The custom descriptions are not passed to GraphiQL.
For example, the type graphql.DateTime has its default description that is not overrided from my custom description. Indeed, they keep the default description:
The DateTime scalar type represents a DateTime. The DateTime is serialized as an RFC 3339 quoted string

Instead, the field status which is a custom enumeration, comes with No Description.

Update import paths

Related: graphql-go/graphql#52

Update readme for renaming funtions

The docs/readme needs to be updated to specify that not all conventional input names follows graphql-relay js, Like the clientMutationId which is normally used in graphql-relay needs to be specified as clientMutationID graphql-relay-go.

Just updated my version to the latest.

I guess you need to update the blog post also?

Add .travis.yml

MutationFn, IDFetcherFn signature to follow conventions

Hi,

MutationFn has the following signature.

Edit: same with IDFetcherFn

type MutationFn func(inputMap map[string]interface{}, info graphql.ResolveInfo, ctx context.Context) (map[string]interface{}, error)
it is a convention to have context.Context as the first parameter in functions. So, the signature should be

type MutationFn func(ctx context.Context, inputMap map[string]interface{}, info graphql.ResolveInfo) (map[string]interface{}, error)
ref: https://godoc.org/golang.org/x/net/context

Do not store Contexts inside a struct type; instead, pass a Context explicitly to each function that needs it. *The Context should be the first parameter, typically named ctx *:

func DoSomething(ctx context.Context, arg Arg) error {
    // ... use ctx ...
}

Tests use old format for ResolveTypeFn

I'm raising this mostly because I started poking at graphql-go/relay, /graphql, and the starter kit, and got a little confused. In node_test.go and node_global_test.go, the calls to NewNodeDefinition take the wrong prototype for the TypeResolve parameter. Fixing this so simple, even I was able to figure it out!

My questions, then, ...

• Do you accept PRs directly to this repo? ... and if so, do you have a pattern to follow for branch names? Otherwise, I presume the best practice is to fork and issue a PR from there?
• Will you accept a PR even if all tests are not passing? I haven't dug in enough to see what else is going on, but while they now compile, there are failures. Nevermind; figured out how to fix the tests.

Demo offline

Doesn't resolve! :)

Faction is undefined

See: https://github.com/sogko/graphql-relay-go/blob/master/examples/starwars/schema.go#L119

Since this type is created at runtime, running go build gives an undefined error here.

My first thought is to use the reflect library and capture the types before jumping into the switch-case statement, e.g. valueType := reflect.TypeOf(value). I'm not sure if this is idiomatic or the best way to go, so if others have more elegant solutions please share :)