Querying relational data in GraphQL (NoSQL v RDS) - database

Question

I'm writing an application that contains an overall data model with some obvious relations. I started writing the application using MongoDB but decided to try and transition over to Postgres since my data has tons of "foreign keys". For simplicity, let's consider the following models:
class GameBase {
id: string
entryIds: string[]
submissionIds: string[]
}
class EntryBase {
id: string
description: string
gameId: string
userId: string // id of user who supplied entry
submissionIds: string[] // submissions where entry is covered
}
class SubmissionBase {
id: string
url: string
gameId: string
userId: string // id of user who submitted
entryIds: string[] // entries covered by submission
}
Now I understand if I use a tool like TypeOrm, I could retrieve these relations with something along the lines of:
const games = await gameRepository.find({ relations: ["entryIds", "submissionIds"] });
But I'm not really sure how that relates to GraphQL. What I've been doing up until now is adding #ResolveField inside my Resolvers and writing something like
// game.resolver.ts
#ResolveField(() => [SubmissionBase], { nullable: true })
submissions(#Parent() game: GameBase) {
return this.submissionService.getManySubmissions(game.submissionIds)
}
and in the service
// game.service.ts
async getManySubmissions(submissionIds: string[]): Promise<SubmissionBase[]> {
if (!submissionIds) return []
return await this.submissionRepository.find({
where: {
id: { $in: submissionIds },
},
})
}
So this makes sense to me and has been working great, I'm just curious if I would see tangible speed/performance improvements if I switched to a relational database. For example, if the same .find method you see in my service was instead backed by Postgres instead of MongoDB, and the appropriate foreign key relationship was established, could I reasonably expect speed improvements? I imagine I wouldn't since it's just a simple get with no joins. Also, although submissionIds is a pseudo foreign key (because of MongoDB), it still acts as one in this setup. I guess I'm failing to see why MongoDB is inherently the wrong choice for relational data if you can use GraphQL and something like #ResolveField to grab whatever you need. What would a successful implementation of an RDS backed by GraphQL look like given this context?

Answer 1

This is a good question although I think it's going to get some opinionated and non definitive answers. My personal experience and advice after working on multiple production GraphQL servers talking to both SQL and NoSQL databases is this:
If you're going to expose GraphQL over a relational DB like Postgres and you're using NestJS do not write the GraphQL layer by hand
It's extremely time consuming and error prone plus you'll run into all kinds of problems related to N+1 and performance while sacrificing lots of the functionality that is gained by using an RDS in the first place (like the joins you're talking about). As someone who has gone down this path before, just please don't
There is a plethora of extremely powerful technologies that allow you to instead generate a GraphQL API on top of your RDS. These technologies than parse the GraphQL AST and convert it into an optimized single SQL query. I highly recommend that you look in to Hasura and PostGraphile. Both of these will blow you away with how productive you can be. Manually writing resolvers over top of SQL relations is just a waste of time
These tools can then be integrated into and with your NestJS application. If you're interested in Hasura specifically, I maintain open source packages that can help you integrate it nicely with NestJS