GraphQL APIs with Spring Boot · บทเรียน

DataLoaders พร้อมบริบท Spring และการทำงานแบบอะซิงโครนัส

DataLoaders พร้อมบริบท Spring และการทำงานแบบอะซิงโครนัส เป็นบทเรียน GraphQL APIs with Spring Boot ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน GraphQL APIs with Spring Boot และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส GraphQL APIs with Spring Boot มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

Recap: Why DataLoaders

You already know DataLoaders batch and cache to defeat the N+1 problem. Now the focus shifts to integration: wiring them into Spring's request lifecycle and async model the right way.

DataLoaders Are Request-Scoped

A DataLoader's cache must not leak across requests, or one user could see another's stale data. DataLoaders therefore live for a single GraphQL request and are discarded afterward.

Registering with DataLoaderRegistry

Spring for GraphQL builds a fresh DataLoaderRegistry per request. You contribute loaders to it using a BatchLoaderRegistry bean.

@Configuration
public class LoaderConfig {
    public LoaderConfig(BatchLoaderRegistry registry,
                        AuthorService authors) {
        registry.forTypePair(Long.class, Author.class)
            .registerMappedBatchLoader((ids, env) ->
                Mono.fromCallable(() -> authors.findByIds(ids)));
    }
}

Mapped vs Plain Batch Loaders

A mapped batch loader returns a Map of key to value, which is ideal when results may come back unordered or with gaps. A plain batch loader returns a list aligned by index.

Accessing a Loader in a Resolver

In a @SchemaMapping method, inject the registered DataLoader directly as a parameter. Spring supplies the request-scoped instance.

@SchemaMapping
public CompletableFuture<Author> author(Book book,
        DataLoader<Long, Author> loader) {
    return loader.load(book.getAuthorId());
}

Why CompletableFuture?

A DataLoader's load() returns a CompletableFuture. The framework collects all such futures in a tick, fires one batch call, then completes them together. Returning the future lets GraphQL defer resolution.

Passing Spring Context

Batch loaders receive a BatchLoaderEnvironment that can carry context, like the authenticated user, so authorization-aware loading works correctly.

registry.forTypePair(Long.class, Book.class)
    .registerMappedBatchLoader((ids, env) -> {
        var ctx = env.getContext();
        return Mono.fromCallable(() -> books.findByIds(ids));
    });

Going Non-Blocking

For reactive stacks, return a Mono or Flux from the batch loader so the data fetch never blocks a thread, maximizing throughput.

registry.forTypePair(Long.class, Author.class)
    .registerMappedBatchLoader((ids, env) ->
        authorRepository.findAllById(ids)
            .collectMap(Author::getId));

Combining Loaders

A resolver can use multiple loaders, and loaders can call other loaders. Because batching happens per tick, even chained loads stay efficient and avoid N+1 cascades.

Common Pitfalls

Watch out for:

Sharing a loader across requests (cache leak)
Calling .get() on the future and blocking
Forgetting to map results by key, causing null mismatches
Doing heavy work outside the batch function

Best Practices

Keep loaders clean:

Register via BatchLoaderRegistry, never manually per request
Prefer mapped loaders for robustness
Return reactive types on reactive stacks
Pass context for auth-aware batching

Quick Check

Test your DataLoader integration knowledge.

Recap

You integrated DataLoaders into Spring:

Register loaders via BatchLoaderRegistry, request-scoped
Inject them as resolver parameters
load() returns a CompletableFuture for deferred batching
Pass context and return reactive types for non-blocking loads

Well-integrated loaders make your API both correct and fast.

คำถามที่พบบ่อย

บทเรียน “DataLoaders พร้อมบริบท Spring และการทำงานแบบอะซิงโครนัส” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “DataLoaders พร้อมบริบท Spring และการทำงานแบบอะซิงโครนัส” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส GraphQL APIs with Spring Boot ให้อัปเกรดเป็น CoddyKit PRO คอร์ส GraphQL APIs with Spring Boot มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “DataLoaders พร้อมบริบท Spring และการทำงานแบบอะซิงโครนัส”

ผสานรวม GraphQL DataLoaders เข้ากับ Spring Boot อย่างเป็นระเบียบ โดยลงทะเบียนแยกตามคำขอ เข้าถึงจากตัวแก้ไข และใช้งานร่วมกับการเข้าถึงข้อมูลแบบอะซิงโครนัสที่ไม่บล็อก คุณปฏิบัติ GraphQL APIs with Spring Boot ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน GraphQL APIs with Spring Boot หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน GraphQL APIs with Spring Boot บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “DataLoaders พร้อมบริบท Spring และการทำงานแบบอะซิงโครนัส” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน GraphQL APIs with Spring Boot นี้ได้ไหม

ได้ บทเรียน GraphQL APIs with Spring Boot ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

อธิบายปัญหา N+1
แนะนำ GraphQL DataLoaders
การนำการรวมชุดคำขอและการแคชมาใช้
DataLoaders พร้อมบริบท Spring และการทำงานแบบอะซิงโครนัส

← กลับไปที่ GraphQL APIs with Spring Boot