Trouble with @neo4j/graphql: No results in Apolo Client and incomplete where Type (Bug?)

Hi,

I started working with @neo4j/graphql a few days ago and could get up and running with the graphql API really quickly.

Earlier today I had one issue stopping me that I posted on Stackoverflow:

Basically I want to filter based on a field in User, that I added after first running the server and later restarting it, but apolo claims that it is not present in UserWhere. I never defined UserWhere and realized that it is being autogenerated. I now think, that might be done by neo4j/graphql, but I am still unsure about that.
So this is my first issue: Where is this generated, where can I find documentation on that and how to I add my "isAdmin" field to the UserWhere type (or optimally let it get generated correctly)?

Second issue: I then switched to another database. I still have the neo4j/graphql apollo-server running on my computer, but I connect to a remote database now.
For querying all users

 query Test {
    users {
      name
    }
  }

I get an empty response. I then activated debugging for neo4j/graphql and it generates and executes the following query:

MATCH (this:`User`)
RETURN this { .name } AS this

This returns 0 results. However when I execute the query through Neo4j Browser on the same database, I get 10k+ results.
It also works when I use my local database.

Remote DB: 'Neo4j/4.4.15 in Docker instance, community version. Did not have APOC installed, which I had to, because otherwise the apollo server threw an error. After installing it, there is no error, but an empty list of results.

Local DB: 'Ne4j/4.2' Desktop version

So I have no clue what the reason for this could be and assume it might be a bug when the query works in the browser but not using graphql?

Hi

The GraphQL query you want to write might be

query usersList ($where: USERWhere)
{
  user: users (where: $where)
  {
    user_id
    lastName
    firstName
    dob
    gender
  }
}

I don't really know whether USERWhere is updated from graphql or from neo4j-driver, but your new isAdmin clause should have been automatically updated to the USERWhere (all code I posted is copy/paste from an already opened query in the playground of my project and I wrote USER in full upcase thus the difference in case and parameters !!!)

with parameters

{
  "where": 
  {
    "user_id": "7b61c286-fae8-488d-bcb8-4a18e3ce71f8"
  }
}

and the Id token in the auth headers of course.

Apollo's playground normally automatically introspects the schema at regular intervals so you shouldn't have to refresh everytime you make a change to your typeDefs. Well at least it worked for me with Apollo V4, I never tried with the previous versions.

But try this anyway if you haven't already done. I've seen some videos of a guy running graphql-yoga V2 who had to refresh his browser everytime he made a change to his typedefs so I think it might worth a try.

Thank you very much for replying! Okey so I don't fully understand what happened,

But I could execute:

 query Test {
    users(where: {id: "test"}){
      name
    }
  }

now.

Before that, i executed the query that you proposed:

query usersList ($where: USERWhere)
{
  user: users (where: $where)
  {
    user_id
    lastName
    firstName
    dob
    gender
  }
}

That gave me an unfiltered list of all results, as when I did not define the $where. So what exactly did this do (if anything?). This was after I restarted my computer so I am not sure if this query did something that i am not aware of or if restarting solved something I am also not aware of?
I'd really like to understand what happened, because for now this seems to be solved, but I guess its likely I run into this issue again.

On the other hand I still get 0 results from the remote db so that issue persists.

query usersList ($where: USERWhere)
{
    users(where: $where)
    {
        user_id
    }
}

allows you to pass arguments seperately from the request itself. As far as I understood it passes the arguments to the cypher query separately from the cypher query itself thus preventing cypher-injection (like sql-injection but for cypher instead).

In your playground right under the query input field there's another input field in which you can write

{
  "where": 
  {
    "user_id": "7b61c286-fae8-488d-bcb8-4a18e3ce71f8"
  }
}

and this is how you can pass your arguments separately from the request itself.

Alright! So this seems helpful in any case, but I doubt it had anything to to with the definition of the UserWhere type itself.
So any input on this or the lack of results from the remote db is still highly welcome because I still couldnt make any progress there.