I would like to promote my crate wundergraph. It greatly simplifies the creation of a performant GraphQL over given relational database schema.
Implementations using diesel and juniper in a straight forward most likely have problems with N+1 queries while resolving a nested GraphQL entity. Wundergraph is build on top of diesel and juniper and circumvents this problems carefully craft a fixed number(= independent of the actual number of loaded database entries) of SQL queries to resolve one GraphQL request.
(This seems to be not the case for this example, because there is only one GraphQL entity that is mapped to a database entity, but if this should be a good starting point for a real world application it's probably worth to change it anyway.)
weeping-somnambulist
commented
2 years ago
I would like to promote my crate wundergraph. It greatly simplifies the creation of a performant GraphQL over given relational database schema.
Implementations using diesel and juniper in a straight forward most likely have problems with N+1 queries while resolving a nested GraphQL entity. Wundergraph is build on top of diesel and juniper and circumvents this problems carefully craft a fixed number(= independent of the actual number of loaded database entries) of SQL queries to resolve one GraphQL request. (This seems to be not the case for this example, because there is only one GraphQL entity that is mapped to a database entity, but if this should be a good starting point for a real world application it's probably worth to change it anyway.)