Deploy preview for hasura-docs ready!

Built with commit 6cf3c97

https://deploy-preview-4458--hasura-docs.netlify.app

I believe the Relay spec supports queries without the use of edges/connections/nodes, I believe it is only the cursor spec that requires them.

To use example from the relay docs

query RebelsShipsQuery {
  rebels {
    name,
    ships(first: 1) {
      edges {
        node {
          name
        }
      }
    }
  }
}

and

query RebelsShipsQuery {
  rebels {
    name,
    ships {
      name
    }
  }
}

Are both valid, although one obviously returns all and one turns the first only.

Using the second way, I believe you could keep the way Hasura currently handles aggregations.

query RebelsShipsQuery {
  rebels {
    name,
    ships(limit: 1) {
      name
    }
  }
}

and

query RebelsShipsQuery {
  rebels {
    name,
    ships(where: {id: {_eq: <Global Object Identifier> }}) {
      name
    }
  }
}

And this would be valid with Relay and work with Hasura's engine converts the to the database id in the standard way of using tablename_id.

We have been using relay modern for 12+ months and do not use cursors, edges, connections or nodes.

It would be great to see both ways of querying be supported with the Relay implementation.

Please let us know when there is a working implementation, and we'll happy set it up and give it a try and provide any feedback.

Review app for commit e0478d2 deployed to Heroku: https://hge-ci-pull-4458.herokuapp.com
Docker image for server: hasura/graphql-engine:pull4458-e0478d2c

Review app for commit 8e28ed3 deployed to Heroku: https://hge-ci-pull-4458.herokuapp.com
Docker image for server: hasura/graphql-engine:pull4458-8e28ed3d

Review app for commit 71b5d05 deployed to Heroku: https://hge-ci-pull-4458.herokuapp.com
Docker image for server: hasura/graphql-engine:pull4458-71b5d054

Review app for commit fb92eb7 deployed to Heroku: https://hge-ci-pull-4458.herokuapp.com
Docker image for server: hasura/graphql-engine:pull4458-fb92eb71

Review app for commit ff5d97b deployed to Heroku: https://hge-ci-pull-4458.herokuapp.com
Docker image for server: hasura/graphql-engine:pull4458-ff5d97b5

@wawhal The relay api toggle status on console should be persisted to LS

Review app for commit f1c07e2 deployed to Heroku: https://hge-ci-pull-4458.herokuapp.com
Docker image for server: hasura/graphql-engine:pull4458-f1c07e21

Review app for commit 97814f4 deployed to Heroku: https://hge-ci-pull-4458.herokuapp.com
Docker image for server: hasura/graphql-engine:pull4458-97814f4d

Review app for commit ef8255f deployed to Heroku: https://hge-ci-pull-4458.herokuapp.com
Docker image for server: hasura/graphql-engine:pull4458-ef8255f3

Does this PR support relay persist queries?

@rakeshkky The spec gives priority to first So it is always interpreted as last of first edges between after and before 😅

https://relay.dev/graphql/connections.htm#sel-FAJLJCDDAAHFDDFBGB_yN

Review app https://hge-ci-pull-4458.herokuapp.com is deleted

Review app for commit acca92c deployed to Heroku: https://hge-ci-pull-4458.herokuapp.com
Docker image for server: hasura/graphql-engine:pull4458-acca92c7

@soneymathew

@soneymathew I couldn't understand the actual issue here. Is the encoded id value in the latter not correct?

@rakeshkky encoded id value is correct, but the encoded id was not globally unique, perhaps I missed a migration step? note that I was running an older version of hasura in the same database.

The global unique id is base64 encoding of the JSON object which contains the details of the table name itself and primary key column values. The id is a primary key column whose value is encoded.

Regarding first and last argument:

I blindly followed the note and made a decision not to allow both arguments. We can support the behavior you mentioned in the use case. Soon the next beta release (1.3.0-beta.2) will support it.

Edit 1:-
From the formal specification of relay pagination.

3. If last is set:

    a. If last is less than 0:
          i. Throw an error.
    b. If edges has length greater than than last:
          i. Slice edges to be of length last by removing edges from the start of edges.

The edges are the result of rows after applying cursors and not the result of slicing edges by first argument value.

@rakeshkky - I am must not be making myself clear.

The issue is that the relationship ids are different to the item ids.

In the database the ids look like
Person {id: 1, role_id: 4}
Role {id: 4}

