HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
graphql
dataloader
JavaScript2015–2026
graphql / dataloader

dataloader

DataLoader is a generic utility to be used as part of your application's data fetching layer to provide a consistent API over various backends and reduce requests to those backends via batching and caching.

37Distinct people
37Mentions
0Explicit recommenders
13.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

DataLoader is a generic utility to be used as part of your application's data fetching layer to provide a consistent API over various backends and reduce requests to those backends via batching and caching.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 6:01:08 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year37 dated mentions

Observed mentions: 2015-09-14 19:03:03 UTC to 2026-02-19 19:45:34 UTC.

02468102015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC312
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC505
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC909
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC404
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC303
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC303
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
DataLoader DataLoader is a generic utility to be used as part of your application's data fetching layer to provide a simplified and consistent API over various remote data sources such as databases or web services via batching and caching. A port of the "Loader" API originally developed by @schrockn at Facebook in 2010 as a simplifying force to coalesce the sundry key-value store back-end APIs which existed at the time. At Facebook, "Loader" became one of the implementation details of the "Ent" framework, a privacy-aware data entity loading and caching layer within web server product code. This ultimately became the underpinning for Facebook's GraphQL server implementation and type definitions. DataLoader is a simplified version of this original idea implemented in JavaScript for Node.js services. DataLoader is often used when implementing a graphql-js service, though it is also broadly useful in other situations. This mechanism of batching and caching data requests is certainly not unique to Node.js or JavaScript, it is also the primary motivation for Haxl, Facebook's data loading library for Haskell. More about how Haxl works can be read in this blog post. DataLoader is provided so that it may be useful not just to build GraphQL services for Node.js but also as a publicly available reference implementation of this concept in the hopes that it can be ported to other languages. If you port DataLoader to another language, please open an issue to include a link from this repository. Getting Started First, install DataLoader using npm. npm install --save dataloader To get started, create a DataLoader. Each DataLoader instance represents a unique cache. Typically instances are created per request when used within a web-server like express if different users can see different things. Note: DataLoader assumes a JavaScript environment with global ES6 Promise and Map classes, available in all supported versions of Node.js. Batching Batching is not an advanced feature, it's DataLoader's primary feature. Create loaders by providing a batch loading function. const DataLoader = require('dataloader'); const userLoader = new DataLoader(keys => myBatchGetUsers(keys)); A batch loading function accepts an Array of keys, and returns a Promise which resolves to an Array of values*. Then load individual values from the loader. DataLoader will coalesce all individual loads which occur within a single frame of execution (a single tick of the event loop) and then call your batch function with all requested keys. const user = await userLoader.load(1); const invitedBy = await userLoader.load(user.invitedByID); console.log(`User 1 was invited by ${invitedBy}`); // Elsewhere in your application const user = await userLoader.load(2); const lastInvited = await userLoader.load(user.lastInvitedID); console.log(`User 2 last invited ${lastInvited}`); A naive application may have issued four round-trips to a backend for the required information, but with DataLoader this application will make at most two. DataLoader allows you to decouple unrelated parts of your application without sacrificing the performance of batch data-loading. While the loader presents an API that loads individual values, all concurrent requests will be coalesced and presented to your batch loading function. This allows your application to safely distribute data fetching requirements throughout your application and maintain minimal outgoing data requests. Batch Function A batch loading function accepts an Array of keys, and returns a Promise which resolves to an Array of values or Error instances. The loader itself is provided as the this context. async function batchFunction(keys) { const results = await db.fetchAllKeys(keys); return keys.map(key => results[key] || new Error(`No result for ${key}`)); } const loader = new DataLoader(batchFunction); There are a few constraints this function must uphold: The Array of values must be the same length as the Array of keys. Each index in the Array of values must correspond to the same index in the Array of keys. For example, if your batch function was provided the Array of keys: [ 2, 9, 6, 1 ], and loading from a back-end service returned the values: { id: 9, name: 'Chicago' } { id: 1, name: 'New York' } { id: 2, name: 'San Francisco' } Our back-end service returned results in a different order than we requested, likely because it was more efficient for it to do so. Also, it omitted a result for key 6, which we can interpret as no value existing for that key. To uphold the constraints of the batch function, it must return an Array of values the same length as the Array of keys, and re-order them to ensure each index aligns with the original keys [ 2, 9, 6, 1 ]: [ { id: 2, name: 'San Francisco' }, { id: 9, name: 'Chicago' }, null, // or perhaps `new Error()` { id: 1, name: 'New York' }, ]; Batch Scheduling By default DataLoader will coalesce all individual loads which occur within a single frame of execution before calling your batch function with all requested keys. This ensures no additional latency while capturing many related requests into a single batch. In fact, this is the same behavior used in Facebook's original PHP implementation in 2010. See enqueuePostPromiseJob in the source code for more details about how this works. However sometimes this behavior is not desirable or optimal. Perhaps you expect requests to be spread out over a few subsequent ticks because of an existing use of setTimeout, or you just want manual control over dispatching regardless of the run loop. DataLoader allows providing a custom batch scheduler to provide these or any other behaviors. A custom scheduler is provided as batchScheduleFn in options. It must be a function which is passed a callback and is expected to call that callback in the immediate future to execute the batch request. As an example, here is a batch scheduler which collects all requests over a 100ms window of time (and as a consequence,
Read the full README on GitHub

What Hacker News says

2 sources
Eh... I'm torn on it and could write at length about this, but here's my off-the-cuff thoughts. For context, my co-founder and I are quite active in the GraphQL community. If you've ever used apollo-cache-persist[1] or graphql-crunch[2], we authored those libraries. Our startup, if you're curious, is a social podcasting app written in react-native (https://banter.fm). We learned a lot of GraphQL lessons building it. The tl;dr; is that graphql gives you a lot of flexibility and typed schemas are nice, but it doesn't come for free and I miss the tooling around http. Pros: - Typed schema - Custom queries retrieve all the data the client needs in one request - Really easy to implement, both server-side and client-side - Server-side, it's trivial to have any field resolved in any way you want (redis, memcache, postgres, some random service) -
Read the rest
Easy and arbitrary mutations. There's no pontificating over what verbs are the proper ones to us. - If you use react, the community and ecosystem often assumes you're using GraphQL, so it may make sense to use graphql just so you don't swim against the current. Cons: - The payloads can quickly become huge because there is often a ton of duplication in a responses (depending on your query patterns). See this example on the SWAPI demo: https://bit.ly/2uOFZBP. The result is 1MB of JSON, ~97% of which is data that exists somewhere else in the response already. - Refactoring types is often impossible to do in a backwards-compatible way, even if the shape of the data is the same. - You don't know what data you'll need in advance, so you're basically doing all of your joins by going back and forth between the api resolver and your data sources (this can be alleviated with persistent queries, but those come with their own set of issues). A typical query to hydrate a response for a user's feed in our app requests ~1,100 objects. After caching and consolidating queries into multi-gets, it translates to about 50 distinct DB queries. - Tooling: Working at the HTTP level simply has better tooling and tons of infrastructure around caching and serving content (varnish, nginx, etc...) We found that graphql payloads were so large that older mobile phones were spending significant time parsing them. We created graphql-crunch to de-duplicate responses before sending them over the wire. This led to nice perf improvements on mobile platforms. It also gave us referential equality when persisting the results to cache, allowing us to reduce a lot of work client side. If you're going to use GraphQL, embrace the javascript ecosystem. Also use Apollo[3]. Also use DataLoader[4]. Roughly 40% of our queries get resolved for "free" by data loader. If I were to do it again, I'd at least prototype a REST-api with resources designed specifically for http cache-ability (that is, break out session-specific resources/attributes vs shared resources) and see if HTTP/2 multiplexing + nginx caching + etags results in a good client experience. But I also mostly work on the backend while my co-founder mostly works on the frontend, so we have different desires and constraints. Ideally, as few requests as possible would make it to code that I wrote. With GraphQL that's nearly impossible. [1] https://blog.apollographql.com/announcing-apollo-cache-persi... [2] https://github.com/banterfm/graphql-crunch [3] https://www.apollographql.com/server [4] https://github.com/facebook/dataloader
In Ask HN: Were you happy moving your API from REST to GraphQL?

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.