DynamoDB와 함께 GraphQL을 사용하는 것이 좋습니다.

GraphQL's 리졸버에 대한 가장 큰 오해는 리졸버를 필드에 배치해야 한다는 것입니다. 당신은하지 않습니다.

쿼리/변형에 1을 넣습니다. 이것은 사람들이 생각하기 때문에 중요합니다.

"oh, DynamoDB is single table design, GraphQL needs individual fields".

아니요. 쿼리는 DynamoDB 쿼리만 수행할 수 있습니다.

개별 GraphQL 필드 해석기에 대한 걱정은 일련의 I/O 호출을 여러 번 수행하는 폭포수 패턴에 들어가고 속도가 느려지거나 더 나쁘게는 여러 DynamoDB 테이블을 활용하여 더 관계형으로 만들고 따라서 사용하지 않는 것입니다. 싱글 테이블 디자인.

이를 위해 AppSync/GraphQL API를 구축하는 경우 문제가 됩니다. Postegres 과 같은 관계형을 사용하는 것이 좋습니다.

Dynamo용 단일 테이블 디자인을 원하고 GraphQL을 사용하려는 경우 모델링에 두 번째 단계를 추가하기만 하면 됩니다.

1단계는 전체 "조인을 단일 행으로 평면화"입니다. 이것이 단일 쿼리에서 얻을 수 있도록 데이터를 최적화하는 일반적인 DynamoDB 패턴입니다.

2단계는 "해당 dynamodb 쿼리에 대한 GraphQL 쿼리 만들기"입니다. 그게 다야.

예, GraphQL 쿼리:

getStuff(id:ID!):Stuff!

그러면 Lambda가 Dynamo를 호출합니다.

dynamodbDoc.query({ 'id=getStuffID' })

1단계에서 데이터 액세스 패턴을 사소하게 만드는 것이 아닙니다. 매우 어렵습니다. 이것은 또한 "제품 소유자/사용자"가 항상 쓰레기를 변경하고 쿼리를 업데이트할 때 처벌을 받지 않기 때문에 유연성을 위해 관계형 또는 NoSQL을 사용하는 것이 때때로 더 쉬운 이유이기도 합니다.

ETL 파이프라인 작성을 즐기는 동안 비즈니스/제품이 마음을 바꾼다고 해서 처벌을 받아서는 안 됩니다.

어쨌든, tl;dr; UI가 [1, 2, 3]을 백엔드로 안전하게 전달할 수 있도록 하는 것이 REST보다 GraphQL에서 더 쉽습니다. UI용 BFF를 구축하면서 액세스 패턴을 알고 있습니다. GraphQL + DynamoDB는 훌륭합니다.