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.
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.