However Hasura is returning is returned the base64 encoded table+id for the id, but not for the relationship id.

From current hasura query result
Person: {id: 'cGVvcGxlLTE=', role_id: 4}
Role: {id: 'cm9sZXMtNA=='}

Now there is no way to match role_id: 4 to the role, because the ids are different.

Hasura should be returning role_id as the base64 encoded table+id instead like this:
Person: {id: 'cGVvcGxlLTE=', role_id: 'cm9sZXMtNA=='}
Role: {id: 'cm9sZXMtNA=='}

This is how all other relay + sql implementations I have used work.

@rakeshkky currently "normal" ids are used in URL like https://my.app/company/h3ol3ne. Here is short id "h3ol3ne" which exact row id in table "company". Now in Relay API mode ids not the same and match longer. Is there a right way to use previous ids?

@ro-savage

In a given table, the id column is replaced with Node interface's GUID. The GUID is base64 encoding of the JSON object which contains the details of the table name itself and primary key column values (the table may have more than one primary key columns).

In the use case you mentioned:
Person: {id: 'cGVvcGxlLTE=', role_id: 'cm9sZXMtNA=='}
Role: {id: 'cm9sZXMtNA=='}

I think there's no point in having Role table information in Person table's column (role_id). Let's say if we are querying just the data from Person, having opaque base64 encoded value for role_id doesn't make it clear. Also, it is always assumed that role_id should match with Role's id.

To avoid conflicts, you can customize the column name. If relay clients work with custom name for Node interface GUID field (other than id), let us know.

Please do open an issue on github, specifying your concerns on the relay as this PR got merged to master as that would be easier to track and discuss. 😃

@rakeshkky currently "normal" ids are used in URL like https://my.app/company/h3ol3ne. Here is short id "h3ol3ne" which exact row id in table "company". Now in Relay API mode ids not the same and match longer. Is there a right way to use previous ids?

You can make use of customize column name feature to rename the id column field.

What happen with this task "Implement camelcase and singular/plural inflection"?. Even though it might not be explicitly in the graphql spec the camel case, is definitely a convention. In 1.3 beta for relay the connections cant be aliased like the table fields, also there is a mix of camel case and snake case, which makes it inconsistent.

For my particular case, I'm considering hasura to replace an existing graphql api that is consumed by a relay client. The camel case is a big problem, since we would have to modify all the existing graphql queries and I want to do this with the least possible changes to the existing client code.

In another note, I think the generated global IDs are too big. Just consider the request payloads and response data size increase just because of this small detail. Also consider that this IDs could be used in URLs (any client/app).

The base64 encoded data has too much information for an identification string {"table" : {"schema" : "public", "name" : "test"}, "columns" : {"id" : 1}}. Wouldn't some text like schema:table:id, result in a smaller encoded string, have enough information and would be easy/faster to parse?, or am I missing something?

@rakeshkky - I have made an issue here #5035 #5036 #5037

@jmsegrev - I've also added an issue for your suggestion

Huge thanks for adding relay support! I'm testing it right now, it works pretty well but I find something weird, nodes are typed as nullable, but I can't find any example where they would indeed be null, but it's quite a pain to deal with nullable in the front end. Is it something that could be changed?

@tsnobip Just speculation from my side, but this is sometimes an effect of how permissions are implemented. Ie "fetch all rows, check permission for each node". I dunno if that's the case here though, but just to provide some context on when node might be nullable in general.

@tsnobip @zth

The rows are filtered by applying permissions, if any. So, each item should be non-nullable. I'll fix this in #5013.
Thank you.

@rakeshkky please how the id is generated?

The global unique id is base64 encoding of the JSON object which contains the details of the table name itself and primary key column values. The id is a primary key column whose value is encoded.

Can you show the JSON object format, please? I would like to generate the id, but I need the JSON fields, for example:

{
    "table_name": "my_table",
    "pk": "4ddd3e6c-7528-41d4-a052-84e57931b199"
}

What names are used in the table_name and pk? Is there any other information I need to know to generate the ids?

I need to generate the ids while #5658 is not fixed because I'm using a custom function in the regular endpoint, that should contain the relay id of the record.

@PedroBern This answer might help: https://stackoverflow.com/questions/62685944/hasura-relay-how-to-work-with-base64-encoded-ids

@tirumaraiselvan thanks for the response, I've submitted a PR to add an example of how to get the relay id in the graphql endpoint #6054