Leonardo Losoviz
Feb 19, 2020 ⋅ 7 min read

Simplifying the GraphQL data model

Leonardo Losoviz Freelance developer and writer, with an ongoing quest to integrate innovative paradigms into existing PHP frameworks, and unify all of them into a single mental model.

Recent posts:

Using Rust And Leptos To Build Beautiful Declarative User Interfaces

Using Rust and Leptos to build beautiful, declarative UIs

Leptos is an amazing Rust web frontend framework that makes it easier to build scalable, performant apps with beautiful, declarative UIs.

Eze Sunday
Nov 30, 2023 ⋅ 10 min read
5 Best JavaScript Multi-Dimensional Array Libraries

5 best JavaScript multidimensional array libraries

Learn more about the 5 best JavaScript libraries for dealing with multidimensional arrays, such as ndarray, math.js, and NumJs.

Pascal Akunne
Nov 30, 2023 ⋅ 4 min read
Dom Scandinaro Leader Spotlight

Leader Spotlight: Leading by experience with Dom Scandinaro

We spoke with Dom about his approach to balancing innovation with handling tech debt and to learn how he stays current with technology.

Jessica Srinivas
Nov 30, 2023 ⋅ 6 min read
Vite Adoption Guide Overview Examples And Alternatives

Vite adoption guide: Overview, examples, and alternatives

Vite is a versatile, fast, lightweight build tool with an exceptional DX. Let’s explore when and why you should adopt Vite in your projects.

David Omotayo
Nov 29, 2023 ⋅ 16 min read
View all posts

2 Replies to "Simplifying the GraphQL data model"

  1. The whole spiel of ‘components’ seemingly has nothing to do with the final solution. You are still loading data as a graph. All you have done is load ALL the edges of the graph with each node. This allows you to more efficiently load the other nodes connected to each node. Again, you have just shifted the problem to the persistence layer where you now must load ALL these edges. Some nodes (think a UserAccount) may have many, many edges which makes this extremely in-efficient. Imagine doing 100s of joins to get all related edges in an RDBMS. A better solution is to load the edges you need in the child resolver then defer loading the actual nodes using a data-loader.

  2. Also, this does not even account for when an edge may not just be a simple foreign key in a relational database table. There could be complex ternary relations etc as well.

Leave a Reply