react-relay VS dataloader

Link

Suppose we have this JavaScript file from Relay, a GraphQL client framework.

Relay is a JavaScript framework for building data-driven React applications.

Relay 17 Improved correctness checking and validation; Additional editor features; Experimental features exploring error handling and nullability

GraphQL Relay is one of the most powerful GraphQL clients that you can found on the web environment. It provides to you a lot of features that lets your development flow in a scalable way.

GQty (https://gqty.dev/) and Relay (https://relay.dev/) will combine fragments or queries you request in your React components and will handle combining these / getting the data each component needs with as few queries as is possible. Are there any other clients I’ve missed? It’s not immediately clear to me whether this is possible with Urql via Exchanges (https://formidable.com/open-source/urql/docs/advanced/authoring-exchanges/).

Inside Woovi, our entire codebase is managed by GraphQL using the Relay client framework. To ensure the best UX possible for our final user, we give some useful features in our payment link, like the real-time update after paying a charge. It's all handled by our GraphQL, which won't be solvable by templates in our use case.

Since you mentioned Node CRUD APIs, I'd probably suggest looking at Relay/GraphQL. Would give you exposure to some interesting and employable skills that wouldn't require you learning an entirely new domain on top of it. They are rewriting the current compiler in Rust, which since you mentioned Rust might be interesting to follow. Uneducated takes, but GraphQL is a schema IDL, so would probably be a good place to start to minimize lexical complexity while still having some cool abstract concepts to learn (interfaces, unions, etc).

Cons: 1. Potential Complexity: Implementing and maintaining GraphQL servers can become complex, especially with custom data resolvers for different scenarios. While TypeGraphQL-Prisma abstracts some of this complexity, there’s a risk of encountering issues in auto-generated resolvers, which might be challenging to fix. 2. Caching Challenges: Unlike REST, where caching is more straightforward due to predictable endpoints, caching in GraphQL can be more complicated. Each query is unique, making traditional caching mechanisms less effective. 3. Performance Concerns: Complex and overly nested queries or inefficient resolvers can impact server performance. It could be that the generated TypeGraphQL resolvers do something smart for this issue. For example to use the dataloader pattern. However, I have not had the opportunity yet to investigate this topic. 4. Adoption and Skill Gap: Despite its growing popularity, GraphQL is still not as widely adopted as REST. This might present a learning curve for teams unfamiliar with the technology. 5. Security Considerations: With GraphQL’s single endpoint, securing the API becomes more complex. Fine-grained control over authorization at the resolver, model, and field levels is necessary, making it more challenging compared to REST.

This seems to be the dataloader pattern. There are implementations in many languages, but the idea is that you have a bunch of threads which declare their I/O needs, and then you 1) denounce and merge the requests (uniform access) and 2) cache the results so that later in the graph of calls you don’t need to fetch already loaded data.

Here’s one impl: https://github.com/graphql/dataloader

When I began working with GraphQL, I had concerns about the N+1 query problem. In my research, I came across the DataLoader pattern and its implementation on GitHub. While I explored various examples of its usage, I still struggled to grasp how it operates internally. Join me in delving a bit deeper into GraphQL DataLoader! :)

DataLoader: it is the standard solution to N+1 problem.

Additionally, you can use DataLoader or similar tools to optimize data fetching and avoid over-fetching or under-fetching data. Ultimately, performance and load tests ensure that your GraphQL API delivers optimal performance, meets response time expectations, and provides a smooth experience for users, even under heavy loads.

The most common practice is to turn N+1 into 1+1 using dataloaders (https://github.com/graphql/dataloader for JS, there are equivalents for most implementations). The N resolvers invoke a single batched loader which receives a list of keys and returns a list of values.

Let's take Payload, for example. Surprise, surprise. We have a relationship field, and it can store IDs to other related documents which are seamlessly merged in when you retrieve documents from the DB. We leverage the dataloader pattern to batch together all "populations" required for a given query, returning them all super fast and with as few separate queries to the DB as possible. We actually even outperform SQL-based frameworks quite a bit. In a purely relational test, we were 3x faster than Directus and 7x faster than Strapi while both were running Postgres, and we were on MongoDB.

Also, have a look at Facebook's Dataloader[0].

[0] https://github.com/graphql/dataloader

In the next article, I'm going to implement a GraphQL server with dataloader using the tools we introduced.