Is neo4j-graphql.js ready for production? Anyone company/persion using this in production?
In general, as a Neo4j Labs project, neo4j-graphql.js is being actively worked on, and might still be a bit rough around the edges. Therefore, we don't provide official commercial support for these projects or guarantee longevity. However, some Neo4j customers and users still love the functionality of these projects and choose to continue using them in production environments. Ideally, a Neo4j Labs project graduates and moves into an officially supported project at some point.
More specifically, there are still some features in neo4j-graphql.js that we need to implement, next on our list are support for filtering, better handling of union and interface types and how they relate to node labels in Neo4j, and generating type definitions from an already existing Neo4j database. So if your use case relies on these features, then it might be best to wait a bit for these to be built out.
Having said that, some companies are indeed using neo4j-graphql.js in production. For example, the Financial Times uses neo4j-graphql.js to power their "biz-ops API". Rhys Evans, Principal Engineer at the Financial Times recently gave a presentation at GraphTour London about how they leverage neo4j-graphql.js and GRANDstack, you can find the slides here - "A field guide to the Financial Times". I am aware of others using neo4j-graphql.js and GRANDstack in production, but I won't call them out here ;-)
Maybe others could chime in? Are you using neo4j-graphql.js / GRANDstack in production? Tell us about it in this thread.
Hey @William_Lyon is it updated with Apollo Server v2?
Since, neo4j-graphql-js auto generates cypher queries based on graphql schema, how it handles the custom scalar like JSON or Date or any other scalars?
According to Apollo GraphQL
GraphQL schemas are at their best when they are designed around the needs of client applications. When a team is building their first GraphQL schema, they might be tempted to create literal mappings on top of existing database collections or tables using CRUD-like root fields. While this literal database-to-schema mapping may be a fast way to get up and running, we strongly suggest avoiding it and instead building the schema based on how the GraphQL API will be used by the front-end.
But in case of neo4j-graphql-js we have to have the same type and attribute names same as it's in database right?
Our GraphQL integrations are intended to go the other way and drive the database model from GraphQL type definitions. So the GraphQL schema can be designed as it's intended to be used by the client and the database data model is defined from those type definitions. See https://grandstack.io/docs/guide-schema.html for the goals / principles of the Neo4j-GraphQL integrations.
Currently we don't expose any aliasing / transformation of GraphQL type def --> database datamodel, but that's something we've considered. You could accomplish this today in a more manual way with the
@cypher schema directive.
See the docs here for how we handle the Neo4j temporal types in GraphQL.
For other custom types you can use
@cypher schema directives to resolve these or implement custom resolvers alongside the auto-generated.
Or we can call the
neo4jgrapgql(obj, params, ctx, resolveInfo) function and store the returned object into another variable then do the aliasing and then return to grpahql schema.
Our GraphQL integrations are intended to go the other way and drive the database model from GraphQL type definitions. So the GraphQL schema can be designed as it's intended to be used by the client and the database data model is defined from those type definitions.
I applaud this approach, and it fits how our team wants to work. My frustration is that what you have said is implicitly asserted, yet it's insufficiently documented how this is achieved, though. I understand that "automagic" things are very useful, I would just like to know, step by step, what is involved to achieve this?
Hi @benjamin.rood -
Have you seen the GraphQL schema design guide here: https://grandstack.io/docs/guide-graphql-schema-design.html ? This document outlines the goals of the Neo4j GraphQL integrations, how a property graph model is driven from GraphQL type definitions, what is added to the type defintions through the schema augmentation process, etc.
Exactly what kind of documentation would you like to see added that is missing? Are you asking for more about the internals of the Neo4j GraphQL integrations, and for example how they translate GraphQL to database queries?
Thanks for your reply. Yes, I've read that page, but it's too 'high-level'.
Since GraphQL type definitions are used to define the database schema
That's great, but where in the code is this done, exactly? When I create an instance by calling
What side-effects occur, precisely?
What if there is no prior database, will it automagically generate one inside the running Neo4j instance?
Does the database schema definition persist if the GraphQL server dies?
What if other clients need to connect directly to the Neo4j instance (via a bolt connection), can they take advantage of this schema?
I'm an engineer, I really should know how something works before I just invoke it or copy-and-paste from an example.
Are you asking for more about the internals of the Neo4j GraphQL integrations, and for example how they translate GraphQL to database queries?
Definitely, yes, please, but just as important is documentation of
neo4j-graphql-js as a library, i.e.
x does this, with an example of using
y does this... etc.
I sure do agree with @benjamin.rood here. The documentation do need to be as detailed as possible and well structured. For instance, when I read the doc I don't exactly know what more and how @cypher directive can do for me other than the example given.
And also that's really a good question, when exactly the schema is being created in the code. I was going to ask that too. Also, I would love to contribute to this project after I get a detailed look and know how things are exactly working here.
I think it's necessary to have a clearly defined spec definition of the custom directives which
neo4j-graphql-js supports. It seems like it's just
@relation, but I'm just inferring this. I don't know it definitively because there is no explicit 'index', so to speak, of these things.
I consider this a good piece of documentaion: https://neo4j-graphql-server.gitbook.io/docs/neo4j-graphql-server
But as it's not an official source, I have no idea whether it's out-of-date, or still valid?
This is the sort of information I need:
The following describes the server setup process based on the default configuration:
neo4jIDL is called to update your Neo4j-GraphQL schema.
buildNeo4jTypeDefs then augments the same typeDefs provided to your Neo4j-GraphQL schema.
neo4jGraphQLBinding is used to create a custom GraphQL Binding over the resulting augmented typeDefs. The binding is added into your server's context parameter (default key: 'neo4j' so you can access it the way you normally would access a GraphQL Binding.
buildNeo4jResolvers then generates any unprovided resolvers for query and mutation types that were generated or that use a @cypher directive. Each resolver uses a created binding to delegate all such queries and mutations to a Neo4j-GraphQL endpoint.
Finally, steps 1-5 are processed for any additional binding configurations provided in
bindingsand the resulting
resolversare merged and provided to Apollo Server.
This states which bits are doing what. A good model is the Apollo Server docs. I'm more than happy to help contribute to this documentation, by the way.
Is support for
neo4j-graphql (js or java implementation) covered by the Neo4j Enterprise license? Perhaps a skype call to pick your brain would be useful?
Why not setup a conference call, invite interested people and discuss a complete roadmap and assign tasks?
I am in by the way.