2020-02-19
2229
#graphql
Leonardo Losoviz
14127
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:

Interface Segregation Principle

SOLID series: Understanding the Interface Segregation Principle (ISP)

Discover how the Interface Segregation Principle (ISP) keeps your code lean, modular, and maintainable using real-world analogies and practical examples.

Oyinkansola Awosan
Jun 30, 2025 â‹… 7 min read
​​How HTML’s Selectedcontent Element Improves Dropdowns

​​How HTML’s <selectedcontent> element improves dropdowns

is an experimental HTML element that gives developers control over how a selected option is displayed, using just HTML and CSS.

Temitope Oyedele
Jun 27, 2025 â‹… 6 min read
advanced caching in Node.js with Valkey

How to get faster data access in Node.js with Valkey

Learn how to implement an advanced caching layer in a Node.js app using Valkey, a high-performance, Redis-compatible in-memory datastore.

Muhammed Ali
Jun 27, 2025 â‹… 7 min read
how to properly handle rejected promises in TypeScript

How to properly handle rejected promises in TypeScript

Learn how to properly handle rejected promises in TypeScript using Angular, with tips for retry logic, typed results, and avoiding unhandled exceptions.

Lewis Cianci
Jun 26, 2025 â‹… 4 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