@neo4j/graphql vs neo4j-graphql-js

[ainsausti]

Hi,

I've recently read this post of the maintainer of neo4j-graphql-js in github: The future of this library · Issue #608 · neo4j-graphql/neo4j-graphql-js · GitHub

As he says, the library will no longer be maintained officially by Neo4j and he mentions @neo4j/graphql as the replacement. Does this library has the same features as the other one or it has a totally different purpose? Will it be officially maintained long-term or it's just a proof of concept?

We need to know how stable it is and if it will cover the functionality proposed by neo4j-graphql-js because one of our system depends on it and we must make a decision as soon as possible.

Thank you in advance.

[MuddyBootsCode]

The new library @neo4j/graphql is going to be the officially supported library in the future. It has a number of different features than the old library but maintains the core functionality of the old there's a migration guide here Migration Guide - Neo4j GraphQL Library that can help you get started.

[jaedag]

Just to add to @MuddyBootsCode's post, I would mention that the new @neo4j/graphql library doesn't have support for properties on relations yet. The maintainer of the library says that it will be released in the near future.

So I would say that if your code depends on relationship properties at all, then you should probably hold on till that feature is incorporated in the new library. Otherwise you are safe to upgrade.

[William_Lyon]

The @neo4j/graphql library is the official open-source Neo4j GraphQL Library and will be maintained and supported on an ongoing basis with a dedicated engineering team. Current users of neo4j-graphql-js should consider migrating to @neo4j/graphql. While the two libraries are conceptually similar there are some differences in the generated APIs and feature sets. @neo4j/graphql also introduces additional features such as a more powerful authorization model, nested mutations, and an OGM. You can read more about the Neo4j GraphQL Library in this blog post and on the Neo4j GraphQL Library web page.

For other resources on migrating in addition to the migration guide linked above, this blog post goes into detail comparing features in the two libraries and we recently did a live stream showing how to migrate a demo podcast application from neo4j-graphql-js to @neo4j/graphql including how the new authorization functionality can be used.

Regarding relationship properties - this is something being addressed now. The plan is to use a Relay style connection model for handling relationship properties which is more consistent with GraphQL best practices. For details, there is an RFC here with the current design.

If you have any other blockers to migrating please open an issue on Github as we are actively interested in ensuring users are able to migrate to the official Neo4j GraphQL Library and want to make sure these issues are identified so they can be addressed.

[William_Lyon]

Also, wanted to mention another resource for learning more about the Neo4j GraphQL Library, which is this online training on Graph Academy: "Building GraphQL APIs Using The Neo4j GraphQL Library"

[ainsausti]

Thanks everyone!
We will migrate to the new library slowly because it affects to an important part of the system, thus we are using it to automatically create and deploy APIs form a model built in an application.

We will comment here our experience and problems to give you feedback.

[louis_van_acker]

So far I am not having an issues with the new library except for one detail. For me the graphql _id that exposes the Internal ID of nodes does not work anymore. Anyone else experiencing this?

[William_Lyon]

Glad to hear it's going smoothly - for the most part 🙂

Exposing the Neo4j internal id to external systems is almost always not desired as those id values can be reused/reclaimed. Instead, I would suggest generating a UUID and storing that as a property on the node. The @id directive can be used to autogenerate these UUID values.

If you really want to expose the internal node id via GraphQL, this can be done with a @cypher directive field:

extend type Foo {
  internalNodeId: ID! @cypher(statement: "RETURN id(this)")
}

[louis_van_acker]

Hi,

I've received the same advice on the discord. That query does indeed work and fix the situation. I've tried shifting to apoc.install.uuid (favoring long-term/robustness) but also had some issues there which have resulted in some code updates. Nice to see the quick bug fixes in the repository !

Thanks!