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:

how to get the most out of Cursor

Frontend devs: Here’s how to get the most out of Cursor

Learn how to get the most out of Cursor AI — one of the hottest tools in AI-assisted coding, with practical workflows and underrated features.

Isaac Okoro
Jun 18, 2025 â‹… 5 min read
When to Use OpenAI vs. Open Source LLMs LogRocket

When to use OpenAI vs. open source LLMs in production

Learn about OpenAI vs open source LLMs for frontend devs, with an integration guide, costs, performance comparison, and implementation tips.

Clara Ekekenta
Jun 17, 2025 â‹… 6 min read
RAG vs. Fine Tuning, A LogRocket Article

Fine-tuning vs. RAG: Which AI strategy fits your frontend project?

Compare fine-tuning vs. RAG to design faster, smarter, and more responsive AI-powered frontend experiences.

Ikeh Akinyemi
Jun 16, 2025 â‹… 8 min read
7 Common CSS Navigation Menu Mistakes And How To Fix Them

7 common CSS navigation menu mistakes and how to fix them

Navigation menu errors are common, even for seasoned developers. Learn seven common navigation menu errors and how to solve them using CSS.

Temitope Oyedele
Jun 13, 2025 â‹… 6 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