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:

Fix over-caching with dynamic IO caching in Next.js 15

Next.js 15 caching overhaul: Fix overcaching with Dynamic IO and the use cache directive.

David Omotayo
Aug 6, 2025 â‹… 10 min read
LLMs are facing a QA crisis here’s how we could solve it

LLMs are facing a QA crisis: Here’s how we could solve it

LLM QA isn’t just a tooling gap — it’s a fundamental shift in how we think about software reliability.

Rosario De Chiara
Aug 4, 2025 â‹… 7 min read

Windsurf vs. Cursor: When to choose the challenger

Windsurf AI brings agentic coding and terminal control right into your IDE. We compare it to Cursor, explore its features, and build a real frontend project.

Chizaram Ken
Jul 31, 2025 â‹… 9 min read

The CSS if() function: Conditional styling will never be the same

The CSS Working Group has approved the if() function for development, a feature that promises to bring true conditional styling directly to our stylesheets.

Ikeh Akinyemi
Jul 30, 2025 â‹… 12 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