implement DataLoader in GraphQL gateway to prevent N+1 queries close

[Joewizy]

Closes #110

PR Summary

Changes

New files (9):

• graphql/loaders/user.loader.ts — Batch loads users by ID
• graphql/loaders/nft.loader.ts — Batch loads NFTs by ID (with attributes)
• graphql/loaders/collection.loader.ts — Batch loads collections by ID
• graphql/loaders/listing.loader.ts — Batch loads listings by NFT token ID
• graphql/loaders/auction.loader.ts — Batch loads active auctions by NFT token ID
• graphql/loaders/bid.loader.ts — Batch loads bids by auction ID
• graphql/loaders/order.loader.ts — Batch loads orders by NFT ID
• graphql/loaders/index.ts — Exports DataLoaders interface and createLoaders() factory
• graphql/types/user.types.ts — GraphqlUserProfile ObjectType for resolved user fields

Modified files (5):

• context/context.interface.ts — Added loaders: DataLoaders to GraphqlContext
• context/context.factory.ts — Creates fresh DataLoader instances per request via DataSource
• resolvers/nft.resolver.ts — Added @ResolveField for owner, creator, collection using DataLoader
• resolvers/collection.resolver.ts — Added @ResolveField for creator using DataLoader
• package.json — Added dataloader dependency

How it works

• Each request gets a fresh set of DataLoader instances (request-scoped caching)
• When resolving nested fields (e.g., 20 NFTs with owners), DataLoader batches individual .load(id) calls into a single WHERE id IN
  (...) query
• Before: 20 NFTs + owners + collections = 41+ queries
• After: 20 NFTs + owners + collections = 3 batched queries (~93% reduction)
• No breaking changes to the existing GraphQL schema — only additive fields (owner, creator, collection)

[drips-wave]

@Joewizy Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits