Prisma: Neo4j support

Created on 16 Jan 2018  ·  31Comments  ·  Source: prisma/prisma

This feature requests serves as a central place to discuss development and progress for the Neo4j connector.

kinfeature tecengines database

Most helpful comment

I'm really waiting for Neo4j support! GraphQL + Graph DB's is like a dream comes true! How far is the process on this?

All 31 comments

I would like to contribute. Do you have any guideline to follow? TIA

@samueledirito It would be great to collaborate on this.

  • The first step is to map out the kind of queries a Neo4j Connector should support.
  • The next step would be to plan in detail whet the resulting API should be. Our current API is designed to expose the power of relational databases, and I'm not sure trying to fit a graph database to the same API is a good idea.

Feel free to dump your thoughts (well formed or not) in this thread so we can get the conversation going.

Would _really_ like to use this in an enterprise application my team is building. Willing to help in any way to push this forward.

https://github.com/neo4j-graphql/neo4j-graphql-js is a nice place to brainstorm initial design

Thanks @d3r1v3d!

At this stage the best way to help is to contribute the following two things (either here or as a slack dm if it is confidential)

  1. Very concrete use case description.
  2. Initial suggestion for syntax for SDL and the generated GrpahQL API.

When we prioritise the connectors to build community validation plays a big role so providing this will ensure that the neo4j connector will get build sooner.

If I may ask, since I'm interested as well, what are you looking for with regards to syntax for SDL? I'd love to use Prisma but need neo4j out of the box (and would prefer to use prisma + stitching + gramps) but need to know more about what is needed to get this off the ground. I'll probably have to backport to Prisma when it's time, but that will hopefully not be too hard given the architecture I've designed for my application.

@aoighost

Neo4J is untyped and GraphQL is typed. We need to decide how the developer should specify the mapping. Prismas MySQL connector generates a powerful CRUD API based on a simple SDL type definition. neo4j-graphql takes a similar approach in addition to allowing custom resolvers implemented by Cypher queries.

I'm interested to understand if this is the best approach or if there is some other model that would be better. If this is the best approach, then we need to map out the SDL syntax required to put type definitions on all aspects of the Graph.

Neo4j has nodes and edges. I'm not quite sure, but I think edges can have a direction as well as properties, so the SDL must be expressive enough to handle this.

It might very well be that Prisma does not need to support all the features of Neo4j to be useful. That's why I would like to see some very concrete use case descriptions, including the schema represented in a mock SDL as well as the queries required to implement the use case.

In neo4j-graphql we use the GraphQL schema as the definitive type mapping

(optionally it can also be generated from the existing data in the graph)

The graphql schema + your directives (like @relation(with direction), @isUnique) are already enough to represent Neo4j's "types".
Multiple labels can be reprented by interfaces or by union types.

Edges with direction are supported in neo4j. Use case for what I'm doing is the following:
Application pushes and pulls data from nodes, connected by edges. Looks for connected nodes on edges to see if things are related as well as to a certain depth. Also supported is pulling all of N type nodes, or E type edges. Cypher, mutations, and subscriptions would all be useful.

That's pretty much all I need. Read/Write including seeing what nodes and edges are related to n depth along with subscriptions and mutations.

Pretty sure @jexp is right on the ball with this.

I am willing to help on this too, any clue when the development might start? what is still needed?

I'm really waiting for Neo4j support! GraphQL + Graph DB's is like a dream comes true! How far is the process on this?

I'm really waiting for Neo4j support! GraphQL + Graph DB's is like a dream comes true!

If all databases are reduced to a lowest common denominator and you are unable to use database specific features (including Cypher language) – what's the point? Really, I'm asking with no irony, – what's the difference between Neo4j and AnySQL in this case?

Edit: I missed the point that Prisma.io doesn't own/host your database. So the question is canceled.

How is going this?
I want to help

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

Ping

Ping again

+1

+1

+1

Any updates on this?

Any update? Any idea around when the connector could be ready?
Q2 2019, 2020... 2030 ? :)

+1

Would use

I've just stumbled on you guys and this aspect alone has sold me. Looking forward to seeing it as a reality.

:1st_place_medal:

Would be great

+1

Also interested to contribute on this.

When is support expected to be released? a week? a month?
Thanks 👍

I'm building an server that requires some machine learning features entirely depends on neo4j.
I also have been using prisma from its alpha state.
Nothing will be better if prisma supports neo4j!

Yea so I've been getting a bit more into this now

The first thing to understand is that _the functionality we're all looking for already exists in an abstract sense via GRANDstack_

... let me explain.
So I started out using Prisma backed by postgres. Defined my schema, built a social network application and got all hydrated with user data. THEN I discover Neo4j.. a friggen beautiful piece of art in the form of a Database

As it turns out in nearly entirely turn-key "just works" fashion you can both import your data from Postgres --> Neo4j , and then Infer a GraphQL Schema From the Existing Neo4j Database we just made

..and have a nearly functionally equivalent neo4j backed GraphQL endpoint in very little time (for me it took a couple days for a fairly involved application) this is obviously a punchline.

... as such I would recommend anybody here serious about creating the Neo4j connector with Prisma should try out GRANDStack and get some experience looking through that lens in order to see GRANDstack's "big picture" juxtaposed with Nexus's

Now I've come to understand that it's not a mutually exclusive GRANDStack - or - Nexus Framework decision. Fundamentally each project has a distinct area of focus.

That said they certainly overlap. For instance both handle schema definition/construction. However Nexus achieves this via code. And the neo4j-graphql-js graphql middleware is bootstrapped via GraphQL SDL. Both result in a graphql endpoint that I can generate TypeScript types from for nearly compatible typesafe usage on my frontend.

Anyways this is just an intro. I suppose it's also worth noting that I was running a Kubernetes cluster for my Nexus Framework endpoint and Prisma Postgres instance, and now I'm literally running a single google cloud run serverless service which hosts the neo4j-graphql-js middleware. The Neo4j instance I outsourced to their own Neo4j managed "Aura" (provisioned through GCP)

I sense intuitively that this integration should/will happen. Graph-native databases are fundamental staple of modern software bag-o-tricks, meaningful Nexus-Prisma-GRANDstack integration is a must. As I get deeper into GRANDstack I'd like to really seriously ask the question what this Neo4j connector could look like. Especially the "WHY?" And then the "HOW?" and ultimately the concrete "WHAT?"

IF NOTHING ELSE CLICK TO SEE THE DATA VIS I GOT OUT OF THE BOX FOR VERY LITTLE TIME INVESTED

Was this page helpful?
0 / 5 - 0 ratings