Spring JPA和GraphQl

发布于 2025-01-21 15:22:54 字数 766 浏览 0 评论 0原文

鉴于以下图,

type Movie {
   name: String!
   actors: [Actor!]!
}

type Actor {
   name: String!
   awards: [Award!]!
}

type Award {
   name: String!
   date: String!
}

type Query {
   movies(): [Movie!]!
}

我希望能够尽可能有效地运行以下三种类型

查询1:

query { 
  movies {
    actors {
      rewards {
        name
      }
    }
  }
} 

查询2:

query {
  movies {
    name
  }
}

查询3: QUERY 3:

query {
  movies {
    name
    actors {
      rewards {
        date
      }
    }
  }
}

请注意,这些不是我将要运行的唯一查询,但是我希望我的代码能够“自动”选择最佳路径。

我的其余业务逻辑正在使用JPA。数据来自三个表,每个表最多可以包含40列。


我不是在寻找代码示例,而是寻找一个高级结构,描述了各个职责的不同元素。

Given the following graph

type Movie {
   name: String!
   actors: [Actor!]!
}

type Actor {
   name: String!
   awards: [Award!]!
}

type Award {
   name: String!
   date: String!
}

type Query {
   movies(): [Movie!]!
}

I'd like to be able to run the following three types of queries as efficiently as possible:

Query 1:

query { 
  movies {
    actors {
      rewards {
        name
      }
    }
  }
} 

Query 2:

query {
  movies {
    name
  }
}

Query 3:

query {
  movies {
    name
    actors {
      rewards {
        date
      }
    }
  }
}

Please note, these are not the only queries I will be running, but I'd like my code to be able to pick the optimal path "automatically".

The rest of my business logic is using JPA. The data comes from three respective tables, that can have up to 40 columns each.


I am not looking for code examples, but rather for a high-level structure describing different elements of architecture with respective responsibilities.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

请帮我爱他 2025-01-28 15:22:54

没有进一步的上下文和DB模式的细节,我可以做的就是为您提供所需的一般建议。

当执行包含几个相关对象的查询时,您很可能会遇到N+1加载性能问题,并且这些对象存储在不同的DB表中。

通常,有两种方法可以解决它:

  1. 使用 dataloader 。它的想法是将每个对象的实际加载时间推迟到可以通过单个SQL一起批处理多个对象的时刻。它还提供了缓存功能,以进一步提高相同查询请求的加载性能。

  2. 使用“向前图模式”(请参阅​​一个>示例)。它的想法是,当您解决父对象时,您可以向前看,分析您需要执行的GraphQl查询是否需要包含其他相关的孩子。如果是的,则可以使用JOIN SQL与他们的孩子一起查询父对象,以便您以后解决孩子时,他们已经被获取,您无需再次获取它们。

另外,如果您域中的对象在理论上可以包含无穷大的数字,则应考虑为查询实现分页行为,以限制其可以返回的最大对象数量。

Without further context and details of your DB schema, what I could do is to just to give you the general advice that you need to aware of.

Most probably you would encounter N+1 loading performance issue when executing a query that contains several levels of related objects and these objects are stored in different DB tables.

Generally there are 2 ways to solve it :

  1. Use Dataloader . Its idea is to defer the actual loading time of each object to a moment that multiple objects can be batched loaded together by a single SQL. It also provides the caching feature to further improve the loading performance for the same query request.

  2. Use "look ahead pattern" (Refer this for an example). Its ideas is that when you resolve the parent object , you can look ahead to analyse the GraphQL query that you need to execute require to include others related children or not. If yes , you can then use the JOIN SQL to query the parent object together with their children such that when you resolve its children later , they are already fetched and you do not need to fetch them again.

Also, if the objects in your domain can contain infinity number in theory , you should consider to implement pagination behaviour for the query in order to restrict the maximum number of the objects that it can return.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文