能否将Elixir的Absinthe插件与Neo4J搭配并复用传统数据库Schema？

Absolutely! You don’t have to abandon Absinthe/GraphQL and rely solely on raw Bolt wrappers for Neo4J. You can absolutely reuse the schema patterns you use for PostgreSQL—here’s how it works:

1. Schema Structure Reuse: Keep the GraphQL Layer Intact #

The core of your Absinthe schema (defining object types, queries, mutations) doesn’t need a complete overhaul just because you’re switching to a graph database like Neo4J.

• For example, if you have a PostgreSQL-backed User type in your schema:

  object :user do
    field :id, :id
    field :name, :string
    field :posts, list_of(:post), resolve: &Resolvers.User.posts/3
  end
  

  You can keep this exact type definition. The only change happens in the resolver function: instead of using Ecto to fetch related posts from PostgreSQL, you’ll write a Cypher query via a Neo4J driver (like bolt_sips) to traverse the graph relationship between User and Post.

2. Swap the Data Access Layer, Not the Schema #

Think of your Absinthe schema as a "contract" for your API—your underlying database shouldn’t dictate this contract. Here’s the playbook:

• Keep using Absinthe.Schema to define your GraphQL API structure, just like you do with PostgreSQL.
• Replace Ecto/Repo calls in resolvers with Neo4J driver operations. For instance, instead of Repo.get(User, args.id), you’d run a Cypher query like MATCH (u:User {id: $id}) RETURN u using Bolt.Sips.query/3.
• Optional: Wrap your Neo4J interactions in a custom "Repo-like" module (e.g., Neo4J.Repo) to abstract away driver specifics. This way, your resolvers will look almost identical to their PostgreSQL counterparts, making schema reuse even smoother.

3. When to Consider Raw Bolt vs. Absinthe/GraphQL #

Raw Bolt wrappers make sense if you need ultra-low-level access to Neo4J’s graph capabilities (like complex traversals or admin operations). But if you’re building a user-facing API or want to maintain consistency with an existing GraphQL-based system:

• Reusing your PostgreSQL-style schema pattern keeps your tech stack unified.
• Frontend teams can continue using the same GraphQL interface, regardless of whether the data comes from PostgreSQL or Neo4J.
• You can encapsulate complex graph logic in resolvers, exposing clean, standardized GraphQL endpoints to consumers.

内容的提问来源于stack exchange，提问作者Errol Hassall